Unknown database type "geometry" requested, Doctrine\DBAL\Platforms\PostgreSQL120Platform may not support it.

[Kinqdos]

Hello there I am trying to use the PostGIS types. Especially the type geometry. I use symfony and added the following to the doctrine.yaml:

doctrine:
...
        types:
            geometry: MartinGeorgiev\Doctrine\DBAL\Types\Geometry

then a I added a column with

    #[ORM\Column(type: 'geometry', nullable: true)]
    public ?WktSpatialData $coordinates = null;

but when I run php bin/console schema:update --dump-sql I get the following error

/var/www/html # bin/console doc:schema:update --dump-sql

In AbstractPlatform.php line 408:
                                                                                                                 
  Unknown database type "geometry" requested, Doctrine\DBAL\Platforms\PostgreSQL120Platform may not support it.  
                                                                                                                 

doctrine:schema:update [--em EM] [--complete] [--dump-sql] [-f|--force]

Additionally I want to ask, if there is a way to specify this type a bit more. In raw sql I want geometry(Point, 4326). But I did not find any options for something like this.

[martin-georgiev]

@coderabbitai - can you advise on this?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Find README and documentation files
fd -t f 'README|CHANGELOG|UPGRADE' -x cat {}

# Find the Geometry type implementation
fd -t f 'Geometry.php' -x cat {}

# Search for type registration examples in documentation or tests
rg -n -C5 'registerType|addType|geometry'

# Look for configuration examples
fd -t f -e yaml -e yml | head -20 | xargs cat

Length of output: 265820

---

🏁 Script executed:

#!/bin/bash
# Read the Symfony integration documentation
cat docs/INTEGRATING-WITH-SYMFONY.md

# Search for geometry type registration examples in documentation
rg -n -C5 "geometry.*Type::addType|dbal.*types.*geometry" docs/

# Look for any YAML configuration examples
rg -n -C10 "doctrine:" -g "*.md" docs/

Length of output: 29202

---

@martin-georgiev, the issue is that your configuration is incomplete. You need to add the mapping_types section in addition to the types section. Here's the complete configuration:

# config/packages/doctrine.yaml
doctrine:
    dbal:
        # Register the custom type
        types:
            geometry: MartinGeorgiev\Doctrine\DBAL\Types\Geometry
        
        # Add the mapping - this is what's missing!
        connections:
            default:
                mapping_types:
                    geometry: geometry
                    _geometry: geometry  # PostgreSQL array type

The mapping_types section tells Doctrine how to map PostgreSQL's native geometry type to your registered DBAL type. Without this, Doctrine doesn't recognize the PostgreSQL type when reading from the database.

Using geometry(Point, 4326) Specification

To specify the exact geometry type and SRID like geometry(Point, 4326), you need to use the columnDefinition option in your ORM annotation:

use Doctrine\ORM\Mapping as ORM;
use MartinGeorgiev\Doctrine\DBAL\Types\ValueObject\WktSpatialData;

class YourEntity
{
    #[ORM\Column(type: 'geometry', nullable: true, options: ['columnDefinition' => 'geometry(Point, 4326)'])]
    public ?WktSpatialData $coordinates = null;
}

Or if you're using XML/YAML mapping:

# config/doctrine/YourEntity.orm.yml
App\Entity\YourEntity:
    type: entity
    fields:
        coordinates:
            type: geometry
            nullable: true
            options:
                columnDefinition: 'geometry(Point, 4326)'

Important Notes:

1. When using columnDefinition, Doctrine will use your exact SQL definition, so migrations and schema updates will respect the Point, 4326 constraints.

2. The WktSpatialData value object from this package can handle any geometry type (Point, LineString, Polygon, etc.) and optional SRID, so it works perfectly with your constrained column.

3. After making these configuration changes, clear your cache:

   php bin/console cache:clear

This should resolve both issues: the "Unknown database type" error and allow you to specify the exact geometry type with SRID.

[Kinqdos]

Seems to work now, but wouldnt it be better to specify both of them in the GeometryType class? getMappingTypes can be specified there and Point as well as 4326 could be separate options. So that the GeometryType class build the sql type definition

[martin-georgiev]

I'm not sure I understand your proposal properly. Please visualise with code.

[Kinqdos]

Sure the postgres type for geometry is geometry([geometry_type][, srid][, dimension]) so in doctrine I would represent it as this:

#[ORM\Column(type: 'geometry', nullable: true, options: ["geometryType" => GeometryType::POINT, "srid" => 4326, "dimension" => 2])]
public ?WktSpatialData $coordinates = null;

And for the mapping types, I would simply add this to Geometry.php

    public function getMappedDatabaseTypes(AbstractPlatform $platform): array
    {
        return [self::TYPE_NAME];
    }

P.S: I guess something similar would apply for Geography

[Kinqdos]

Also why has WktSpatialData a private constructor? It would make it way more safe to create SpatialData when I can do this:

$this->coordinates = new WktSpatialData(4326, GeometryType::POINT, "$lon $lat");

[martin-georgiev]

Sure the postgres type for geometry is geometry([geometry_type][, srid][, dimension]) so in doctrine I would represent it as this:

#[ORM\Column(type: 'geometry', nullable: true, options: ["geometryType" => GeometryType::POINT, "srid" => 4326, "dimension" => 2])]
public ?WktSpatialData $coordinates = null;
And for the mapping types, I would simply add this to Geometry.php

public function getMappedDatabaseTypes(AbstractPlatform $platform): array
{
    return [self::TYPE_NAME];
}

P.S: I guess something similar would apply for Geography

I still don't understand your proposal. It will help when you can illustrate side-by-side with code what you have to do right now, and how you want it to look going forward.

[Kinqdos]

Okay first of all, adding the function getMappedDatabaseTypes to the geometry and geography type will completely eliminate the need for adding this config section into the doctrine.yaml:

# config/packages/doctrine.yaml
doctrine:
    dbal:
        connections:
            default:
                mapping_types:
                    geometry: geometry

Regarding the second proposal with the column options. This is more like a quality of live improvement. Here you can see side by side whats the difference:

// Old syntax
#[ORM\Column(type: 'geometry', nullable: true, options: ['columnDefinition' => 'geometry(Point, 4326)'])]
public ?WktSpatialData $coordinates = null;

// New syntax
#[ORM\Column(type: 'geometry', nullable: true, options: ["geometryType" => GeometryType::POINT, "srid" => 4326, "dimension" => 2])]
public ?WktSpatialData $coordinates = null;

I hope this helps

[martin-georgiev]

I get your idea now.

Pros:

• More type-safe (using enum instead of string)
• Better IDE autocomplete
• Cleaner separation of concerns
• Follows the principle of not using raw SQL strings

Cons:

• Requires implementing getSQLDeclaration() to parse these options and build the column definition
• Adds complexity to the type class
• PostgreSQL's geometry type syntax is flexible: geometry, geometry(Point), geometry(Point, 4326), geometry(PointZ, 4326) - supporting all variations could be complex and not necessarily backwards compatible
• The current columnDefinition approach is already standard Doctrine practice and gives users complete control
• May need to handle edge cases and validation

In conclusion, your suggestion is a "nice to have" but not essential. The current columnDefinition approach works fine and is explicit.