Heh, so we are not waiting for Jesse before design questions then :-) Interesting that you start from a base of prepared statements, I was thinking of starting from a base of a ResultSets. We need three, optimized, implementations of Feature Collection: - FeatureCollection for all content, bounds and so on come from metadata - FeatureCollection over a result set (ie generated by Filter, SortBy, Join ... aka SQL at the end of the day) - the focus is on data access - FeatureCollection used to lazily wrap WHERE clause so that operations like clear() or update() can be implemented efficiently - the focus is on setting up a SQL statement
And finally we need to think about: - FeatureList - basically a sorted FeatureCollection (not much of an Isssue for SQL), see previous conversations on "paged" content for motivation - RandomAccess a marker interface (for FeatureList or FeatureCollection) indicating that lookup by FeatureID is possible and is O(1) rather then O(N) Cheers, Jody > 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
