jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Marth <mma...@adobe.com>
Subject Re: Migration without an embedded Jackrabbit
Date Sun, 13 Oct 2013 17:36:58 GMT
Hi Jukka,

I think the situation is slightly different between OAK-458 and OAK-805 (although I come to
roughly the same conclusion in both cases)

OAK-805: JR users that cannot upgrade their existing data store will be stuck "eternally"
after a migration (I think it is fair to assume and a reasonable deployment case that a large
amount of binaries might not be feasible to move ever). So, in turn this means that we would
be eternally stuck with all the mentioned JR dependencies in Oak unless we re-implement the
existing functionality. However, it also means, that this re-implementation needs to be "production
quality" for read/write (as opposed to the second case). So, I think a re-implmentation makes
sense.

OAK-458: In this case the functionality that needs to be re-implemented is certainly a subset,
as it requires only read-access to the repo (and does not need to cover a lot of edge cases
that a full fledged read-write support needs to cover). So, I am inclined to also opt for
a re-implementation if this subset is sufficiently easy to implement.
If not, we could pull in the whole enchilada of dependencies as we know that we can drop them
later: IMO it would be fair to drop (or make optional) the ability to upgrade an existing
JR repo to Oak at a certain point in the future and thus remove the additionally needed deps.

Michael


On Oct 11, 2013, at 4:28 PM, Jukka Zitting wrote:

Hi,

I've been thinking about the upgrade/migration code (oak-upgrade,
OAK-458) over the past few days, and trying to figure out how we could
achieve that without having to keep the full Jackrabbit 2.x codebase
as dependency. The same question comes up for the support for
Jackrabbit 2.x datastores (OAK-805).

The key problem here is that the Jackrabbit 2.x codebase is already so
convoluted that it's practically impossible to just pick up say
something like an individual persistence manager or data store
implementation and access it directly without keeping the rest of the
2.x codebase around. This is troublesome for many reasons, for example
using such components require lots of extra setup code (essentially a
full RepositoryImpl instance) and the size of the required extra
dependencies is about a dozen megabytes.

Thus I'm inclined to instead just implement the equivalent
functionality directly in Oak. This requires some code duplication
(we'd for example need the same persistence managers in both Oak and
Jackrabbit), but the versions in Oak could be a lot simpler and more
streamlined as only a subset of the functionality is needed. To reduce
the amount of duplication we could push some of the shared utility
code (like NodePropBundle, etc.) to jackrabbit-jcr-commons or to a new
jackrabbit-shared component.

WDYT?

BR,

Jukka Zitting


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message