archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Archiva Database future.
Date Mon, 12 Mar 2007 00:58:24 GMT

On 09/03/2007, at 7:39 AM, Joakim Erdfelt wrote:

> 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.

I'd like to investigate this statement further yet. I certainly  
believe it, but would like to better understand where the balance  
will be (and also in how much is done just by reading poms from the  
file system).

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

In what way does efficiency of development and reduced quantities of  
code factor in? I know we've had a bumpy road with JDO, but there are  
still benefits of ORM.

> 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.

I don't believe that to be the case. You can generate the unenhanced  
classes and use that on the client side.

To take OpenJPA as an example, I note that they preserve compatible  
serialization of enhanced and unenhanced classes.

In addition, OpenJPA can manage enhancement at deployment/runtime,  
not requiring the original classes to be modified.

> 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.

But surely the developer can manage the tables in the ORM  
technologies too?

I'm actually quite happy for the ORM to manage the schema - JPOX did  
this just fine with the exception of it's internal tables changing  
version to version.

We should be managing transitions at the application/model level.  
That also facilitates importing data from old versions (in XML, etc)  
as well.

> 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.

I think you still have decent SQL access to the tables of any of the  
ORM tables, and a rich query language in the ORMs to facilitate the  
queries before getting to that stage.

If it's a problem of the granularity of the returned objects, I'd  
start to wonder if perhaps the data model needs to be further broken  
down anyway.

> 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 )

What about Rahul? He's already started work on an openjpa  

I'm of the opinion that we have more important things to worry about  
than ORM tools right now. We have a reasonably well working JDO  
solution that we already know of all the positives and negatives of.

- Brett

View raw message