Hi, the shapefile-ng work is nearing completion. I have all the tests passing now (at least, once the transaction stuff for content data store gets in) and the code seems to work, in test harness, for both indexed and non indexed shapefiles.
In particular thanks to content data store this one should support sorting for good. General highlights: - the basic underpinnings (low level readers and writers) are the same as shapefile data store (did not get around to try a cleanup there, and bug reports are piling up, have stop doing R&D and fix at least some of them). - the top level is rewritten to use content data store - there is a single configurable store instead of two (indexed or not) - the non indexed version should be somewhat faster Issues I see in a migration: - not nearly as real world tested as the old code - the old code has a public interface large from here to the moon, with a ton of methods that should have never been made public (lots of methods that were not in the DataStore interface to grab readers and writers for example) - the old code had a billion constructors with all the possible options, the new one has _one_ constructor taking a URL, and then has getters/setters for all the various options (turn off indexing, timezone, charset) - the code is sitting, at least for the moment, in a org.geootools.data.shapefile.ng package Of course migration won't be instant for all that code that used directly the extended api the old store was providing. In any case, I was wondering how to handle the upgrade. Moving the classes in the same package might help the migration, but at the very least I would like to get rid of the "ng" since that's going to become the default thing (if we do another rewrite, are we going to mark it as "aab"? (above and beyond?)). Maybe be consistent with jdbc and move it to org.geotools.shapefile And then what... have the new code pick up the old params in case it's the only one in the classpath, otherwise redirect to the old store? We also need to test it out quite a bit in all the GeoTools code that depends on it (test, image mosaic), in GeoServer and uDig. Still quite a bit of work ahead. Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
