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.
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.
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.
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.
Rob
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
begin:vcard
fn:Rob Atkinson
n:Atkinson;Rob
org:Social Change Online
email;internet:[EMAIL PROTECTED]
title:Principal Consultant
tel;work:+61 2 42265490
tel;cell:0419 202 973
x-mozilla-html:TRUE
url:http://online.socialchange.net.au
version:2.1
end:vcard
-------------------------------------------------------------------------
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
