I have to say, JDBCDataStore has become quite the beast. And its pretty
hard to maintain I must say.
Jody Garnett wrote:
> 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.
I would be all for this. It would peel away one layer of abstraction
which would make the datastore easier to follow.
>
> 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
>
> !DSPAM:1004,44e46bdf129702095110867!
>
--
Justin Deoliveira
The Open Planning Project
[EMAIL PROTECTED]
-------------------------------------------------------------------------
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
