Motivation: |
DataStore allows access to SimpleFeature, we need to access Feature as well |
|---|---|
Contact: |
|
Tracker: |
http://jira.codehaus.org/browse/GEOT-1701 |
Tagline: |
|
introduce This page represents the current plan; for discussion please check the tracker link above.
Description
This proposal:
- introduces DataAccess as a super class of DataStore
- traditional DataStore methods are maintained; often type narrowing a method in DataAccess
- client code can be written against DataAccess for the general case; DataStore offers more specific that can make use of the SimpleFeature assumption
- this proposal covers a naming convention / design stratagy that can be used for GridAccess as well
Additional information:
Status
Voting took place at today's IRC meeting over the approach #1(Generics + DataStore superclass), see Dry Run at DataAccess+Story for a summary.
- Andrea Aime 0
- Ian Turton
- Justin Deoliveira +1
- Jody Garnett +1
- Martin Desruisseaux +1
- Simone Giannecchini +1
Tasks
|
no progress |
|
done |
|
impeded |
|
lack mandate/funds/time |
|
volunteer needed |
|---|
Introduce DataAccess level classes- Allow DataStore level classes to extend; patching up implementations as needed
- Update and test GeoServer
- Update and test uDig (and axios community edit tools)
- Update the user guide
API Changes
The API changes needed are minimal and respect the current interfaces and behaviour. The general strategy is to pull up the common methods from DataStore to a superclass and parametrize as per the Feature and FeatureType flavor they use.
BEFORE
AFTER
BEFORE
AFTER
Documentation Changes
- Developers Guide will need a section on adding a DataAccess api that has the right feel
- Data Module from the Module matrix page
- Upgrade to 2.5
- http://svn.geotools.org/geotools/trunk/gt/demo/example/
- Home
- Home
Labels