My rough idea was to choose between PostGIS and Oracle (whatever would get the most interest) and make something good. And then use that as a guideline for rewriting DB2 and others ...
It is a facinating problem, and after spending some time w/ hibernate I can further appricaiate some of the nice things we have done. They do have some nice usability concessions we can pick up on though. Cheers David :-) Jody > 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: [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 > > ------------------------------------------------------------------------- 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
