> -----Original Message----- > From: Rob Atkinson [mailto:[EMAIL PROTECTED] > Sent: Friday, August 17, 2007 1:07 PM > To: Vitali Diatchkov > Cc: 'geotools-devel'; 'Jody Garnett'; [EMAIL PROTECTED] > Subject: Re: [Geotools-devel] AbstractJDBCDataStore and its pilot > implementation for Oracle Spatial > > > > 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. > > > > > Are you aware of activities to improve Geotools from a hard-coded > "simple features model" to the "ISO general feature model". The latter > supports properties with complex types, relationships between feature > types and multiple valued properties. > > I would think you can model most objects with this, especially if we > achieve the ultimate goal (IMHO) of being able to bind operations to > feature types, and feature types inherit such behaviours from supertypes. > > Is your need to gain direct access simply to bypass the simple features > model? Or is it to allow injection of operations against features via > SQL statements?
So, the goal was based on project needs and simple feature model is used while there is nothing really special in it: the table represents a feature type and a row with data represents a feature instance. GeoTools 2.2.x at least works only with SFM and what is done is intended for simple feature modeling from data model in the database. Right now the framework just suggests more customizable way to bind features to and from database model because the GT 2.2.x jdbc stuff is not in a very good shape from my point of view. I believe that based on this first step other various ideas may be applied to move the JDBC framework forward. Briefly , I have just separated SQL stuff for simple feature model binding from major GeoTools API interfaces implementations (FeatureStore, DataStore,..) into SQL operations part. More clean way where feature binding is performed. These operations may be called from any place where add/remove/modify/read features actions are needed. The user works with high level API (FeatureStore e.g.) while it delegates real work to low level API (org.geotools.data.jdbc.operations). That was a goal. The low level API should be very optimized for the performance and contain minimum of validations of features against feature types, etc. This is a responsibility of high level API to guarantee that feature is valid, etc. That was an idea. Then I was able to highly customize the OracleDataStore for my project specific data model by overriding low level API (JDBCOperation interfaces, various factories and builders like JDBCFeatureTypeBuilder..). Because in specific projects not all of feature types should be visible, not all attribute types should be included in feature types, etc. To implement new datastore for the new database - most of general classes are the same, but low level API implementation is easily implemented and injected to the implementor of AbstractJDBCDataStore class through "builders, factories, providers". Not really sure , did I answer to your questions, but at least tried to explain what is done. I was not concentrated a lot in complex features investigation. Suspect that implementation complex features for JDBC is a task comparable with Hibernate complexity. > > Rob A > ------------------------------------------------------------------------- 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
