...
For the 2.2.x branch the data module remainted stable:
- Implementation updated for ResourceCollection
- Implementation provided for FeatureList (a random access api)
2.4.x
Broken out into a seperate module.
...
On the FM branch the following has occured:
- seperated out into a distinct module
- transition to GeoAPI feature model
2.5.x
Introduced DataAccess super class for DataStore and parametrized the FeatureSource/Collection/Reader/Writer interfaces to handle GeoAPI Feature as the general case, and SimpleFeature as a specialization.
...
There are several areas in which the data module can be improved:
- support for "joins" has been attempted several times, most recently on the "complex-features" branch, a standards
compatible way of defining joins can be seen as part of the Catalog 2 specification in which a Query may hold several
filters against different metadata. Starting at the other end of the problem
the "community schema" effort concentrates on mapping the joins needed to fufill a
predefined XML schema. - The exact mechaism for Locking can be improved based on the workflow documented in GeoAPI currently (in which
LockResults are returned at the end of a Commit) - Repository can either be subsumed by Catalog, or can remain as a front end for cross datastore
opperations (such as client side joins and unlocks). It would make sense to have Repository
server as the creator of both Transaction and Locks. - Coverage support should be accessable in a manner similar to DataStore.