archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
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  
implementation.

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


Mime
View raw message