Hi all, as some of you may know, the H2 module Justin has been working on has been created to full fill two purposes: - be a H2 datastore (ok, this was obvious) - provide a new set of JDBC datastore base classes that are supposed to be more maintainable compared to the old datastore classes.
Justin can elaborate more on this, but imho the extra maintainability comes from two related items: - the datastore has been developed from a clean slate as opposed to organically grow patch by patch - the architecture is somewhat similar to Hibernate, a set of core classes that are equal between all databases, and one dialect class for each database that factors out the differences (so if we fix a bug or add a capability, we do so for all databases). Now, based on these classes, OpenGeo managed to get a contract to rewrite from scratch the Oracle data store with the objectives of making it more maintainable, faster, and more amenable to supporting 3d data. The datastore will be based on the architecture proposed in the current H2 datastore, preparing the path for an eventual switch of the Postgis and Mysql datastores as well (mysql support being already partially implemented in the current H2 module). The base datastore class will first see some improvements, like full prepared statement support (say bye bye to sql injection attacks) and non serial primary keys support. Once that is done, we'll work on adding Oracle support, experiment with different data transfer technologies (current SDO classes, JGeometry, WKB), and make sure all the bugs reported against the current Oracle datastore do not occur in the new one. At the moment the work is ongoing in the h2 module, that already hosts partial mysql bindings as well, and that is starting to grow a set of oracle bindings. The core of the H2 module is in fact a replacement set of base JDBC datastore classes, designed around an idea siilar to Hibernate: a core set of classes Given this set of modules is going to become a proposed replacement for the existing jdbc modules, we're probably going to setup a proposal when the modules are ready to graduate to supported status. This is eventually going to grow, we should probably create a module group around the new jdbc base class, something like: - jdbc-ng - jdbc-core (base classes and base tests) - jdbc-h2 (h2 datastore) - jdbc-mysql (experimental mysql replacement) - jdbc-oracle (oracle replacement) Those would be a set of unsupported modules, that we'll hopefully manage to graduate soon, especially since maintainership work is supposed to become less of a problem. Suggestions, opinions? Cheers Andrea ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
