On 2015-08-21 11:57, Bertrand Delacretaz wrote:
Hi,
Continuing to play with Robert's MultiplexingDocumentStore [1] I got a
failure in the oak-jcr module's LongPathTest.
That's due to the conversion of long paths to their hashed variants -
those cannot be used to locate the appropriate DocumentStore when
multiplexed, as that decision is based on the real path. In some cases
like UpdateOp the real path is saved alongside the hashed one, but not
always.
Removing the path hashing as shown in the below patch removes that
problem, and all oak-core tests pass with this change.
Is that hashing still needed, or was that created due to backend
limitations which are gone now?
It is still needed, as both persistence implementations (Mongo, RDB) are
restricted to IDs of 512 bytes length (yes, bytes, not characters).
If still needed, could it be made configurable so that users can make
their own tradeoff (MultiplexingDocumentStore vs. supporting backends
that require that), or are there other constraints?
I don't think disabling is an option; it's very easy to hit this length
limit.
Best regards, Julian
