Hey walter; welcome to GeoTools If you are looking at this as a personal developer we will need to get you to go through the developers guide; and the process to get commit access. In this case aaime is the module maintainer so you will need to collaborate with him (and he is often busy) - there are a number of sections of GeoServer that depend on the versioned postgis api.
I would recommend going through the developers guide (getting commit access; signing code contribution agreement for yourself and your organisation). While you wait you can go over the code base and put together a plan; we have a wiki we generally use for such things; followed up by IRC or email discussion (although andrea and you can sort out what you like). My own thoughts are: - check that the versioned datastore api is a separate interface; refractor GeoServer to use that that if needed; and test - start work on the second datastore implementation (that extends JDBCNG); you will need to add a dependency to the JDBCNG and you may be in for a bit of fun as I believe that implementation is final (with an internal dialect class handling the difference between servers). I am not quite sure how you can extend that to allow for the extra versioned datastore methods? Worst case would involve duplicating the work; best case would be to extend the design. - Idea: you may be able to get away with "wrapping" a JDBCNG DataStore; and thus allow "versioned" to work on any SQL backend; it really depends on how much SQL is allowed by these days. - Check how the dialect code is used to isolate all SQL generation in one spot; something similar will be needed to isolate the SQL used for selecting out versioned feature data. You will find a bit of code duplication here; but it was deemed easier to follow that way. - I would keep the factory in place; so you can practice cutting between the old and the new datastore implementations by changing a connection parameter (unless you and andrea decide the work should be done in a new module?) - you are probably going to submit patches for andrea to review and commit; because this module is used by geoserver we have to be very careful not to break the build for others Jody On 13/12/2010, at 11:42 AM, Walter Deane wrote: > Hey guys, > > I am having a look at the unsupported/postgis-versioned package in version > 2.6.5 and was looking at what would be involved with updating it to work with > gt-jdbc-postgis. I have been going through the code in the new classes and am > a bit confused about the FidMapper classes that have been deprecated and > removed. Most of the reference are removed except for the class > org.geotools.jdbc. JDBCDataStore which still uses > org.geotools.data.jdbc.FilterToSql and passes in a FidMapper. Is this as it > should be? > > Walter Deane > ------------------------------------------------------------------------------ > Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, > new data types, scalar functions, improved concurrency, built-in packages, > OCI, SQL*Plus, data movement tools, best practices and more. > http://p.sf.net/sfu/oracle-sfdev2dev > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ 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
