Doctrine Support Laravel Package

Product Decisions This Supports

• Database Schema Flexibility: Enables Doctrine DBAL enums in Laravel, allowing teams to leverage advanced database types (e.g., PostgreSQL enums) without sacrificing Eloquent’s simplicity. This aligns with roadmaps prioritizing type safety and schema evolution (e.g., migrating from legacy string-based enums to native enums).
• Build vs. Buy: Avoids reinventing Doctrine integration for projects already using Doctrine DBAL (e.g., for multi-database support or legacy systems). Reduces dev time for teams maintaining hybrid stacks (e.g., Laravel + Symfony Doctrine).
• Legacy System Modernization: Supports Laravel 6.0, expanding compatibility for older projects still on that version, making it viable for teams with long-term maintenance needs or constrained upgrade paths.
• Use Cases:
  • PostgreSQL-heavy apps: Native enum support improves query performance and schema integrity.
  • Multi-tenant apps: Enums for tenant-specific configurations (e.g., UserRole per tenant).
  • Data migration projects: Safely transition from string-based enums to native enums without breaking changes.
  • Teams using Doctrine DBAL: If already invested in Doctrine (e.g., for migrations or connections), this package bridges the gap with Eloquent.
  • Legacy Laravel projects: Now supports Laravel 6.0, broadening adoption for teams unable to upgrade to newer Laravel versions.

When to Consider This Package

• Adopt if:
  • Your app uses Doctrine DBAL (e.g., for migrations, multi-connection setups, or legacy systems).
  • You’re on PostgreSQL and want to replace string-based enums with native enums for type safety or performance.
  • Your team is already familiar with Doctrine and needs seamless Laravel integration.
  • You’re building a greenfield project where enum support is a non-negotiable feature (e.g., domain-driven design with strict types).
  • You’re maintaining a Laravel 6.0+ project and need Doctrine DBAL enum support without upgrading Laravel.
• Look elsewhere if:
  • You’re not using Doctrine DBAL (package adds unnecessary complexity).
  • Your enums are simple (e.g., tinyint or string columns) and don’t require Doctrine’s features.
  • You’re on MySQL (native enums are limited; this package focuses on PostgreSQL/SQLite).
  • Your team lacks Doctrine experience (learning curve for setup/maintenance).
  • You need active maintenance (last release was 2019; evaluate fork or alternative like spatie/laravel-doctrine).
  • You’re on Laravel 5.x or below (package no longer supports versions prior to 6.0).

How to Pitch It (Stakeholders)

For Executives: "This package lets us use PostgreSQL’s native enums in Laravel—cutting down on data validation errors and improving query speed. For example, if we’re storing user roles, native enums prevent invalid values at the database level, reducing bugs in production. It’s a lightweight way to modernize our schema without rewriting core logic. With support for Laravel 6.0, it’s now viable for legacy projects still on that version, making it a low-risk upgrade for teams already using Doctrine DBAL. Since it’s MIT-licensed, it’s a cost-effective solution for schema improvements."

For Engineering: *"If we’re using Doctrine DBAL (e.g., for migrations or multi-connection setups), this package adds first-class enum support for Eloquent models. Key benefits:

• PostgreSQL enums: Replace string/integer columns with native enums for stricter validation.
• Zero Eloquent changes: Works alongside existing model code (e.g., User::where('role', User::ROLE_ADMIN)).
• Legacy support: Now officially supports Laravel 6.0, so it’s an option for older projects.
• Future-proof: Aligns with Doctrine’s type system if we expand beyond Laravel. Tradeoffs:
• Last updated in 2019, so compatibility with Laravel 10+ may require vetting.
• If we’re not using Doctrine, this isn’t worth the dependency.
• Laravel 5.x or below is no longer supported."*