Morning Vitali, where would you like to go with this? I recall going over your design and liking your work - I am afraid I contrasted it with the ideas being put together for H2 and we got more feedback on FeatureCollection then your implementation.
I would like to see you start up an unsupported module for this DataStore, eventually moving it up to supported status so it is released with GeoTools. Is this something you are interested in? I agree that the reader/writer approach is not very useful (either as an implementor or as a user). Did you follow the changes to FeatureCollection that were proposed in order to try and make it easier to implement? I would really like your feedback. Jody Vitali Diatchkov wrote: > > As it was mentioned earlier, reader/writer approach is not very useful in > case of features being processed through JDBC. > I had a goal to implement datastore for Oracle Spatial based on GeoTools > architecture and interfaces to be used for direct access to Oracle database > from UDIG. GeoTools' standard implementation is very narrow and not > appropriate for high customization - I mean customization for data model > being used in particular project. > > What is done is not a new Hibernate to bind Feature instances to table rows > in the database. But the idea of "feature binding" is used. > > There are several major parts in the "new" JDBC datastore framework design. > > The part where "feature binding" takes place is in package > org.geotools.data.jdbc.operation. For SELECT/DELETE/INSERT/UPDATE SQL tokens > there are interfaces like SelectJDBCOperation... etc. And there is a > JDBCOperationFactory that creates instances of operations. Implementors of > operation interfaces encapsulate all SQL stuff to process Feature objects > and bind them to the relational representation in the database. > > Feature objects and coming in and out to/from operations and this part of > the framework is responsible for the SQL and real JDBC processing. > > Another part of the framework is AbstractJDBCDataStore class and other > classes around it. AbstractJDBCDataStore mostly contains get/set methods to > configure various factories, builders and providers: > > -JDBCOperationFactory > -JDBCFeatureTypeBuilder > -FIDMapperFactory > -FilterToSQLFactory > -ConnectionProvider > .... > > So, AbstractJDBCDataStore is general enough to let the developer charge its > implementation for the particular database with different factories and > builders that customize the framework for this particular database. > > SQL stuff is far from FeatureStore/FeatureSource/DataStore implementations > and it is located in "operations" part of the framework. > > org.geotools.data.jdbc.prepared - is a general implementation of JDBC > operations that deal with prepared statements of JDBC. > > org.geotools.data.jdbc.type - is a package with classes to handle data types > conversion (AttributeType of the feature <-> JDBC type ). > > JDBCConnectionProvider extracts physical Connection with respect to the > passed transaction object. It does not replace the work what I see in H2 > module of GeoTools 2.5. The work has been done in H2 module related to > getting physical connections from pools should be integrated in this > framework to improve it. But JDBCConnectionProvider is a thing that works > with already created and cached Connections with respect to transaction. > > > For the convenience I merged UDIG UI and Geotools Oracle plugin with all > made changes into one UDIG plugin for testing. To run this stuff it is > necessary manually put Oracle's JDBC driver (ojdbc14.jar) into the lib > folder. > > > Come classes are almost full copies from GeoTools trunk but with some > necessary changes for the framework. The idea is to force this stuff to > work, then make backward improvements in GeoTools trunk if necessary if this > framework would be useful for next JDBC architecture generation. > > > Originally this framework and Oracle implementation was developed for UDIG > 1.1 + GeoTools 2.2.x, but what is available in SVN - is a port for GeoTools > trunk with latest changes in interfaces (like FilterToSQL instead of > SQLEncoder). That's why some things were ported in a dirty way - just force > them to work. And some work is required to bring things to date - I am able > to continue this work for the community at my free time. > > What else.. may be something but later. Jody may be is a person who could > look into this stuff, comment or propose the next steps. > > I tested UDIG trunk + GeoTools trunk + Oracle Spatial 10g that is used in a > production mode right now in projects for our customers. Of course, getting > full functionality of INSERT/UPDATE queries requires some steps at the > client side that is outside of GeoTools framework and more related to > feature types model tuning to create valid Feature instances with acceptable > values of attributes when there are various column restrictions at the data > model in the database. > > Operations part of the framework is optimized for the performance not > validation while our project was implemented in a such way that we guarantee > that Feature instances coming into JDBCFeatureStore are valid and conform > to the database data model - no complex validation - only binding Feature > object to SQL query and execution. This is a white place right now in the > operations framework. It assumes that features are valid and its feature > types match the database data model and feature attribute values are also > valid, etc. > > > SVN: > http://svn.geotools.org/udig/community/vitalus/org.geotools.data.oracle > > > > Vitali. > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
