org.geotools.data

Interface DataAccessFactory

All Superinterfaces:

Factory

All Known Subinterfaces:

DataStoreFactorySpi, FileDataStoreFactorySpi

All Known Implementing Classes:

AbstractDataStoreFactory, AppSchemaDataAccessFactory, ArcSDEDataStoreFactory, ArcSDEJNDIDataStoreFactory, DB2NGDataStoreFactory, DB2NGJNDIDataStoreFactory, GeoPkgDataStoreFactory, H2DataStoreFactory, H2JNDIDataStoreFactory, JDBCDataStoreFactory, JDBCJNDIDataStoreFactory, JDTSSQLServerJNDIDataStoreFactory, JTDSSqlServerDataStoreFactory, MBTilesDataStoreFactory, MongoDataStoreFactory, MySQLDataStoreFactory, MySQLJNDIDataStoreFactory, NetCDFAuxiliaryStoreFactory, OracleNGDataStoreFactory, OracleNGJNDIDataStoreFactory, OracleNGOCIDataStoreFactory, PostgisNGDataStoreFactory, PostgisNGJNDIDataStoreFactory, PreGeneralizedDataStoreFactory, PropertyDataStoreFactory, SampleDataAccessFactory, ShapefileDataStoreFactory, ShapefileDirectoryFactory, SQLServerDataStoreFactory, SQLServerJNDIDataStoreFactory, TeradataDataStoreFactory, TeradataJNDIDataStoreFactory, WFSDataAccessFactory, WFSDataStoreFactory

public interface DataAccessFactory
extends Factory

Constructs a live DataAccess from a set of connection parameters.

The following example shows how a user might connect to a PostGIS database, and maintain the resulting datastore in a Registry:

 HashMap params = new HashMap();
 params.put("namespace", "leeds");
 params.put("dbtype", "postgis");
 params.put("host","feathers.leeds.ac.uk");
 params.put("port", "5432");
 params.put("database","postgis_test");
 params.put("user","postgis_ro");
 params.put("passwd","postgis_ro");

 DefaultRegistry registry = new DefaultRegistry();
 registry.addDataStore("leeds", params);

 DataStore postgis = registry.getDataStore( "leeds" );
 SimpleFeatureSource = postgis.getFeatureSource( "table" );
 

The required parameters are described by the getParameterInfo() method. Client

Implementation Notes

An instance of this interface should exist for all DataAccess implementations that want to advantage of the dynamic plug-in system. In addition to implementing this interface a DataAccess implementation should provide a services file:

META-INF/services/org.geotools.data.DataAccessFactory

The file should contain a single line which gives the full name of the implementing class.

Example:
e.g. org.geotools.data.mytype.MyTypeDataSourceFacotry

The factories are never called directly by client code, instead the DataStoreFinder class is used.

Author:

Jody Garnett (Refractions Research)

Nested Class Summary

Nested Classes

Modifier and Type	Interface and Description
static class	DataAccessFactory.Param Data class used to capture Parameter requirements.

Method Summary

Modifier and Type	Method and Description
boolean	canProcess(Map<String,Serializable> params) Test to see if this factory is suitable for processing the data pointed to by the params map.
DataAccess<? extends FeatureType,? extends Feature>	createDataStore(Map<String,Serializable> params) Construct a live DataAccess using the connection parameters provided.
String	getDescription() Describe the nature of the datasource constructed by this factory.
String	getDisplayName() Name suitable for display to end user.
DataAccessFactory.Param[]	getParametersInfo() MetaData about the required Parameters (for createDataStore).
boolean	isAvailable() Test to see if the implementation is available for use.

Methods inherited from interface Factory

getImplementationHints

Method Detail

createDataStore

DataAccess<? extends FeatureType,? extends Feature> createDataStore(Map<String,Serializable> params)
                                                             throws IOException

Construct a live DataAccess using the connection parameters provided.

You can think of this class as setting up a connection to the back end data source. The required parameters are described by the getParameterInfo() method.

Magic Params: the following params are magic and are honoured by convention by the GeoServer and uDig application.

• "user": is taken to be the user name
• "passwd": is taken to be the password
• "namespace": is taken to be the namespace prefix (and will be kept in sync with GeoServer namespace management.

When we eventually move over to the use of OpperationalParam we will have to find someway to codify this convention.

Parameters:

params - The full set of information needed to construct a live data store. Typical key values for the map include: url - location of a resource, used by file reading datasources. dbtype - the type of the database to connect to, e.g. postgis, mysql

Returns:

The created DataStore, this may be null if the required resource was not found or if insufficent parameters were given. Note that canProcess() should have returned false if the problem is to do with insuficent parameters.

Throws:

IOException - if there were any problems setting up (creating or connecting) the datasource.

getDisplayName

String getDisplayName()

Name suitable for display to end user.

A non localized display name for this data store type.

Returns:

A short name suitable for display in a user interface.

getDescription

String getDescription()

Describe the nature of the datasource constructed by this factory.

A non localized description of this data store type.

Returns:

A human readable description that is suitable for inclusion in a list of available datasources.

getParametersInfo

DataAccessFactory.Param[] getParametersInfo()

MetaData about the required Parameters (for createDataStore).

Interpretation of FeatureDescriptor values:

• getDisplayName(): Gets the localized display name of this feature.
• getName(): Gets the programmatic name of this feature (used as the key in params)
• getShortDescription(): Gets the short description of this feature.

This should be the same as:

 Object params = factory.getParameters();
 BeanInfo info = getBeanInfo( params );

 return info.getPropertyDescriptors();
 

Returns:

Param array describing the Map for createDataStore

canProcess

boolean canProcess(Map<String,Serializable> params)

Test to see if this factory is suitable for processing the data pointed to by the params map.

If this datasource requires a number of parameters then this mehtod should check that they are all present and that they are all valid. If the datasource is a file reading data source then the extentions or mime types of any files specified should be checked. For example, a Shapefile datasource should check that the url param ends with shp, such tests should be case insensative.

Parameters:

params - The full set of information needed to construct a live data source.

Returns:

booean true if and only if this factory can process the resource indicated by the param set and all the required params are pressent.

isAvailable

boolean isAvailable()

Test to see if the implementation is available for use. This method ensures all the appropriate libraries to construct the DataAccess are available.

Most factories will simply return true as GeoTools will distribute the appropriate libraries. Though it's not a bad idea for DataStoreFactories to check to make sure that the libraries are there.

OracleDataStoreFactory is an example of one that may generally return false, since GeoTools can not distribute the oracle jars. (they must be added by the client.)

One may ask how this is different than canProcess, and basically available is used by the DataStoreFinder getAvailableDataStore method, so that DataStores that can not even be used do not show up as options in gui applications.

Returns:

true if and only if this factory has all the appropriate jars on the classpath to create DataStores.