> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:geotools-devel- > [EMAIL PROTECTED] On Behalf Of Rob Atkinson > Sent: Friday, August 17, 2007 2:02 PM > To: Vitali Diatchkov > Cc: 'geotools-devel' > Subject: Re: [Geotools-devel] AbstractJDBCDataStore and its pilot > implementation for Oracle Spatial > > Thanks, I understand I think. > > The question then is whether we can kill two birds with one stone - > improve the JDBC architecture and at the same time upgrade it to use the > GeneralFeature model. Otherwise we risk two significant disruptive > efforts working on incompatible solutions.
+1. > > The other question I have is whether the architecture you are proposing > potentially supports joining multiple result sets into a single feature > - some example of this requirement are: > > * encapsulating another configured feature as a property of a > containing feature - RoadSegment includes two RoadJunction > features as end-points > * joining geometry from a shapefile to data from a JDBC source > * populating multi-valued attributes from different result sets. > This is about complex things , whereas I was thinking about SFM first of all. What I see here. Hibernate do not know a priori about how to bind hierarchy of objects to relational model. We should configure it (through XML or annotations) and charge the framework with such configuration. Is complex feature type a thing that represents such a configuration for feature model? I mean feature type that describes complex entity some of attribute types of which are nested feature types? As I understand this is a complex feature model. I did not follow a lot to complex feature model discussion. But if there is a such configuration (like complex feature type) then there is a way to implement complex features binding to database relational data model. We charge the framework with configuration of complex feature types, binding starts to work. So, as I understand, this is mostly about configuration, how to model complex relationships, then complex features binding implementation may be general enough to work with any general configuration. Like we provide XML schema and XML document begins to be not only text, but structural information for third parties (parsers e.g.) > Possibly this can/should be abstracted to a different level of the > architecture, but keen to see whether you have thought about this at all. When there is no user provided configuration described above, the only SFM is available for JDBC features binding (table to feature type, row to the feature) in automatic way. If there is a general mechanism to model complex relationships then we may implement more complex binding. But I am not aware about complex feature model progress a lot. So, that's why my understanding of these things are intuitive right now. > > Its well accepted that JDBC is in need of a rebuild, I am keen to see we > have a complete set of requirements understood before the redesign. > +1 > > Vitali Diatchkov wrote: > > > >> -----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 > > ------------------------------------------------------------------------- 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
