On Tue, Dec 14, 2010 at 6:34 AM, Walter Deane <[email protected]> wrote: > Just a follow up to this i have been going through the FidMapper Classes > that have been deprecated. In the old jdbc classes geotools had the option > for many types of fidmappers in the new JDBCDataStore it is relying on the > primary key of one or more columns. It seems that the complexity has been > removed from FIDs in general and it has a single option. The versioning will > still need to decode and encode a fid a little outside of the datastore to > handle version numbers so i am planning on moving that into static methods > into a new VersionedNGPostgisDataStore class that will wrap a jdbc > datastore. I think there is a minimum amount of work that will need to be > done know that the JDBCDataStore is handling most of the FID work. These > methods can then be used by the > VersionFeatureReader and VersionFeatureWriter class instead of needing a > passed in FidMapper. Hopefully this doesn't break any design conventions for > the geotools libraries.
Hi Walter, I'm the "maintainer" of the postgis-versioned module. Migrating the module to jdbc-ng has been on the todo list for a while, but it's a long undertaking so I was waiting for funding to pop up, or find someone that was willing to do it: I guess the latter happened. Yeah, fid mapping in the versioned store is a tricky story because there is a public and an internal view of what the primary key looks like. FIDMappers as of today cannot really get rid off completely, there is still code using them, the sql builders. The JDBCDataStore.initializeFilterToSQL builds one internally, so maybe it's not necessary to have working ones in other places. Unfortunately I don't have enough time to look into this right now. Mind, the module has quite a bit of tests that also need to be ported over. But they are not all there: in GeoServer there is an extensions, versinoed WFS, and a community module, GSS, GeoServer Synchronization Service, that both depend on the versioning data store. If you want full testing you should also run the test suites in those two modules with the modified store. If instead you don't have time to do that we'll probably have to find some arrangement to avoid throwing away work, like forking off the module you're changing into yet another community module so that GS code can still rely on the old one. Cheers Andrea ----------------------------------------------------- Ing. Andrea Aime Senior Software Engineer GeoSolutions S.A.S. Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584962313 fax: +39 0584962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ----------------------------------------------------- ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
