- Does creof/doctrine2-spatial work with Laravel out of the box?
- No. It is a Doctrine DBAL/ORM extension for spatial column types and DQL functions, not a Laravel-native package with a service provider. In Laravel you would need Doctrine ORM, often through a bridge such as laravel-doctrine, and you must register the custom types and functions yourself. For an Eloquent-first application this is an architectural mismatch.
- How do I install creof/doctrine2-spatial with Composer?
- You install it with Composer, typically using composer require creof/doctrine2-spatial. Because the last release dates to 2017, expect dependency resolution conflicts against modern PHP, Laravel, and Doctrine DBAL/ORM versions. Pin versions and test the install in an isolated branch before adding it to a real application. Laravel auto-discovery will not configure it for you.
- Which databases does creof/doctrine2-spatial support?
- The package provides spatial support for MySQL and PostgreSQL/PostGIS. That includes geometry column types, spatial indexes, and DQL functions for points, lines, and polygons. You should verify type conversion, SRID handling, index creation, and generated SQL against your exact database version. Do not assume support for SQL Server, SQLite, or other platforms without testing.
- Do I need Doctrine ORM to use this package in Laravel?
- Yes, practically speaking. The package extends Doctrine DBAL/ORM with spatial types and DQL functions, so its value depends on using Doctrine for persistence. Eloquent does not consume Doctrine column types, so a pure Eloquent application would need raw SQL or a separate Doctrine integration. Introducing Doctrine just for spatial data adds dual-ORM complexity.
- Is creof/doctrine2-spatial maintained and safe for production?
- Treat it as high risk. The package is effectively unmaintained, with a 2017 release and likely compatibility gaps against modern PHP, Laravel, and Doctrine versions. Production use means budgeting to fork, patch, and own the code, including dependency upgrades and database-platform fixes. It is not a composer require and forget dependency.
- What Laravel and PHP versions are supported by creof/doctrine2-spatial?
- There is no reliable modern Laravel or PHP version matrix for this package. Its Doctrine 2-era assumptions make compatibility with PHP 8+, DBAL 3/4, and current Laravel releases uncertain. You must validate the exact Laravel, PHP, Doctrine DBAL, and Doctrine ORM combination yourself. Expect to patch or fork for modern type systems and attribute mapping.
- How do I register spatial types and DQL functions with Doctrine?
- You configure the package's custom DBAL types in your Doctrine connection or ORM configuration and register its platform functions so DQL can use spatial operations. Since there is no Laravel service provider, this registration belongs in your Doctrine bootstrap or a custom Laravel service provider. After registration, verify the generated SQL and schema migrations against MySQL or PostGIS. Keep the configuration explicit and covered by tests.
- Can I use creof/doctrine2-spatial alongside Eloquent models?
- Only with clear boundaries. Doctrine and Eloquent are separate persistence layers, so mixing them increases model duplication and developer overhead. Isolate spatial access behind repositories or domain services and avoid mapping the same tables in both ORMs. If you only need distance filters or bounding-box queries, raw SQL with spatial indexes may be simpler and safer.
- What are alternatives to creof/doctrine2-spatial for geospatial Laravel apps?
- For Eloquent-first applications, raw SQL using MySQL spatial functions or PostGIS, combined with proper spatial indexes, often covers distance and bounding-box queries with less integration risk. You can also write custom Doctrine DBAL types or evaluate a maintained geospatial package against your exact stack. If you already use Doctrine, forking and maintaining this package is another option. Choose based on SRID, geometry coverage, and query complexity.
- How should I test a creof/doctrine2-spatial integration before adopting it?
- Start with a proof of concept in a bounded module, not core persistence. Register the custom types and functions, map one spatial entity, and test create, read, update, spatial index, SRID, and DQL function behavior against your target database. Add integration tests that inspect generated SQL and run on the exact Laravel, PHP, and Doctrine versions you plan to support. Roll out to one non-critical feature before expanding to core domain models.