Doctrine2 Spatial Laravel Package

Technical Evaluation

Architecture fit: creof/doctrine2-spatial is not a Laravel-native package. It extends Doctrine DBAL/ORM with spatial column types and SQL functions, so it fits only if the application already uses Doctrine ORM or is willing to introduce Doctrine alongside Eloquent through a bridge such as laravel-doctrine. For a typical Eloquent-first Laravel application, this is an architectural mismatch: spatial types would sit outside the primary ORM, increasing dual-model complexity and reducing developer ergonomics.

Integration feasibility: Feasible for a narrow geospatial domain if the target database is supported and the team can register custom Doctrine types/functions. The package is a library-level integration rather than a Laravel service provider, so configuration, type registration, platform function registration, and migration tooling must be handled by the application. The 2017 release date and Doctrine 2-era assumptions are the main feasibility constraints.

Technical risk: High. The package is effectively unmaintained, with likely compatibility gaps against modern PHP, Laravel, Doctrine DBAL/ORM, and PHP 8+ type systems. Risks include dependency resolution conflicts, missing platform functions, SRID/geometry serialization issues, and breakage during framework upgrades. The 273-star count suggests niche but non-trivial usage; however, low release recency and unknown repository status weaken confidence.

Key questions:

• Does the application already use Doctrine ORM, or is this being considered for an Eloquent-first Laravel app?
• Which database and spatial extension are required: MySQL 5.7/8, MariaDB, PostgreSQL/PostGIS, SQL Server, or SQLite?
• Which Laravel, PHP, Doctrine DBAL, and Doctrine ORM versions must be supported?
• Are spatial types needed in domain entities, or would raw SQL/repository queries be sufficient?
• Is the team prepared to fork, patch, and own the package if upstream is inactive?
• What is the required SRID, geometry/geography, index, and query-function coverage?

Integration Approach

Stack fit: Best fit is Laravel + laravel-doctrine + a spatial database such as PostGIS or MySQL 8. Poor fit is a conventional Eloquent-only Laravel application. If the product only needs distance filters or bounding-box queries, raw SQL with spatial indexes may deliver most value with less integration risk.

Migration path: Start with a proof of concept in a bounded module, not core persistence. Register the package’s custom Doctrine types and platform functions, map one spatial entity, run create/read/update/query tests, and verify generated SQL against the target database. If successful, isolate spatial access behind repositories or domain services so Eloquent and Doctrine boundaries remain explicit.

Compatibility: Treat version pinning as mandatory. Validate the package against the exact Laravel/PHP/Doctrine matrix before adoption. Expect to fork for PHP 8+, DBAL 3/4, attribute mapping, or modern platform support. Avoid adopting it as a transitive dependency without a compatibility test suite.

Sequencing:

1. Confirm geospatial requirements and database platform.
2. Spike with the target Laravel/Doctrine stack and one spatial entity.
3. Validate type conversion, SRID handling, spatial indexes, and query functions.
4. Decide whether to adopt, fork, wrap in custom types, or replace with raw SQL.
5. If adopting, add integration tests, pin dependencies, and document ownership.
6. Roll out to one non-critical feature before expanding to core domain models.

Operational Impact

Maintenance: High ownership burden. The package’s last release in 2017 means the team should assume fork-and-maintain responsibility. Budget for dependency upgrades, PHP compatibility patches, Doctrine API changes, and database-platform fixes. This is not a “composer require and forget” dependency.

Support: Community-only, with no vendor SLA and uncertain upstream activity. Internal documentation, examples, and runbooks will be necessary. The TPM should identify a named maintainer and escalation path before production use.

Scaling: The package itself does little for scale; performance depends on database spatial indexes, query design, SRID consistency, and ORM hydration costs. Spatial indexes and query plans must be validated under realistic data volumes. ORM abstraction may obscure expensive spatial queries, so repository-level query review is required.

Failure modes: Likely failures include composer dependency conflicts, unsupported Doctrine DBAL versions, missing platform SQL functions, geometry/SRID corruption, silent type conversion errors, schema migration gaps, and breaking changes on Laravel/PHP upgrades. Eloquent/Doctrine dual-stack inconsistencies are also a product-level risk.

Ramp-up: Moderate to high. Developers need Doctrine ORM familiarity plus geospatial database knowledge. A reasonable ramp-up is a short spike for a senior engineer, followed by integration tests and documentation. For an Eloquent-only team, the learning curve is likely not justified unless geospatial capability is a core differentiator.