Re: [JPP-Devel] sqlite database

[Michaud Michael]

Ede, Broken tests : my feeling is that FlexibleDateParser is doing too much (more than hundred different formats). Wonder if it wouln't be better to have a parser with less formats (removing ambiguous formats like dd/MM, MM/dd, MM/yy, yy/MM etc.) and add a mechanism to use a user-defined parser where it is needed (we already have one in options panel for table attribute display). We could also add a plugin to change a String attribute to a Date attribute with an ad'hoc parser (most databases have a set of specific functions to handle dates and times)  Yes I saw the code of sqlite driver. Seems that I changed the code from getDate to getTimestamp in 2013 with the following comment : "fix 1472782 : date is now shown with time in attribute table. It is persisted as timestamp in postgis database and jml files, but time part is still lost in shapefiles."  Possible because both sql.Date and sql.Timestamp are subclasses of java.util.Date. Currently, the code is the same for all the drivers. Maybe we can do better using getDate or getTimestamp depending on the jdbc type, but I would wait for an actual problem before modifying this code. The problem I found in sqlite driver is that attributes declared as TIMESTAMP but stored as text does not return java.sql.Timestamp but varchar so that our code just read it as String and store it as AttributeType.STRING (https://github.com/xerial/sqlite-jdbc/issues/532) Michaël envoyé : 23 août 2020 à 12:56 de : edgar.sol...@web.de à : jump-pilot-devel@lists.sourceforge.net objet : Re: [JPP-Devel] sqlite database On 22.08.2020 22:24, Michaud Michael wrote: I reactivated the code parsing Date attributes as dates during data loading. The slowdown observed during saving should be moved to loading, but thanks to Ede's fix, FlexibleDateParser is now much more efficient (exploration to find the right parser is done only once). double-checked the deactivated tests in-between. unfortunately they look valid too me. changing the order /globally/ will lead to wrong detections like the one in the tests. that's only a problem for different datasets, assuming that one dataset/layer will not willy-nilly switch data formats between features. i will change the speedup patch accordingly to keep the default parser as is, but extend it in a way that selectively a parser with caching can be requested. apart from that. Mike. did you check how the jdbc sqlite lib handles date etc. https://github.com/xerial/sqlite-jdbc/blob/master/src/main/java/org/sqlite/jdbc3/JDBC3ResultSet.java#L278 ? are we sure that getTimestamp() suffices and we should not implement the other date/time methods depending on column type or maybe even let the matching JDBC handle it, like ResultSet.getDate() above does it according to the column type? after all the matching JDBC should know best?! ..ede _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel