Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.

This is an RnD page as we explore design ideas for a GeoGIT GeoGit DataStore.

Table of Contents


This page is backed by an implementation on a github branch "markles":


titleOpen Questions
  • Schema Definition (as it changes over time)
  • "Directory" Access is a work in progress (it needs to cover more than just a list of Name; as the names published change over time)
    • Ability to Browse / Explore GeoGIT GeoGit contents prior to checkout
    • We may need a separate data model to track the ResourceIDs
  • Having a lot of trouble wrapping JDBCDataStore cleanly and efficiently



The design of the GeoGIT GeoGit DataStore is pretty straight forward:

  • It extends ContentDatastore
  • It maintains an internal "delegate" DataStore which is used as the "workspace" to hold the current checkout
  • It maintains a GeoGit class and uses it to access the BLOB structures maintained in BerklyDB (or other Key Value database). To make common tasks easier a GeoGitFacade class with utility methods for performing common blobbing tasks (such as access an index BLOB describing the contents).


This section will be filled in with notes on the GeoGitFacade class; currently he design is straight forward.

Code Block
package org.geotools.jdbc.versioning.geogit;

public class GeoGITFacadeGeoGitFacade {      
    public GeoGITFacadeGeoGitFacade(GeoGITGeoGit ggit) {    }    
    protected ObjectId insertAndAdd(Feature f) throws Exception {    }        
    public Feature getFeature(String id){    }           
    public Collection<FeatureType> getFeatureTypes(){        }           
    public Collection<FeatureType> getFeatureTypeForFeature(String featureId, String revisionId){ }    
    protected ObjectId insert(Feature f) throws Exception { }    
    protected void insertAndAdd(Feature... features) throws Exception {  }        
    protected void close() throws Exception {    }    
    protected void insert(Feature... features) throws Exception {    }    
    protected boolean deleteAndAdd(Feature f) throws Exception {    }    
    protected boolean delete(Feature f) throws Exception {    }   
    public String toString() {    }       
    public SimpleFeatureCollection getLog(String fromVersion, String toVersion, FeatureType featureType, Filter filter, Integer maxRows) throws Exception{                   }       
    private SimpleFeature feature(SimpleFeatureType type, String id, Object... values)            throws ParseException {         }        
    private void processFilter(Filter filter, FeatureType featureType, LogOp logOp) throws OperationNotSupportedException {    }    
    public void commit() throws Exception {    }

Director or Index BLOB

GeoGit contents is pretty unstructured (as expected for a pile of BLOBS). We should look into supporting:

  • A spatial index? This is a spatial

DataStore Delegate Design

Walter got a bit of technical direction from Justin Deoliveira / Gabriel Roldán have expressed a strong preference for a "wrapper" approach. Rather than subclassing JDBCDataStore.



The central challenge here is how to reuse the above work; as GeoGitDataStore would like to also make SQL queries and take part in the generation of featureIds; splice in ResourceIds and so on.

Justin Deoliveira has asked that we work in a fork of GeoTools in order to explore options (and then report back on what needs to be changed when merging in the work).

Pure DataStore Wrapper

The goal here would be to define a pure DataStore wrapper that would encode revision+featureid information into the attributes provided by the delegate DataStore (which would be treated as a simple storage of "row sets").


  • Lack of tight integration with SQL Generation may result in inefficient code
  • Need to write delegating implementations for ContentDataStore implementation (and all support classes)

JDBCDataStore Wrapper

Following the example of postgis-versioned a wrapper DataStore is defined to add versioning against a JDBCDataStore.

IJDBCDataStore Interface

Definition of a IJDBCDataStore which is implemented by JDBCDataStore and GeoGITWrappingDataStoreGeoGitWrappingDataStore. This allows classes that previously expected direct access to work with either.


  • The rational behind adding the interface was so that the GeoGITWrappingDatastore GeoGitWrappingDatastore or a separate implementation or direct versioning could still use the existing class structure of JDBC classes (e.g. SqlDialect).
  • The only other option would have been to reimplement the entire module for *gt-jdbc*. This would have resulted in a lot of duplicated classes with only package name changes or with only a redeclaration of a field type. This would have caused a lot more maintaining effort in the long run and was counter to DRY principles.
  • Our intent was to develop a solution that allowed the API to maintain final implementation of existing classes without blowing out the classes.


Code Block
public final class JDBCDataStore extends ContentDataStore implements IJDBCDataStore {
public final class GeoGITDataStoreGeoGitDataStore extends ContentDataStore implements IJDBCDataStore {
  JDBCDataStore delegate;
  GeoGITGeoGit geogit;
  GeoGITDataStoreGeoGitDataStore( GeoGITGeoGit geogit, JDBCDataStore dataStore ){


  • Making more of JDBCDataStore method public
  • Introduction of IJDBCDataStore interfaces gives the API more surface area to maintain
  • The IJDBCDataStore ends up being a grab back of methods at different levels of abstraction (basically a side effect of an implementation issue rather than a clear concept)

SQLDataStore Abstract Class

This is a follow up Idea; which should result in a cleaner implementation of the above approach without introducing an interface (is a bit scary and runs counter to the design goals of JDBCDataStore).


  • Clear migration from existing IJDBCDataStore implementation
  • Clear definition of SQLDataStore as an abstract class
  • Allows JDBCDataStore support classes to maintain their package visibility relationship with SQLDataStore and JDBCDataStore
  • Concepts pulled up into SQLDataStore would be those common to both GeoGITDataStore GeoGitDataStore and JDBCDataStore
  • Can use package visibility to avoid exposing too much to subclasses


  • Large number of classes introduced
  • Still gives more surface area to JDBCDataStore concepts (at least it is still controlled and locked down to GeoGIT and JDBCDataStore)

Second Strategy Object

Another design alternative suggested by Jody Garnett was to extend JDBCDataStore from the inside with a strategy object to sort to how revision information is handled. This could be defined as an RevisionSupport; with a default implementation that encodes revision information into a 'revision' attribute which can be combined with the normal FeatureID.


  • Nobody has been interested or understood this suggestion

getJDBCDataStore Wrapper

One of the smallest changes would be to copy the design of java.sql.Wrapper: