archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joakim Erdfelt <joa...@erdfelt.com>
Subject Archiva Database future.
Date Fri, 09 Mar 2007 15:39:15 GMT
Databases in Archiva.

I need *desperately* to create a proper database for Archiva. Relying on
the Lucene database for all things in Archiva is not cutting it.

But I'm waffling on the database O/RM technology to use.

Here some Archiva requirements for the O/RM db technology.

 1) Need to be able to handle objects managed outside of Archiva.
 2) Need to be able to work with objects managed by Archiva.
 3) Needs to work with objects in without enhancements by O/RM.
 4) Needs to support a wide variety of JDBC datasources.
 5) Needs to be ASL license compatible.
 6) Needs to be Open Source.
 7) Need ability to upgrade schema of previously installed Archiva.
 8) Needs to be quick.
 9) Need to be active and support project.
10) Need to support arbitrary lookups across DB tables for reporting
    reasons.

So, when I looked at the technologies out there, this is what I see.

JPOX: Violates #3, #7, #8, #10.
Hibernate: Violates #3, #5, #7, #10
OJB: Violates #3, #7
OpenJPA: Violates #3, #7, #10
iBatis: --

The problem I have with most of the O/RM technologies are around #3.
The long term plans of Archiva are to create supporting technologies
around the XML-RPC interface to the data that Archiva is tracking.
Having enhanced objects would cause the clients to Archiva to also have
these enhanced classes as well as the O/RM supporting jars.  An
unacceptable situation.

Another big concern is #7 or how to upgrade the database schema between
archiva releases.  Most of the O/RM technologies above do not make it
clear how they do that.  So I dinged them.  iBatis on the other hand makes
it extremely clear.  It doesn't manage the Table creation.  The developer
does it.

The last concern is #10, or how well the O/RM technology can deal with
arbitrary and dynamic lookups into the tables without working with
the objects.  Such as the needs of a reporting system.  I would like
to hook up the database tables to the various reporting libraries
and presentation widgets without having to worry about those queries
being invalidated by changes made to the schema by the O/RM technology.
One Note, all of the reporting usage patterns against the database that
I see are read-only in nature.

  The process I am proposing is to use modello and ibatis.

  * Create our archiva-model using modello.
  * Generate java files for model definition.
  * Generate Create Table sqlMap.xml files.
    - One for each database type (hsqldb, derby, mysql, oracle, etc...)
    - Only for version 1.0.0 in modello model.
  * Generate Update Table sqlMap.xml files.
    - One for each database type (hsqldb, derby, mysql, oracle, etc...)
    - For each versions above 1.0.0 in modello model.
  * Generate CRUD sqlMap.xml files.
    - One for each database type (hsqldb, derby, mysql, oracle, etc...)
    - One for each object in modello model.
  * Generate java source for table version. (to aide in upgrade logic)
  * Generate java source for ibatis DAO layer.
    - One for each object in modello model.
  * Generate java source for sqlmap table create / update usage.

I am going to be working towards this starting monday.  Unless anyone
has some suggestions or criticism on this approach.

( /me awaits the pearls of knowledge from trygvis )

- Joakim

Mime
View raw message