OK, changed it. I'm not a spatialite user, but I'll try to configure a database
to do more tests.
I also upgraded postgresql and sqlite jdbc drivers.
As far as I understood, the spatialite database has no date type and getting
date or timestamp from it is still very hazardeous
(https://github.com/xerial/sqlite-jdbc/issues/88). I think the fallback to
FlexDateParser is necessary for this reason, but it may lead to a performance
regression except if your patch on the FlexDateParser can really place the good
parser at first place (until now, I could not measure the impact of you change
as the first save operation from a Dataset made of FlexibleFeatures was still
long) .
For now :
r 6383 just restored the read of dates from Database as java.util.Date
r 6384 restored the fallback to the possibly slow FlexibleDateParser in case
the database driver fails to read the date with rs.getTimestamp method
---
** [bugs:#497] Shapefile export slowed down because of FlexibleDateParser**
**Status:** open
**Created:** Mon Aug 17, 2020 11:47 AM UTC by michael michaud
**Last Updated:** Wed Aug 19, 2020 07:45 PM UTC
**Owner:** michael michaud
Exporting a big dataset to shapefile (1 300 000 objets - around 225+115 Mb)
with version 1.15 lasted more than 20 minutes.
Most of the time is used by FlexibleDateParser.parse().
---
Sent from sourceforge.net because jump-pilot-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/jump-pilot/bugs/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/jump-pilot/admin/bugs/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
