Hi Vitali - > Hello. I would like to share some news seeing how much JIRA tasks are > created for JDBC module. > Just to let you know we are (all?) reading this email. You have a given us all bunch of information to digest so it will be a bit while we figure it out. I assume you know the drill - this will become a proposal page and so on after we kick it around on email for a bit. > 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). > I think I understand what you are saying: sunburned surveyor and I were kicking a similar idea around on blog pages > 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. > For sure. To be clear the result better darn well not be a reader/writer. It should be a FeatureCollection (over top of a result set random access or forward only as you see fit). Have you looked at the unsupported/h2 experiment where justin is kicking these ideas (and me) very hard? > 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. > Okay you are now on exactly the same page as justin and myself. If you check out H2 you will find that FeatureReader/FeatureWriter is treated as a legacy API that is wrapped over top of a FeatueColleciton iterator. > 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). > I see - interesting. Justin also was forcing me into this approach - he was isolating all JDBC stuff into one class. My intention was to isolate everything into three implementations of FeatureCollection (one representing the entire table, one representing wrapped over a result set, and one just used to hold the where clause.
Let me break your list down according to these three ALL: used to stage up requests against the entire table (using metadata as often as possible) SelectJDBCOperation - would delegate to SelectFeatureCollection with TRUE, most requests such as bounds can be handled by via MetadataJDBCOperation rather than with SelectJDBCOperation UpdateJDBCOperation - would delegate to select feature collection with TRUE DeleteJDBCOperation - would delegat eto select feature collection with TRUE .... SubFeatureCollection: works over a ResultSet (created against a select statement, maybe created in a lazy fashion from Filter and SortBy) SelectJDBCOperation - would be used to produce the ResultSet, if possible the result set would be "kept open" and a random access cursor used to perform such things as fid look ups UpdateJDBCOperation - skip the prepaired statement and just smack the STRUCTS into the result set DeleteJDBCOperation - same deal InsertJDBCOperation - I cannot remember how to add to a result set right now MetaDataJDBCoperation - while size() may be possible, bounds will be more tricky - should be able to fake it if the select statement is a bounding box query CustomJDBCOperation - use the iterator to update the result set in an ad hoc manner SelectFeatureCollection: just focus on the Select statement, possibly defined by Filter and SortBy, used as a staging ground for bulk prepaired statement operations - these are all a match to what you are describing > 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. > Nice work. Can you write this up as a proposal? You may want to grab a spike directory or an unsupported module to try out the ideas. > JDBCConnectionProvider is responsible for getting clean Connection in > context of the current transaction. > Andrea has a proposal on the table for throwing out the ConnectionPool idea and making use of javax.sql.DataSource. Especially since they are a) not written by us and b) can be configured to cache prepaired statements > JDBCFeatureTypeBuilder is responsible for the creation > JDBCfeatureTypeBuilder that is used to create FeatureType from the database > tables, database metadata. > Nice. > AttributeTypeHandler is an interface for converting attribute type values > for to/from prepared objects (like Geometry->STRUCT in case of Oracle). > If possible try and look at hibernate UseType - which can gobble up more than one column when creating compound objects (easy example is Range). > 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. > Sweet; okay I did not understand you had written this puppy already. > 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. > For sure - grab an unsupported module and get the code out there for review. There are some hoops to jump through to roll it into GeoTools (headers, test coverage, user docs etc...). Nice work, Jody ------------------------------------------------------------------------- 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
