Propel1 Laravel Package

Technical Evaluation

Architecture Fit

• Legacy ORM for PHP 5.3+: Propel1 is a v1.7.x fork of Propel ORM, designed for PHP 5.3–7.4 compatibility. It is not a modern Laravel-compatible ORM (e.g., Eloquent, Doctrine). Key misalignments:

  • No Laravel Service Provider: No built-in Laravel integration (e.g., register()/boot() methods).
  • Schema/Migration System: Uses Propel’s XML schema (schema.xml) and reverse-engineering tools (not Laravel’s migrations).
  • Query Builder: Propel’s Criteria API differs significantly from Laravel’s Query Builder/Eloquent.
  • Dependency Injection: Propel relies on static methods (e.g., Model::getTableMap()) and global configuration, conflicting with Laravel’s container.
  • Event System: Propel lacks Laravel’s events/listeners (e.g., ModelObserver).

• Use Case Fit:

  • Legacy Codebases: Ideal for maintaining old Propel-based apps migrated to PHP 7.x.
  • Non-Laravel Projects: Better suited for standalone PHP apps or Symfony 1.x/2.x (where Propel 1.x had limited support).
  • Avoid for New Projects: Laravel’s ecosystem (Eloquent, Query Builder) is far more mature for new development.

Integration Feasibility

• Composer Integration: Trivial (composer require palepurple/propel1), but no Laravel-specific hooks.
• Schema Management:
  • Propel’s XML schema must be manually synced with Laravel’s migrations (if used).
  • Reverse-engineering (generating models from DB) conflicts with Laravel’s conventions.
• Model Generation:
  • Propel generates static BaseModel classes (e.g., UserPeer), which clash with Laravel’s Eloquent.
  • No automatic table naming: Propel uses schema.xml; Laravel uses snake_case conventions.
• Query Differences:
  • Propel’s Criteria API (e.g., $criteria->add(UserPeer::NAME, 'John')) is incompatible with Laravel’s fluent query builder.
  • No Eloquent-like relationships: Propel uses hasMany(), hasOne(), etc., but no dynamic accessors ($user->posts).

Technical Risk

Key Questions for TPM

1. Why Propel1?
   • Is this for legacy migration or new feature development?
   • Are there specific Propel features (e.g., nested sets, behaviors) that Laravel lacks?
2. Laravel Compatibility Layer
   • Will you build a wrapper to expose Propel models as Eloquent-like objects?
   • Example: PropelUser::find($id) → new EloquentUserWrapper(UserPeer::retrieveByPk($id)).
3. Schema Management
   • How will you sync Propel’s XML schema with Laravel migrations?
   • Will you abandon Laravel migrations in favor of Propel’s tools?
4. Performance Impact
   • Propel1’s static models may bloat autoloading. Will this affect CI/CD?
5. Long-Term Viability
   • PHP 8.x support is unlikely. Is this a temporary stopgap?
   • Are there modern alternatives (e.g., Doctrine DBAL, Eloquent) that could replace Propel’s role?
6. Team Familiarity
   • Does the team have Propel expertise? Training costs may outweigh benefits.
7. Behavioral Differences
   • Propel’s lazy loading differs from Eloquent’s. Will this cause bugs in existing code?

Integration Approach

Stack Fit

• Laravel Core: Poor fit. Propel’s static models, XML schema, and Criteria API are fundamentally incompatible with Laravel’s:
  • Service Container: Propel uses globals (Propel::getConnection()).
  • Eloquent: Propel’s UserPeer ≠ Laravel’s User model.
  • Migrations: Propel’s schema.xml ≠ Laravel’s php artisan migrate.
• Symfony Components: Better fit than Laravel, but still not ideal (Propel 1.x was designed for Symfony 1.x).
• Standalone PHP: Best fit. Propel1 is not Laravel-specific and works in any PHP 5.3–7.4 app.

Migration Path

Option 1: Hybrid Integration (High Risk)

1. Install Propel1:

   composer require palepurple/propel1
   

2. Configure Propel:
   • Set up schema.xml (manual or reverse-engineered).
   • Configure build.properties for DB connection.
3. Build a Laravel Wrapper:
   • Create facade classes to expose Propel models as Eloquent-like objects.
   • Example:

     class PropelUser extends Model
     {
         public static function find($id) {
             return new EloquentUserWrapper(UserPeer::retrieveByPk($id));
         }
     }
     

   • Challenge: Propel’s static methods (e.g., UserPeer::doSelect()) must be dynamicized.
4. Query Adapter:
   • Write a Criteria-to-QueryBuilder translator to reuse existing Laravel queries.
   • Example:

     function propelCriteriaToQuery($criteria) {
         $query = User::query();
         foreach ($criteria->getWhereClauses() as $clause) {
             $query->where($clause->getColumn(), $clause->getValue());
         }
         return $query;
     }
     

5. Schema Sync:
   • Use Laravel migrations for new tables.
   • Manually sync Propel’s schema.xml for existing tables.

Option 2: Full Propel Replacement (Recommended)

• Replace Propel with:
  • Eloquent: For active record patterns.
  • Doctrine DBAL: For raw SQL/queries.
  • Laravel Query Builder: For fluent queries.
• Migration Steps:
  1. Generate Eloquent Models:

     php artisan make:model User -m
     

  2. Convert Propel Queries:

     // Propel1:
     $users = UserPeer::doSelect(new Criteria());
     
     // Eloquent:
     $users = User::all();
     

  3. Replace Behaviors:
     • Propel’s SluggableBehavior → Laravel Observers or Accessors.
     • Propel’s TimestampableBehavior → Eloquent’s created_at/updated_at.

Option 3: Isolated Propel Module (Low Risk)

• Use Propel only for specific features (e.g., nested sets, complex queries).
• Keep Laravel and Propel in separate namespaces.
• Example:

  // In a service class:
  class LegacyReportGenerator
  {
      public function generate() {
          return PropelReportPeer::generate(); // Isolated Propel call
      }
  }
  

Compatibility

Sequencing

1. Assess Scope:
   • Identify which Propel features are critical (e.g., nested sets