Thanks for the method breakdown.... so are you thinking:
XXXXDataStore extends DataStore {
List<String> getVersions(); // some kind of versions that available
FeatureSource getFeatureSource( typeName ); // may return
FeatureVersioning
}
interface FeatureVersioning extends FeatureStore {
String getVersion(); // current version
FeatureCollection getDifferences( String version1, String version2,
Filter)
List<Changes> getLog((version1, version2 filter,users, count);
}
On Wed, Aug 3, 2011 at 3:39 PM, Jody Garnett <[email protected]> wrote:
> 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
