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