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
