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!
>
> I would like to share some ideas that I have already implemented on the top
> of GT 2.2.x. It concerns JDBC stuff and OracleDataStore as a framework for
> testing of new architecture.
>
> JDBCDataStore is about reading and writing features from/to database. The
> main problem having been a force to "reinvent the wheel" for me that lot of
> things was just in one place such as JDBC1DataStore with a hard coded
> functionality and hard to be extended to get more complex or DB version/JDBC
> driver/something_else specific functionality. To create one JDBCDataStore or
> JDBCFeatureWriter more? SQL code is everywhere. Each database plugin has its
> own SQL stuff that has no general design and I suppose was implemented just
> as it is.
>
> Here is just some thoughts, I try to generalize what do I need from
> JDBCDataStore, how I see ways to improve, revisit, simplify the
> architecture.
>
> JDBCDataStore functionality is the following:
>
> 1) JDBCDataStore is just about reading and writing features from database
> based on Simple Feature Spec for SQL - simply when the FeatureType comes
> from one table of database. The row of the table is a feature.
> 2) We have SELECT/INSERT/UPDATE/DELETE operations over data in database and
> its pairs for features in context of FeatureSource/FeatureStore interfaces:
> read/add/modify/remove.
> 3) JDBCDataStore is created with credentials: username, passw, db, schema on
> the specified host. All available feature types of JDBCDataStore are matched
> to available tables of the database with specified credentials. The
> FeatureType can be created from metadata requested from particular table and
> cached. FIDMapper interfaces are responsible for mappings between database
> PKs and feature IDs.
> 4) Application developer mostly works with FeatureSource and FeatureStore
> interfaces implemented by JDBCFeatureSource and JDBCFeatureStore. They
> provide basic functionality to read/add/modify/remove features. Behind these
> interfaces the real job is being done to SELECT/INSERT/UPDATE/DELETE
> corresponding rows in database tables.
>
>
> To customize the functionality of 4) related to particular proprietary
> database or application needs more easy way is desired than to go deeply
> into overriding of JDBCDataStore,JDBCFeatureWriter and etc. While the most
> of the things are implemented and work well, it is enough just create couple
> of new interfaces and refactor a bit the code from JDBCDataStore,
> JDBCFeatureWriter, SQLEncoder, etc.
>
> PROPOSALS
>
> 1)
> I suggest to make SQLEncoder more meaningful. It takes the responsibility to
> encode Filter API into WHERE clause of SQL query. Here I don't provide
> implementation and etc, I can provide later, but the idea.
>
> PreparedSQLEncoder extends SQLEncoder{
>
> public Object[] getPreparedObjects()
>
> }
> The basic class for encoding of SQL queries for PreparedStatement.
>
>
> This method returns objects for PreparedStatement to be used in if " ? "
> places have been created during filter encoding. OraclePreparedSQLEncoder,
> for example, can encode GeometryFilter for PreparedStatement. It gives the
> opportunity to create complex geometry based filters, not only BBOX based
> and pass geometry with hundreds of vertices when the text based SQL request
> would crash.. . This functionality of encoding of Filter API and arbitrary
> geometry objects as a parameters to PreparedStatement for Oracle is
> implemented by us. Any complex geometry can be encoded for PreapredStatement
> and passed to query database
>
>
> 2)
> Another improvement is a new SQLExecutor interface that encapsulates all SQL
> executing job. The interface is in attachment. It can be extended by methods
> performing custom SQL operations.
>
> The destination of the interface is to encapsulate all possible SQL stuff
> through set of methods that are easily extended by subclasses for
> customization.
>
>
> 3) Refactor some functionality related to SQL code from JDBCDataStore to
> SQLExecutor.. The particular implementation of JDBCDataStore is responsible
> to create and retrieve SQLExecutor instance:
>
> protected SQLExecutor createSQLExecutor(...);
> public SQLExecutor getSQLExecutor();
>
> 4) Clear up DefaultSQLBuilder and its subclasses for particular databases.
> SQLEncoder must be responsible for encoding parts of SQL query while
> SQLBuilder just create the whole SQL from parts.
> We can have just one general SQLBuilder that calls various methods of passed
> SQLEncoder to encode column names, table names and , of course, Filter API.
>
> 5)
> AttributeIO interface is a good structure to encode attribute values into
> SQL text representation or prepared object and back from ResultSet object to
> feature attribute java class based value. To and from.
> We have BasicAttributeIO for base java data types and custom such as
> SDOAttributeIO for Oracle geometries.
>
> Extend FeatureTypeInfo by helper method to get an array of attribute
> handlers - implementations of AttributeIO - for its FeatureType. Lazily!
> For example, SQLExecutor can request handlers from FeatureTypeInfo during
> inserting, updating - to convert feature attribute values for
> PreparedStatement.
>
>
>
> I tried to describe key features of design being in my mind. I have also
> implemented OracleDataStore2 based on new design and interfaces. Main
> changes are in:
>
> -OraclePreparedSQLEncoder extends PreparedSQLEncoder ( .. extends
> SQLEncoder).
> -OracleSQLExecutor extends PreparedSQLExecutor (extends AbstractSQLExecutor
> (implements SQLExecutor))
> -JDBCDataStore3 extends JDBC1DataStore (with all overridden methods with
> necessary changes)
> -JDBCFeatureWriter3 that uses capabilities of SQLExecutor.
>
>
> The letter is quite long, I would like to discuss details and get a feedback
> - are these changes worth to be considering?
> It is just my view at the problem and I really happy to see that it works
> and looks much more clear for the developer, at least for me, anyway
> everything is subjective of course:)
>
> Regards to the community,
> Vitali Diatchkov.
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
