Hello. I would like to share some news seeing how much JIRA tasks are created for JDBC module.
I have implemented on the top of GeoTools DataStore/Feature API and existing Oracle plugin a new OracleDataStore with a concept of Feature binding (something similar to Hibernate but much more simple and narrow). Briefly to say, we needed direct feature access to Oracle Spatial with good performance using prepared statements with geometries being passed as STRUCT objects (prepared objects), with capabilities and powerful customization of the OracleDataStore implementation, with taking into account a nature and differences of JDBC against standard GeoTools reader/writer architecture. The user API is the same: DataStore/FeatureSource/FeatureStore. But internal implementation gets rid of FeatureWriter approach that is so inconvenient for JDBC and uses a concept of JDBCOperation interface instead of writers. There are several operation interfaces: SelectJDBCOperation UpdateJDBCOperation DeleteJDBCOperation InsertJDBCOpearation MetaDataJDBCOperation CustomJDBCOpearation There is factory interface JDBCOperationFactory that creates instances of underlying operation interfaces and DataStore contains a factory (get/set methods). So, all real JDBC stuff is moved to the implementation of the factory and its set of operations for the particular database (like Oracle). Main datastore class is AbstractJDBCDataStore that contains get/set methods for various factories mostly, like: protected abstract JDBCOperationFactory createOperationFactory(); public final AttributeTypeHandler[] getAttributeTypeHandlers(FeatureTypeInfo featureTypeInfo, AttributeType[] attributeTypes, Connection conn); public JDBCConnectionProvider getConnectionProvider(); public JDBCFeatureTypeBuilder getFeatureTypeBuilder(); public FIDMapperFactory getFIDMapperFactory(); public SQLEncoderFactory getSQLEncoderFactory(); public JDBCDataStoreConfig getConfiguration(); In a result implementation of the JDBC datastore for the particular implementation is concentrated mostly on hacking and customizing factories and objects they return. JDBCConnectionProvider is responsible for getting clean Connection in context of the current transaction. JDBCFeatureTypeBuilder is responsible for the creation JDBCfeatureTypeBuilder that is used to create FeatureType from the database tables, database metadata. AttributeTypeHandler is an interface for converting attribute type values for to/from prepared objects (like Geometry->STRUCT in case of Oracle). Etc... Here are just some words to outline the situation. It is better to see the code and understand these concepts that from my point of view make a progress in GeoTools JDBC datastore implementation process for different databases and application-dependent specific customization on the top of default implementations. We use this new OracleDataStore implementation in a production project for Oracle 10g/9.0 with UDIG platform based application. The datastore is able to INSERT/UPDATE/DELETE/SELECT any type of JTS geometry model through prepared objects converting. Right now the source code is not well commented while the development was in a hurry. But I think we may share this stuff for the community development right now and improve necessary places to align the architecture with lot of improvements at the GeoAPI/GeoTools things. Vitali Diatchkov. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
