Formula Doctrine Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Pros:

  • Decoupled Computation: Eliminates need for manual hydration logic or DQL/QueryBuilder modifications for read-only computed fields, reducing boilerplate.
  • Doctrine Integration: Leverages existing ORM infrastructure (metadata listeners, SQL walkers) without requiring custom repositories or hydration callbacks.
  • Symfony-First: Designed for Symfony’s DI container, aligning with modern Symfony best practices (e.g., autowiring, bundle architecture).
  • Performance: Avoids N+1 queries via SQL-level computation (subqueries/joins) rather than application-layer logic.
  • Readability: Declarative #[Formula] syntax (similar to Hibernate) improves entity clarity.

• Cons:

  • Limited to Read-Only Fields: Not suitable for writable computed fields or bidirectional relationships.
  • SQL Dependency: Computations must be expressible as SQL (no PHP logic in formulas).
  • Doctrine-Specific: Tight coupling to Doctrine ORM may complicate future migrations to other ORMs (e.g., Eloquent in Laravel).
  • Bundle Maturity: Low stars/dependents suggest unproven stability; lacks active community or enterprise adoption signals.

Integration Feasibility

• Symfony Compatibility: Seamless integration with Symfony’s DI and Doctrine bundles (e.g., doctrine/orm). Assumes Symfony 6.4+ (PHP 8.2+).
• Laravel Gap: Critical Risk: The package is Symfony-specific and relies on:
  • Symfony’s Bundle system (no Laravel equivalent).
  • Doctrine’s metadata listeners and SQL walkers (Laravel uses Eloquent, not Doctrine ORM).
  • Symfony’s event system for lifecycle hooks.
