Re: [Geotools-devel] org.geotools.data.jdbc revisiting

[David A. <da...@ri...>]

I have considerable interest in making sure that this is consistent with 
the DB2DataStore.

At 10:30 AM 8/17/2006, Vitali Diatchkov wrote:


>I expected that you will be a person from whom I get a feedback:)
>
>I see you agree that the current JDBC design is worth to be made better. We
>need rich capabilities of OracleDataStore and I can concentrate and devote
>some time for Geotools JDBC stuff to improve that framework. And at least
>set up OracleDataStore with optimized performance based on these
>improvements, rich SELECT capabilities (SortBy, as you mentioned) and full
>INSERT/UPDATE/DELETE/CREATE operations.
>
>Additional enhancements:
>1) SQLEncoder is extended with SortBy interface converting into WHERE clause
>capabilities along with already existing Filter API encoding.
>
>2) Adopt the Hibernate's idea of UserType interface for converting values
>from ResultSet into java data types (as basic as custom - geometry e.g.) and
>back from feature attribute values to objects accepted by ResultSet.
>
>
>My plan is:
>
>1) While I had some experiments with changed classes in
>org.geotools.data.jdbc I suggest for myself to move these changes into
>org.geotools.data.jdbc3, whatever name. This package would contain all
>changed classes from org.geotools.data.jdbc where these changes are needed,
>also new interfaces. A kind of future GeoTools  JDBC API. And continue to
>play with them.
>Whenever you are ready to look and evaluate, I can upload to the special
>branch e.g.
>
>2) I change Oracle plugin as a test case locally with new
>org.geotools.data.jdbc3 architecture.
>
>3) Start from PreparedStatement functionality for Oracle. Create
>OraclePreparedSQLExecutor with Oracle optimizations when they are met and
>possible. Also OraclePreparedSQLEncoder
>
>4) Implement something similar to UserType from Hibernate and use instead
>AttributeIO
>
>4) Look into ResultSet-based modification execution and try for Oracle.
>
>Any advises?
>
>Vitali.
>
> > -----Original Message-----
> > From: geo...@li... [mailto:geotools-devel-
> > bo...@li...] On Behalf Of Jody Garnett
> > Sent: Thursday, August 17, 2006 4:12 PM
> > To: Vitali Diatchkov
> > Cc: Jesse Eichar; geo...@li...
> > Subject: Re: [Geotools-devel] org.geotools.data.jdbc revisiting
> >
> > I had a conversation with Jesse last week about this very topic :-) With
> > several points in common with your proposal, lets follow this up
> > when he comes back from holiday.
> >
> > I do apologize for the state of JDBC DataStore, it was never my
> > intention to have huge superclasses that were so difficult to subclass.
> > Instead I wanted to provide a "toolkit" of small little classes that you
> > could use when making your own DataStore.
> >
> > For an interesting contrast with SQLEncoder you can look to hibernate
> > "dialects" api.
> >
> > Rather then out this functionality based on "encoding" the Filter
> > specification (as is done currently), would like to see us make use of
> > methods on the FeatureCollection interfaces (this allows us to capture
> > constructs beyond what is available in the SQL WHERE clause). As an
> > example look at how sorting is accomplished with
> > a FeatureCollection method.
> >
> > Finally I would like to see the JDBCDataStores *not* use the attributeIO
> > api, name instead make direct use of
> > JDBC ResultsSets (hopefully allowing for random access). Once again look
> > to hibernate UserType construct for an interface
> > mapping from Object to ResultSet on a attribute by attribute basis.
> >
> > Cheers,
> > Jody
> >
> > > Hello!
> > >
>
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>_______________________________________________
>Geotools-devel mailing list
>Geo...@li...
>https://lists.sourceforge.net/lists/listinfo/geotools-devel