adding versioning to gt-jdbc-postgis

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

adding versioning to gt-jdbc-postgis

walterdeane
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: adding versioning to gt-jdbc-postgis

walterdeane
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.

On Mon, Dec 13, 2010 at 12:42 PM, Walter Deane <[hidden email]> 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


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: adding versioning to gt-jdbc-postgis

geowolf
On Tue, Dec 14, 2010 at 6:34 AM, Walter Deane <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: adding versioning to gt-jdbc-postgis

jody.garnett
In reply to this post by walterdeane
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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: adding versioning to gt-jdbc-postgis

walterdeane
In reply to this post by geowolf
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.

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. 

How does this sound as an approach? 



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: adding versioning to gt-jdbc-postgis

jody.garnett
On 15/12/2010, at 9:39 AM, Walter Deane wrote:

> Hello Andrea,
>
> 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.
>

Are you extending ContentDatastore a second time then? I don't like the idea of duplicating state information as it caused us some grief previously with the AbstractDataStore implementation.

Are you going to write up a proposal after your exploratory hacking is complete? Perhaps I should just wait while you look at the codebase.

Jody
------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: adding versioning to gt-jdbc-postgis

geowolf
In reply to this post by walterdeane
On Wed, Dec 15, 2010 at 12:39 AM, Walter Deane <[hidden email]> 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

-----------------------------------------------------

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: adding versioning to gt-jdbc-postgis

geowolf
In reply to this post by jody.garnett
On Wed, Dec 15, 2010 at 1:01 AM, Jody Garnett <[hidden email]> wrote:
> On 15/12/2010, at 9:39 AM, Walter Deane wrote:
>
>> Hello Andrea,
>>
>> 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.
>>
>
> Are you extending ContentDatastore a second time then? I don't like the idea of duplicating state information as it caused us some grief previously with the AbstractDataStore implementation.

Doing a wrapper is unavoidable, and the wrapper will have to keep some
state as the view of the feature types
for the outside world is different from the actual structure, so the
wrapper has to keep those mappings and
the "public" feature types as its state.
However I guess one can get away by mostly implementing the DataStore
interface directly and do delegations
to the wrapped store

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: adding versioning to gt-jdbc-postgis

walterdeane
In reply to this post by geowolf
Well guys I have probing around and am starting to come down to a few issues that I thought I would bring up and ask for advice about the best way to handle. 

1. Subclassing of the jdbcdatastore. Since the class is now final i have been looking at making VersionedNGPostgisData store a wrapper class. But that has required me to create methods 
public VersionedNGPostgisDataStore createVersionedDataStoreInternal(JDBCDataStore dataStore, Map params) throws IOException 
and 
public final VersionedNGPostgisDataStore createVersionedDataStore(Map params)    throws IOException
 is that acceptable? These methods would largely replicate the existing functionality of the previous methods but since the JDBCDatastore is final and doesn't return an interface I can't just override the createDataStoreInternal.

2. JDBCVersionedDataState. In the existing versioning classes, the VersionedJdbcTransactionState subclasses org.geotools.data.jdbc.JDBCVersionedDataState and adds functionality for versioning. I wanted to remove as many of the deprecated classes as possible and was going to create a VersionedNGJDBCTransactionState classes that acted as a wrapper for the new org.geotools.jdbc.JDBCVersionedDataState. This class is package scoped so i can't access it. Should i keep the deprecated class or is there any intention to make this a public class?

3. VersionedNGPostgisDataStore.getModifiedFeatureFIDs This is a meaty method that is doing a big chunk of work. I have been trying to convert these classes to the new classes but trying to keep everything fairly close to the original structure where possible. There is one section that I am not sure how to handle in the new api's yet as this is the first time I have looked at the code base.
There are a few lines:
SQLBuilder builder = wrapped.getSqlBuilder(typeName);
        Filter preFilter = builder.getPreQueryFilter(filter);
        Filter postFilter = builder.getPostQueryFilter(filter);

that split the filter into the prequery and postquery filters. The SQLBuilder is no longer used and i am not sure how (or if) this is done in the new ng jdbc classes. These filters are then used further down the page. It may be that all of this code would be handled completely differently now but I don't have a clue atm.

Thanks for any guidance.
Walter Deane
LISAsoft

I am currently working in the 2.6.5 branch. 

On Thu, Dec 16, 2010 at 9:57 AM, Walter Deane <[hidden email]> wrote:

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

