[DRAFT] Add spatial types #7096
Conversation
| self::assertSame( | ||
| [ | ||
| 'CREATE TABLE spatial_table (id INT NOT NULL, ' | ||
| . 'location geometry(geometry) NOT NULL, ' | ||
| . 'point_location geometry(point,4326) NOT NULL, ' | ||
| . 'polygon_area geometry(polygon) NOT NULL)', | ||
| ], | ||
| $this->platform->getCreateTableSQL($table), | ||
| ); |
There was a problem hiding this comment.
Please focus on functional tests. The kind of test that you're building here is pretty much worthless because it does not tell us if the SQL actually works when it hits a database.
There was a problem hiding this comment.
Thanks for the feedback! I already had in mind to add functional tests, since they’re definitely the right way to validate the SQL.
Because these tests require PostgreSQL with the PostGIS extension, would you suggest:
- creating a dedicated GitHub workflow (e.g.
postgresql-postgis.yml) that uses thepostgis/postgisimage, or - replacing the current PostgreSQL workflow with that image so that all PostgreSQL jobs run with PostGIS enabled?
I’d be happy to go with whichever approach best fits the project’s CI strategy.
There was a problem hiding this comment.
We need to make sure DBAL still works with Postgres databases that don't have these extensions installed. So it's probably best for now if we add an additional check for Postgres that uses the latest postgis image and leave the other checks as they are.
There was a problem hiding this comment.
@derrabus I’ve added the functional tests as suggested and pushed them. However, I noticed that none of the functional tests actually executed in the PR pipeline — is there something I need to do to make sure they run?
If you already had a chance to take a look, I’d really appreciate some feedback on whether this is heading in the right direction. That way I can adjust before proceeding with support for a second platform (e.g. MySQL).
There was a problem hiding this comment.
As far as I can tell, your new workflows were run: https://github.com/doctrine/dbal/actions/runs/17288021054/job/49069200071?pr=7096
There was a problem hiding this comment.
Yes, I noticed an error in continuous-integration.yml only afterwards. After fixing it, the functional tests were executed correctly.
I have one question regarding the functional tests: in MySQL there is a test case Doctrine\DBAL\Tests\Functional\Schema\MySQLSchemaManagerTest::testColumnIntrospection that attempts to define any type as a column to compare it against the same definition. At the moment, I’ve introduced two types for PostgreSQL/PostGIS, geometry and geography. Since geography is not available in MySQL, the current test setup would fail.
Is this behavior intentional, or would it be acceptable to adjust the tests so that they explicitly check which types are supported on MySQL?
ddegasperi
force-pushed
the
add-spatial-types
branch
from
543f582 to
a35520d
Compare
ddegasperi
force-pushed
the
add-spatial-types
branch
from
a35520d to
4ae5dd5
Compare
Add geometry and geography types for spatial data Introduces new spatial data types for handling geometric and geographic data in database applications. GeometryType handles planar coordinates while GeographyType handles spherical earth coordinates, both using Well-Known Text (WKT) format. This provides foundation for spatial data operations across database platforms that support spatial extensions.
Extends Column and ColumnEditor with geometryType and srid properties to support PostgreSQL's PostGIS spatial types and provides a clean schema API for working with GEOMETRY and GEOGRAPHY columns while maintaining backward compatibility. This builds on the core spatial types implementation to complete the PostgreSQL spatial type support at the schema level.
ddegasperi
force-pushed
the
add-spatial-types
branch
from
4ae5dd5 to
810f526
Compare
This commit adds functional testing for PostGIS spatial types (GEOMETRY and GEOGRAPHY) with schema introspection and CI integration. The implementation leverages PostgreSQL's native type system for introspection, making it compatible with any PostgreSQL instance without requiring PostGIS system tables to be accessible during schema operations.
ddegasperi
force-pushed
the
add-spatial-types
branch
from
810f526 to
86b4b15
Compare
| if (is_string($value)) { | ||
| return $value; | ||
| } |
There was a problem hiding this comment.
Is there any object representation that we could hydrate this value to? If we just pass on the strings we might end up with a leaky abstraction.
There was a problem hiding this comment.
Good point — I agree that passing raw strings would be a leaky abstraction. Since the implementation uses WKT, I could introduce a lightweight WKT value object that wraps and optionally validates the string (e.g. via regexp). This would give us a clear object representation without pulling in a full geometry library. Would this be in line with what you had in mind?
|
Adding spatial index management would be interesting for this PR I think :). For instance: Sources: |
Thanks for the advice — I agree, index management is definitely an important aspect when working with geometry data. I haven’t investigated it in depth yet, but it looks like this might already be supported by specifying the index type. A quick search in the repository shows an |
Summary
This draft PR introduces spatial data type support for DBAL, starting with comprehensive PostgreSQL/PostGIS implementation. The goal is to gather feedback on the API design and approach before extending support to other database platforms.
Core Spatial Types
Types::GEOMETRY) - For planar coordinate systemsTypes::GEOGRAPHY) - For spherical earth coordinatesSchema API Integration
ColumnandColumnEditorwithgeometryTypeandsridpropertiesColumn::editor()->setGeometryType('POINT')->setSrid(4326)What's next