This is the top-level interface for access to {@code FeatureData}.
Description
The DataAccess interface provides the following information about its contents:
- {@link DataAccess.getInfo()} - information about the file or server itself
- {@link DataAccess.getNames()} - list of the available contents (each is an individual resource)
- {@link DataAccess.getSchema( Name )} - FeatureType describing the information available in the named resource
Contents
You can access the contents of a service or file using getFeatureSource( Name ). Depending the abilities of your implementation and your credentials you will have access to
- {@link FeatureSource}: read-only api similar to the WFS getFeature operations. Please note the reutrned FeatureCollection may be *lazy*; for many implementations no actual access will occur until you use the FetaureCollection for the first time.
- {@link FeatureStore}: read/write api similar to the WFS Transaction operation. Batch changes such as addFeatures, modifyFeatures and removeFeatures are supported.
- {@link FeatureLocking}: concurrency control; the Data Access API is thread safe; one consequence of this is modifications being held up while other threads read the contents. You may wish to Lock a selection of features for your exclusive use. Locks are timed; and will expire after the indicated period.
Please note that all interaction occurs within the context of a Transaction, this facility provides session management and is strongly advised. Please note that your application is responsible for managing its own Transactions; as an example they are often associated with a single Map in a desktop application; or a single session in a J2EE web app.
The use of Transaction.AUTO_COMMIT is suitable for read-only access when you wish to minimize the number of connections in use, when used for writing performance will often be terrible.
Lifecycle
Normal use:
- Connect using a DataAccessFactory.createDataStore using a set of connection parameters
- Application is responsible for holding a single instance to the service or file, DataAccess implementations will hold onto database connections, internal caches and so on - and as such should not be duplicated.
- DataAccess.dispose() is called when the application is shut down
Creation:
- Created using a DataAccessFactory.createNewDataStore using a set of creation parameters
- DataAccess.createSchema( T ) is called to set up the contents
- DataAccess.getFetaureSource( Name ) is called, and FeatureStore.addFeatures( collection ) used to populate the contents
- DataAccess.dispose() is called when the application is shut down
Applications are responsible for holding a single instance to the service or file, The DataAccess implementations will hold onto database connections, internal caches and so on - and as such should not be duplicated.
@see DataStore Subclass restricted to working with simple content
@param < T> Type of Feature Content, may be SimpleFeatureType
@param < F> Feature Content, may be SimpleFetaure
@source $URL$