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: [EMAIL PROTECTED] [mailto:geotools-devel- > [EMAIL PROTECTED] On Behalf Of Jody Garnett > Sent: Thursday, August 17, 2006 4:12 PM > To: Vitali Diatchkov > Cc: Jesse Eichar; geotools-devel@lists.sourceforge.net > 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
