MySql 8.0 release issues about doctrine2-spatial HOT 10 OPEN

If process knows which version is running, it can adapt function and prevent users from breaking.

Note that MySQL 5.7 also is aware of the ST_ prefixed functions...

from doctrine2-spatial.

I'm not sure that MySQL is aware for all ST_ prefixed functions. Did you? When I launch test on my repo, with my old MySQL 5.7 server version, test throws exceptions because ST_GeomFromText is unknown. And MySQL8.0 server version throws exception because GeomFromText is unknown.

DQL queries should respect the OGC Standard. So, now, DQL should use prefixed ST_ version. I think its a good strategy to target the OGC Standard with DQL. I already updated the Abstract Platform like in doctrine/dbal. Abstract platform detects the server version and now, the DQL are the same for Postgresql, Mysql5 and Mysql8, but the core of the doctrine spatial lib will create the SQL query with the function known by its server. It will be very easy to deploy solutions for MariaDB and Microsoft SQL Server.

According to the official documentation, ST_GeomFromText should be available in MySQL 5.7:
https://dev.mysql.com/doc/refman/5.7/en/gis-wkt-functions.html#function_st-geomfromtext

from doctrine2-spatial.

Guess a PR would be very welcome 🤓 right @djlambert ?

from doctrine2-spatial.

Related to #190

I think we should proceed, adopt the ST_ prefixed function and tag a new major / breaking release, so no one will get any suprises.

@djlambert still monitoring this library?

from doctrine2-spatial.

PRs are always welcomed. They should include tests to be merged.

from doctrine2-spatial.

@djlambert thanks for the response.

Regarding #196, not sure how this can be tested more explicitly: the current test-set already covers it... right? However the automated tests fail...

from doctrine2-spatial.

I'm searching a way to be compliant with MySQL5.7 and MySQL8.0. If process knows which version is running, it can adapt function and prevent users from breaking. I forked the project last week and I will push a big update tonight to avoid untested functions initially. But the updates which uses protected methods insteadof protected properties open a way to determinates the name of function depending the MySQL server version.

Perhaps, you could have a look on it.

from doctrine2-spatial.

I'm not sure that MySQL is aware for all ST_ prefixed functions. Did you? When I launch test on my repo, with my old MySQL 5.7 server version, test throws exceptions because ST_GeomFromText is unknown. And MySQL8.0 server version throws exception because GeomFromText is unknown.

DQL queries should respect the OGC Standard. So, now, DQL should use prefixed ST_ version. I think its a good strategy to target the OGC Standard with DQL. I already updated the Abstract Platform like in doctrine/dbal. Abstract platform detects the server version and now, the DQL are the same for Postgresql, Mysql5 and Mysql8, but the core of the doctrine spatial lib will create the SQL query with the function known by its server. It will be very easy to deploy solutions for MariaDB and Microsoft SQL Server.

from doctrine2-spatial.

I'm not sure that MySQL is aware for all ST_ prefixed functions. Did you? When I launch test on my repo, with my old MySQL 5.7 server version, test throws exceptions because ST_GeomFromText is unknown. And MySQL8.0 server version throws exception because GeomFromText is unknown.

Aah, no, was not sure as well, that makes it a good thing to have these tests in place 👍

Still on vacation, so this was a quick comment without further research, sorry 😄

Your suggested approach seems very flexible, thumbs up!

from doctrine2-spatial.

Please, release an update to solve this issue

from doctrine2-spatial.