Andrei Latyshau schrieb:
with this approach one has great flexibility and doesn't have to be afraid
of possible peformance/scalability issues, because
one can rather easily switch the implementations
As we see, when we decide using JackRabbit, then any rotation of layer below
"Data Implementation" will not help...
but that would mean you are implying the whole concept of JCR/Data
abstraction in general is useless, whereas I don't think so at all.
I think you should focus less on Jackrabbit itself, but rather on the
API and think of what does it mean effort/development wise
to replace the JCR implementation (for example Jackrabbit) by something
else (either third-party or a custom Jackrabbit or your own
implementation of JCR).
For example Jackrabbit seems to have a performance/scalability problem
retrieving the most recent version of a node if a node has many versions
(e.g. 50K). So the question is, is this "just" an implementation problem
or an API problem itself. And if it is an implemetation problem how can
it fixed. If it is an API problem, then I think it's more troublesome.
HTH
Michael
