jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davide Giannella <giannella.dav...@gmail.com>
Subject Re: Avoiding conflicts (OAK-1717)
Date Wed, 23 Apr 2014 13:34:28 GMT
On 23/04/2014 13:59, Michael Dürig wrote:
>
> Hi Davide,
>
> While this looks attractive at first I think there are several
> problematic aspects:
>
> 1. We need different implementations for this index depending on
> whether SegmentNS or DocumentNS is being used.
Yes that would be the case. For SegmentNS the current implementation
could be used without conflicts while if we initialise a DocumentNS we
provide a Mongo specific implementation during repository initialisation.

However while typing I'm thinking: is it possible to have, even by
developing it, a DocumentNS that sits on top of something different than
Mongo? If so, how could we differentiate then?

> 2. The lexicographically order of the DocumentNS must coincide with
> Java's String.comparaTo(). Not sure whether this is already the case
> or whether this requirement can be imposed at all.
I think so. Will have to do some testing beforehand but it seems it is.

> 3. Depending on the property type you'd need to encode it into a
> string such that the lexicographic order coincides with the JCR's
> compareTo semantics [1]. On top of that you'd also need a reverse
> encoding for the descending order. Something along the lines you
> sketched below using some complement.
The encoding/decoding with something like what I said I think will be a
relatively small overhead.

> Overall I fear the complexity that comes along with such an approach...
>
> BTW, I noted that 3 is currently not implemented and that all values
> are compared after having been converted to strings. I believe this is
> wrong and we need to fix this. Could you double check on your side and
> create an issue if needed?
The current implementation of the IndexStoreStrategy[0] accept only
Strings and you don't have any knowledge of the original type of the
property.

(0) http://goo.gl/KLKzDv

However in all my testing I saw then treated correctly. For example
dates arrives in a valid ISO format like ISO_8601_2000 IIRC that makes
it String wise comparable. It's done by using the
Property.getValue(Type.STRING)[1]

(1) http://goo.gl/YzRBQO

Then we use the property value for creating nodes that are the "keys" of
the index and therefore need a string representation of it.

D.



Mime
View raw message