SLQLite issue

[zmitic]

Is there a way to go around the SQLite limitation? I use it only for fast testing and tests don't even need to cover this value.

The error I get when I try to update schema:

In AbstractSpatialType.php line 235:
                                                      
DBAL platform "sqlite" is not currently supported. 

The only idea I have is to make a Doctrine event that would completely remove it when in test environment but that sounds very wrong.

[Alexandre-T]

This library doesn't support SQLite. I didn't know that SpatiaLite was existing. I'm reading their documentation to analyze how much time is necessary to implement it.

But, currently, this spatial extension can only be used with MySQL and PostgreSQL.

I don't know anything about your environment and your test, but I clearly discourage to use another database engine in test, even if you have functional test in staging step. For my knowledge, could you please tell me if there is a so great difference between "fast test" using sqlite and test with the final database engine?

To answer you: you're using Symfony, did you try to move your geometric declaration in dev/doctrine.yaml and prod/doctrine.yaml. So, as the test/doctrine.yaml won't contain any geometric function, Type::addType won't be called in test environment and it (probably) won't call AbstractSpatialType.

[zmitic]

@Alexandre-T The advantage of this bundle is that it makes a backup of sqlite file before the test, and putting it back later.

did you try to move your geometric declaration

Tried it, didn't work.

But what I am doing now is this:

when@dev:
    parameters:
        point_type_class: 'LongitudeOne\Spatial\DBAL\Types\Geometry\PointType'

when@test:
    parameters:
        point_type_class: 'MyPointType'

and MyPointType extends JsonType. So basically, I am saving coordinates as array and manually create Point object.

Still not working, I have

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

so I guess that Point alone is not enough.

[Alexandre-T]

Thank you for your explanations, I now understand how it may be faster.

In version 3.1, I will add some interface (PointInterface extending SpatialInterface, GeometryInterface extending SpatialInterface , GeographyInterface extending SpatialInterface, etc.), it will be useful for your logic, but I don't know if it will really fix your issue.

Your last try is a very good idea (when@test). This last error comes from Doctrine (not my library), I don't understand why it appears, because it means that your MyPointType isn't loaded.

I read some pages on SpatiaLite, they looks like very similar to PostgreSQL ans PostGis. I will do some test this weekend to implement SqLite.

[zmitic]

@Alexandre-T You are right; error does come from Doctrine when I run schema:update later. But initial creation and fixtures work; I am happy for now.

The trick I used is this:

Click to see

class PointType extends JsonType
{
    /**
     * @psalm-suppress MoreSpecificImplementedParamType
     */
    public function convertToPHPValue($value, AbstractPlatform $platform)
    {
        /** @var ?array{x: float, y: float} $data */
        $data = parent::convertToPHPValue($value, $platform);
        if (null === $data) {
            return null;
        }

        $x = $data['x'];
        $y = $data['y'];

        /** @psalm-suppress TooManyArguments */
        return new Point($x, $y);
    }

    /**
     * @param ?Point $value
     *
     * @psalm-suppress MoreSpecificImplementedParamType
     */
    public function convertToDatabaseValue($value, AbstractPlatform $platform)
    {
        if (!$value) {
            return parent::convertToDatabaseValue(null, $platform);
        }

        return parent::convertToDatabaseValue([
            'x' => $value->getLongitude(),
            'y' => $value->getLatitude(),
        ], $platform);
    }

    public function getName()
    {
        return 'point';
    }

    public function requiresSQLCommentHint(AbstractPlatform $platform)
    {
        return true;
    }

It might give you some ideas on how to go around it; it won't support spatial functions but for quick&dirty (and only that) testing... might be useful.

---

If anything, I would rather have Point class to have a real constructor with $x and $y parameters 😄

[Alexandre-T]

Thanks for the tips.

I do agree about the constructor. It should accept only 2 parameters. In version 3.1 or 3.2 I planed to add a deprecation when you don't use it like a real constructor with two parameters. Then in 4.0, constructor will only accept 2 parameters : $x, $y as it is specified in RFC. Then I would like to create Point3D, with 3 parameters and PointM (2D + time) with 3 parameters and Point3DM with 4 parameters.

I don't close the issue. This week end, I will estimate how many times is needed to be compliant with SpatiaLite. (And I will have a look on your tips)

edit : because of work, I won't be able to test it before the 15th.

[Alexandre-T]

I tested it. It could involve some time to do it. I think it's a very good feature, especially for QGIS projects that store environment in sqlite database. I cannot plan it, yet. Lot of work, but help will be appreciate. If someone want to do it, I can help. PRs are welcome.