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