• Workarounds:
  • Option 1: Port the core logic (cryonighter/formula-doctrine) to Laravel/Eloquent (high effort, requires rewriting Doctrine listeners for Eloquent’s query builder).
  • Option 2: Use as a reference for a custom Laravel package (e.g., #[Formula] attribute + Eloquent query macros).
  • Option 3: Hybrid approach: Use for Symfony microservices while keeping Laravel services separate.

Technical Risk

• High Risk for Laravel:
  • Architectural Mismatch: Doctrine vs. Eloquent paradigms differ in query building, hydration, and event systems.
  • Maintenance Overhead: Custom integration would require ongoing sync with upstream changes.
  • Performance Unknowns: SQL subqueries/joins in Laravel may behave differently than in Doctrine (e.g., query caching, connection pooling).
• Mitigations:
  • Proof of Concept: Test with a single entity to validate SQL computation behavior in Laravel’s query builder.
  • Benchmark: Compare performance against manual hydration (e.g., accessors with selectRaw).
  • Fallback Plan: Implement a lightweight alternative (e.g., Eloquent accessors with select clauses) if integration fails.

Key Questions

1. Use Case Criticality:
   • Are computed fields mandatory for core functionality, or is this a "nice-to-have"?
   • Can requirements be met with existing Laravel tools (e.g., Eloquent accessors, selectRaw, or database views)?
2. Team Expertise:
   • Does the team have experience with Doctrine’s internals (e.g., SQL walkers, metadata listeners)?
   • Is there bandwidth to maintain a custom Laravel port?
3. Long-Term Strategy:
   • Will this package replace existing computed-field logic, or supplement it?
   • How will future Laravel/Eloquent updates affect compatibility?
4. Alternatives:
   • Have other solutions (e.g., Laravel’s select + accessors) been evaluated?
   • Would database-level solutions (e.g., computed columns, views) suffice?

Integration Approach

Stack Fit

• Symfony: Native Fit – Designed for Symfony’s ecosystem (bundles, DI, Doctrine).
• Laravel: Poor Fit – Requires significant adaptation due to:
  • ORM Differences: Eloquent lacks Doctrine’s metadata listeners and SQL walkers.
  • Event System: Symfony’s event system (e.g., postLoad) doesn’t map 1:1 to Laravel’s model events.
  • Bundle System: Laravel uses packages/composers, not Symfony bundles.
• Hybrid Stacks:
  • Possible in Symfony + Laravel apps if computed fields are isolated to Symfony services.
  • Not recommended for shared entities between Laravel and Symfony.

Migration Path

1. Assessment Phase:
   • Audit entities needing computed fields. Categorize by:
     • Simple accessors (can use Eloquent’s getXAttribute).
     • Complex SQL (may require selectRaw or custom queries).
   • Benchmark performance of alternatives (e.g., database views vs. application logic).
2. Pilot Integration:
   • Option A (Low Risk): Implement #[Formula] as a Laravel attribute macro + Eloquent query macros.
     • Example:

       // app/Providers/AppServiceProvider.php
       use Illuminate\Support\Facades\Eloquent;
       Eloquent::macro('formula', function ($sql) {
           return $this->selectRaw("({$sql}) as formula_value");
       });
       

       // Model
       class Customer extends Model {
           public function getOrderCountAttribute() {
               return $this->formula('(SELECT COUNT(*) FROM orders WHERE customer_id = id)');
           }
       }
       

   • Option B (High Risk): Fork cryonighter/formula-doctrine and adapt for Eloquent.
     • Requires rewriting Doctrine listeners for Eloquent’s Builder/Query classes.
3. Full Rollout:
   • Replace manual hydration logic with the chosen approach.
   • Update CI/CD to test computed fields in queries (e.g., Model::with('relations')->get()).

Compatibility

• Doctrine-Specific Features:
  • Metadata Listeners: Laravel/Eloquent uses runtime introspection, not compile-time metadata.
  • SQL Walkers: Eloquent’s query builder generates SQL differently; subqueries may need adjustment.
  • DBAL Middleware: Laravel’s query grammar may conflict with Doctrine’s SQL transformations.
• Database Compatibility:
  • Test on target DBMS (e.g., MySQL, PostgreSQL) for subquery/join behavior.
  • Ensure computed fields work with Laravel’s query caching (e.g., select clauses may bypass cache).

Sequencing

1. Phase 1: Replace simple computed fields with Eloquent accessors (getXAttribute).
2. Phase 2: Implement SQL-based formulas using selectRaw or query macros for complex cases.
3. Phase 3 (Optional): If critical, attempt a lightweight port of the bundle’s core logic (prioritize Formula attribute parsing and SQL injection).
4. Phase 4: Deprecate legacy computed-field logic (e.g., custom repositories).

Operational Impact

Maintenance

• Symfony Bundle:
  • Pros: Minimal maintenance (upstream updates handled by Composer).
  • Cons: Vendor lock-in to Symfony’s DI/Doctrine versions.
• Laravel Implementation:
  • Custom Code: Requires ongoing maintenance for:
    • SQL injection protection (critical for dynamic {this} placeholders).
    • Compatibility with Laravel/Eloquent updates (e.g., query builder changes).
  • Documentation: Need to document #[Formula] usage, edge cases (e.g., circular references), and performance implications.
• Dependency Risks:
  • cryonighter/formula-doctrine is unmaintained (no recent commits, no dependents).
  • Forking introduces long-term divergence risk.

Support

• Symfony:
  • Community support limited (0 stars, no issues/PRs).
  • Debugging may require diving into Doctrine internals.
• Laravel:
  • No existing support; team must build internal expertise.
  • Debugging complex SQL generation in Eloquent may be challenging.
• Failure Modes:
  • SQL Errors: Malformed formulas (e.g., syntax errors, missing tables) may crash queries.
  • Performance Regressions: Overly complex subqueries could degrade query plans.
  • Caching Issues: Computed fields may bypass Laravel’s query cache or result cache.

Scaling

• Symfony:
  • Scales well with Doctrine’s existing optimizations (e.g., query batching, DDC).
• Laravel:
  • Query Performance: Subqueries in select clauses may not scale as efficiently as joins in some databases.
  • Memory: Hydrating many entities with complex formulas could increase memory usage.
  • Database Load: Aggregations/subqueries in select may impact read replicas or sharded setups.
• Mitigations:
  • Use database views for frequently accessed computed fields.
  • Implement lazy-loading for non-critical formulas.

Failure Modes