O Joy, it gets better.
In MySQL 8 if you store epsg 4326 data you must be wanting to store
geography and not geometry so let's demand that you flip the axis:
https://dba.stackexchange.com/a/242004
and then ofcourse things like this fail (on MySQL 8.0.21)...
SELECT ST_Envelope(ST_GeomFromText('POLYGON ((6 12, 8 14, 6 16, 4 16, 4
14, 6 12))',4326))
with "Nope can't do this"
Seems that in 8 Geography is a new feature and it needs to be shown off...
Mark
On 04-09-2020 15:23, Mark Prins wrote:
Ok, thanks.
I'll get to work on it
Op wo 2 sep. 2020 om 13:57 schreef Nikolaos Pringouris
<nprig...@gmail.com <mailto:nprig...@gmail.com>>:
Hmm probably I have missed/overlooked these 2 functions when adding
support for ST_... functions in geotools 19.x.
In any case as you already mentioned the flag is direct available
there so you easily add support for the corresponding ST_ functions
at that point.
Concerning Mysql v5.5 I think you are right. IMHO there is no need
to further support them in newer versions of geotools.
Στις Τετ, 2 Σεπ 2020 στις 2:36 μ.μ., ο/η mark <mc.pr...@gmail.com
<mailto:mc.pr...@gmail.com>> έγραψε:
On 2020-09-01 19:24, Nikolaos Pringouris wrote:
> Hi All,
>
> A couple of years ago I worked on jdbc-mysql module and
provided support
> for the newly introduced ST_ functions in Mysql5.6 & Mysql
5.7. I think
> these functions are also supported in Mysql8.0 with the same
signature
> so I do not think there is an issue of incompatibility.
the problem is the code uses old/removed functions in several places
If you check the
> Data Store factory for Mysql (MySQLDataStoreFactory) you will
see that
> there is a static function isMySqlVersion56(...) which is
called during
> creation of the dataStore and if figures out that mysql 5.6
or above is
> used in enables enhancedSpatialSupport flag automatically and
the use of
> the corresponding ST_ functions (check also
> visitBinarySpatialOperatorEnhanced(...) function in
MySQLFilterToSQL
> class).
this would/my have worked for 5.7, but not 8 as the old
functions have
been removed, this code:
https://github.com/geotools/geotools/blob/3496184670f6bb5a7b3af877fed3f312ce86f9a2/modules/plugin/jdbc/jdbc-mysql/src/main/java/org/geotools/data/mysql/MySQLDialect.java#L225-L238
simply fails with a database error that function asWKB does not
exist
same for
https://github.com/geotools/geotools/blob/3496184670f6bb5a7b3af877fed3f312ce86f9a2/modules/plugin/jdbc/jdbc-mysql/src/main/java/org/geotools/data/mysql/MySQLDialectPrepared.java#L194-L205
I can add the enhanced flag around those as a quick scan of the
code
seems that it's limited to these instances. maybe this was an
oversight
when a different dev worked on the code and didn't know about
that flag,
(suggesting the design could be improved)
> Of course mysql 8.0 may have additional spatial features (to
be honest I
> am still using version 5.7.x in my geotools related projects)
and
> probably the mysql module can still be improved but I am
pretty sure
> that the module will still be functional when the underline
Mysql DB is
> v8.0 (in addition to 5.5, 5.6, 5.7).
>
I don't see any point in supporting 5.5 (EOL December 2018) as
it is no
longer part of the support matrix, if you want to use an
unsupported
database software you can use an old version of
geotools/geoserver as
well IMO.
5.6 will be EOL in a few months (February, 2021)
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Disclaimer;
This message is just a reflection of what I thought at the time of
sending. The message may contain information that is not intended for
you or that you don't understand.
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
