Um? My plan was to make it consistent:
a) FeatureSource
b) FeatureStore
c) FeatureLocking
d) FeatureVersioning
That is the usual deal; grab a FeatureSource and use instance of to check
its capabilities.
Jody
On Wed, Aug 3, 2011 at 3:32 PM, Walter Deane <[email protected]> wrote:
> Hello Devs,
>
> My name is Walter and I work with LISAsoft with Jody. We are looking at
> developing a system that uses feature versioning. Jody asked me to look into
> creating a proposal for a VersionedFeatureStore api and I am trying to learn
> the process for doing this properly. I have had a look at the code base a
> bit and am still familiarising myself with it and have had a bit of a look
> at the old versioned postgis module that is being removed. I had a bit of a
> poke around to see about updating to the new classes and ran into a few
> issues. The new JDBC api's are quite different from the old especially with
> the fact that the DataStore is declared final. So the old process that was
> used is very difficult to port of because of the reliance on the datastore
> in the other classes. I see 2 possible options at first glance to approach
> the issue:
>
> 1 remove the use of final from datastore class. (Which seems to go against
> the direction of the new API's)
> 2 change the api of Datastore to understand versioning and have
> isVersioned() methods and throw UnsupportedOperationExceptions when a
> versioned method is called. Any of the other changes then could be added to
> the SqlDialect subclass.
>
> The second option is kind of a fundemental change in that it assumes that
> versioning is kind of a first class concern which kind of makesense in the
> longterm as api's mature. It paves the way for an easier update of the
> versioned PostGIS also to the new api.
>
> Jody had defined this as VersioningFeatureStore api but is there also a
> reason to implement a VersioningFeatureSource? For read only operations of
> the history.
>
> I imagine the api will be kind of light at the beginning and similar to
> andrea's original efforts.
> getLog((version1, version2 filter,users, count)
> getDifferences(version1, version2 [filter])
> getVersion(string)
> getVersions()
>
> There might be a completely different approach that someone has in mind
> please let me know any suggestions.
>
> Thanks,
> Walter
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Geotools-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
