Skip to end of metadata
Go to start of metadata


Improve quality and maintainability of jdbc data stores.


Justin Deoliveira



Next generation architecture for JDBC datastores.

This page represents the current plan; for discussion please check the tracker link above.


This proposal presents the plan to use a new set of support classes for jdbc based data stores. The motivation/benefits being:

  • Reduce the work to implement new datastores
  • Cut down code duplication due to copying from PostGIS
  • Increase quality among all database backends including security, perormance, and testing

In the current jdbc data store architecture a set of base classes (JDBCDataStore is subclassed for each implementation. Various methods are overridden to customize for each specific backend database.

In the new architecture, there is a single JDBCDataStore class, and in fact it is marked final to prevent subclassing. To customize for each data base implementation the notion of a "dialect" (taken from the hibernate architecture) is introduced.

The dialect interface encapsulates all the operations specific to a particular database implementation.


Elements of this proposal were committed to 2.6.x (and the former implementation should be slated for retirement in 2.7.x or 2.8.x):

Supported Checklist

Module Rating

Using the 5 start module rating system:

(star) IP Check - Good to go. No missing headers. (tick)

(star) Releasable - No blocking issues in JIRA. (tick)

(star) Used - GeoServer trunk has moved to using jdbc=ng modules (tick)

(star) Optimized - On par with old modules. (tick)

(star) Supported - Well maintained, still lacks some user docs. (error)

Rating = 4/5

Test Coverage

Note: This is somewhat inaccurate since it only shows the test results of the non prepared statement path. So in actuality test coverage is higher. But regardless it meets the requirements.



no progress






lack mandate/funds/time


volunteer needed

  1. API changed based on BEFORE / AFTER (tick)
  2. Module restructuring
  3. Update wiki (both module matrix and upgrade to to 2.5 pages)
  4. Update the user guide (tick)
  5. Update or provided sample code in demo
  6. review user documentation

API Changes

There are no api changes from the client point of view. The dialect api is a private api for developers, not for users. The regular datastore api remains uncahnged.



Documentation Changes

Documentation for JDBC datstores will need to be updated for the new modules. Basically everything under:

Module Changes

Currently all the new code lives in the unsupported module. And all the old code remains in library and plugin:

The following module structure is proposed:

  • No labels