I can do initial experiments over Oracle plugin. Trying to take some ideas from Hibernate to decompose gt-JDBC stone into nice pieces.
Jesse, sure, will add ideas. But my current schedule is quite free for some experiments and I would like to do some stuff right now. Some work before was done myself related to prepared statements and retrieving the data from Oracle and creating a shapefile from resultset. But just because 1 yeah ago I was scared with JDBCDataStore stuff :)) it was done outside OracleDataStore capabilities. Like an extreme programming paradigm - lets try some approaches simultaneously with collaboration for the time being and gather parts together later. That's true - org.geotools.data.jdbc changes + Oracle - is a test concern from my side. It is not affecting any working branches or trunk.. Whenever it is time we can make a branch and upload initial code. I will take into account and investigate all DB plugins to have a whole picture and find a golden middle. The sense that I can "play" with possible variants right now :) Vitali. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:geotools-devel- > [EMAIL PROTECTED] On Behalf Of Jody Garnett > Sent: Thursday, August 17, 2006 6:58 PM > To: David Adler > Cc: 'Jesse Eichar'; Vitali Diatchkov; geotools-devel@lists.sourceforge.net > Subject: Re: [Geotools-devel] org.geotools.data.jdbc revisiting > > 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&kid0709&bid&3057&dat1642 > >> _______________________________________________ > >> 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&kid0709&bid&3057&dat1642 > _______________________________________________ > 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
