[Geotools-devel] DataSource Branch updated

[Jody G. <jga...@re...>]

I have added the first cut of a modified DataSource API to the data-exp 
branch (in core).
Rather than reuse the name DataSource (making conversation difficult) 
have have invented distinct names as required.  I will try and produce a 
postgis and memory implementation to go along with this api so we can 
have a sensible discussion.

Recently committed:
DataSource - the simplest subset of DataSource (getFeatures and so on)
DataStore - extends DataSource to add modification (addFeatures and so on)
DataLocking - extends DataStore to add feature locking

Slotting into this API is:
FeatureLock - from the existing locking api
Transaction - the point of this exercise

For those that were not part of the IRC a word about the Transaction Class:

DataStore has a setTransaction( Transaction method ) which operates in a 
manner similar to setAutoCommitMode, getTransaction() can be used to 
access the usual raft of commit() and rollback() and locking functions.

DataSource.setAutoCommit( true ) becomes DataStore.setTransaction( new 
DefaultTransaction() )
DataSource.commit() becomes DataStore.getTransaction().commit()
DataSource.rollback() becomes DataStore.getTransaction().rollback()

Transaction also accepts the authorization IDs required for the Locking API.

Using this design we should be able to replace the 
getTransactionConnection() as implemented by both JDBC DataSources to 
(Connection) getTransaction().getState( "jdbc url"), allowing all 
modifications to several tables in the same database to all share a 
single JDBC connection.

When a Transaction is not used a DataSource.getFeatures(*) method will 
use a connection from the ConnectionPool like normal.

For DataSources that need to support Transactions, or Locks using in 
memory data structures, they can externalize the Handling of this data 
structure to the  Transaction with setState( this ) and getState( this ).

Examples of this would be:
- MemoryFeatureStore keeping a FeatureCollection in the Transaction 
object to perform modifications and queries against.
- A Shapefile keeping a filename to work against during the Transaction 
(it can duplicate the original at the start of the Transaction and 
Replace the original at during a commit).

I may need to supply a useful Plug-In Interface for DataStores to 
provide the Transaction Class some knowledge of how to interact with the 
externalized State.

Something along the lines of:

interface TransactionState {
    void commit();
    void rollback();
}

With DataStore providing something that works for them (illustrative only):

JDBCTransactionState {
    Connection conn;
    void commit(){ conn.commit(); }
    void rollback(){ conn.rollback(); }
}

MemoryTransactionState {
    FeatureCollection features;
    void commit(){
        MemoryDataStore.this.features.removeAll();
        MemoryDataStore.this.features.addAll( features );
    }
    void commit(){
        features.removeAll();
        features.addAll( MemoryDataStore.this.features );
    }
}

Comments, and so on are more than welcome!

Jody