David Nuescheler wrote:
- to be able to handle transactions
- to be able to handle commit/rollback
true... what is the difference between the two points?
Well if you think in terms of pure JDBC then there is no difference. But
for me transactions also cover memory state, so any objects handled by
the PM (that are not also handled by the upper layers) should also be
reverted in case a transaction fails. This of course is only necessary
if your PM implementation has internal caches, or uses copies of
Jackrabbit objects.
- use mapping files to be able to change the table and column names as
they might conflict
not sure. of course there are a number of different ways on how
someone could map a content repository to a relational database.
however, i think there are a couple of very simple "hard coded"
implementations that completely avoid conflicts without
any configuration beyond standard jdbc.
Well from experience I know that table and column naming is something
you will want to change at some point (I had the case where I had to
integrate with a DB that required very short names). It doesn't cost
much for example to make the statements loadable from a database (I
believe Edgar's implementation does this). In the case of the iBatis
implementation this was also the case. There is no performance cost to
do this (as it is done during PM initialization), and allows for some
flexibility.
- allow for clustering
that is unfortunately not something that the pm can take care of
see the jira bug and all the discussions around that.
I guess a better wording might be "- doesn't introduce any problems for
clustering" then :) I have been following all the discussion of
clustering, and I do agree that there is much more to it than just the PMs.
see above. i think the differentiators that orm brings to the table
are not that significant to a persistence manager, while i think that
the additional complexity is substantial.
Indeed the complexity worries me too. I'll have to have a go at it and
see if I can simplify.
And as always, in terms of speed : memory > filesystem > db :)
well, not in general ;)
Uh... I'm not sure you read this right. I meant to say that memory
access is always faster than filesystem access which itself is faster
than DB access. I would think this would be the general case. Of course,
there can be exceptions (especially when the access design is not
efficient).
Regards,
Serge...
