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.
SQLExecutor.java
Description: Binary data
------------------------------------------------------------------------- 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
