From: Andrea A. <and...@ge...> - 2010-12-15 07:35:12
|
On Wed, Dec 15, 2010 at 12:39 AM, Walter Deane <wal...@gm...> wrote: > Hello Andrea, > We chatted a few times last year in regard to this module. I work at > LISAsoft with Jody and Mark. I have been going through the versioning code > and both versions of the JDBC implementation and working out a strategy for > implementing versioning with the ngdatastore. > I know there is a process of proposals for changes to the classes, but I am > coding to learn at the moment. Hopefully it will be an acceptable solution > when I finished. I have started with adopting your original structure and > classes where possible but changing the names when necessary to reflect the > next generation implementation. (e.g. VersionedPostgisDataStore > becomes VersionedNGPostgisDataStore). Hopefully most of the top level > classes will conform to the same interface as the old classes so that it > will be a simple update in GeoServer. But I wont be breaking any existing > classes and will reuse as many as possible. > The big change that I am looking at is the fact that JDBCDatastore is final > now, so I have altered VersionedNGPostgisDataStore to act as a wrapper > directly for the JDBCDataStore and have moved some of the bits from the > Wrapped class there and am trying to eliminate the need for the > wrapped/wrapping classes entirely. Not sure at what point this approach > might cause problems but if any pop up I should see them in the next day as > i get deeper. I am trying to keep as close your existing structure as > possible so that it will fit into the geotools codebase and be easier for > everyone to follow. Yeah, the versioning store should be a wrapper around a JDBCDataStore, since as you noticed it's impossible to extend it. I guess the wrapper should also build the JDBCDataStore itself, as that provides an occasion to pass in a SQLDialect. Which, I guess, might be either a subclass or again a wrapper around the basic dialect > By keeping most of the same interfaces I think the test classes should port > well also but the code isn't finished enough to compile yet so I will look > at that soon. > As far as the FIDmapper goes the ngjdbc version seems to handle the fid now > except in a few cases with filtering, i believe. I was going to rely on that > and move the minor handling of the the versioning fids in > to VersionedNGPostgisDataStore. Most of the functionality performed by the > SqlBuilder in the versioning classes that I have seen so far seems to be > possible using the new SQLDialect methods. So I have been recoding and > trying to remove as many ties to FidMappers as possible since they are > deprecated. > As far as the different types of FIDMappers defined in the original > implementation have they been phased out? The JDBCDatastore uses primary key > columns only so it seems like a good simplification and will make what i am > doing feasible with the new classes. Yeah, sound like a plan. Unfortunately I don't remember the details enough to confirm this will work seamlessly, but it seems to me you're headed in the right direction. Take care of the tests in both gt2 and geoserver, they may be a guiding light in the porting/upgrade process. 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 ----------------------------------------------------- |