What i have done so far in this regard was subclass the  PostgisNGDataStoreFactory  as  VersionedNGPostgisDataStoreFactory. VersionedNGPostgisDataStoreFactory uses its super class to be build a datastore and myVersionedNGDataStore has a single constructor that takes a JDBCDataStore. I decided not to have the VersionedNGDataStore create its internal datastore. it didnt feel clean to me to have the VersionedNGDataStore calling the super class of the factory that was instantiating it to populate itself. Also i think that it will better convey the fact that it is a wrapper rather than a super class in the api. 

The VersionedNGDataStore is the class that holds the VersionedJdbcTransactionState and will have the methods for managing versioned Fids. Still not sure if there is a need for multiple fid handlers in the new api if so then i might refactor out. So far it looks like this eliminates the need for all of the wrapped/wrapping classes which will make the source a little easier to follow for simple folk like myself.

 Walter Deane



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Reply | Threaded
Open this post in threaded view
|

Re: adding versioning to gt-jdbc-postgis

jody.garnett
In general we try and lock things down until. There is a need. You could make an API change request: I would recommend sorting out a new interface and package visible subclass in the jdbc module rather than opening up completely. 


On 21/12/2010, at 3:40 PM, Walter Deane <[hidden email]> wrote:

Well guys I have probing around and am starting to come down to a few issues that I thought I would bring up and ask for advice about the best way to handle. 

1. Subclassing of the jdbcdatastore. Since the class is now final i have been looking at making VersionedNGPostgisData store a wrapper class. But that has required me to create methods 
public VersionedNGPostgisDataStore createVersionedDataStoreInternal(JDBCDataStore dataStore, Map params) throws IOException 
and 
public final VersionedNGPostgisDataStore createVersionedDataStore(Map params)    throws IOException
 is that acceptable? These methods would largely replicate the existing functionality of the previous methods but since the JDBCDatastore is final and doesn't return an interface I can't just override the createDataStoreInternal.

2. JDBCVersionedDataState. In the existing versioning classes, the VersionedJdbcTransactionState subclasses org.geotools.data.jdbc.JDBCVersionedDataState and adds functionality for versioning. I wanted to remove as many of the deprecated classes as possible and was going to create a VersionedNGJDBCTransactionState classes that acted as a wrapper for the new org.geotools.jdbc.JDBCVersionedDataState. This class is package scoped so i can't access it. Should i keep the deprecated class or is there any intention to make this a public class?

3. VersionedNGPostgisDataStore.getModifiedFeatureFIDs This is a meaty method that is doing a big chunk of work. I have been trying to convert these classes to the new classes but trying to keep everything fairly close to the original structure where possible. There is one section that I am not sure how to handle in the new api's yet as this is the first time I have looked at the code base.
There are a few lines:
SQLBuilder builder = wrapped.getSqlBuilder(typeName);
        Filter preFilter = builder.getPreQueryFilter(filter);
        Filter postFilter = builder.getPostQueryFilter(filter);

that split the filter into the prequery and postquery filters. The SQLBuilder is no longer used and i am not sure how (or if) this is done in the new ng jdbc classes. These filters are then used further down the page. It may be that all of this code would be handled completely differently now but I don't have a clue atm.

Thanks for any guidance.
Walter Deane
LISAsoft

I am currently working in the 2.6.5 branch. 

On Thu, Dec 16, 2010 at 9:57 AM, Walter Deane <[hidden email]> wrote:

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

What i have done so far in this regard was subclass the  PostgisNGDataStoreFactory  as  VersionedNGPostgisDataStoreFactory. VersionedNGPostgisDataStoreFactory uses its super class to be build a datastore and myVersionedNGDataStore has a single constructor that takes a JDBCDataStore. I decided not to have the VersionedNGDataStore create its internal datastore. it didnt feel clean to me to have the VersionedNGDataStore calling the super class of the factory that was instantiating it to populate itself. Also i think that it will better convey the fact that it is a wrapper rather than a super class in the api. 

The VersionedNGDataStore is the class that holds the VersionedJdbcTransactionState and will have the methods for managing versioned Fids. Still not sure if there is a need for multiple fid handlers in the new api if so then i might refactor out. So far it looks like this eliminates the need for all of the wrapped/wrapping classes which will make the source a little easier to follow for simple folk like myself.

 Walter Deane


------------------------------------------------------------------------------
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel