If it helps I have permission to make a "ext/oracle" module in order to try these experiments in - it would not be included with the release until ready. I started this on geotools 2.2.x but lost my mandate and deleted the work. The oracle module maintainer would also like us to make use of the sdoapi.jar (and has assurances the api will not vanish), given that our SDO.java is now included in JTS we presented with a number of alternatives to maintaining our own SDO_GEOMETRY Struct parsing code.
Jody > 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; [email protected] >> 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; [email protected] >>>>> 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 >>>> [email protected] >>>> 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 >> [email protected] >> 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
