jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Dürig <mdue...@apache.org>
Subject Re: Avoiding conflicts (OAK-1717)
Date Wed, 23 Apr 2014 12:59:06 GMT

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.

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.

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.

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?

Michael

[1] 
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.5.1%20CompareTo%20Semantics

On 22.4.14 6:07 , Davide Giannella wrote:
> Good evening everyone,
>
> (long email warning)
>
> had an offline discussion with Marcel regarding OAK-1717.
>
> Even by having annotating conflicts for the DocumentNS persistence by
> implementing OAK-1185 could not suffice for some cases.
>
> https://issues.apache.org/jira/browse/OAK-1717
> https://issues.apache.org/jira/browse/OAK-1185
>
> Se trying to see any other implementation and the suggestion was to rely
> on the lexicographically nodes order that is implicitly provided by the
> MongoNS. Getting rid therefore of the conflicting property (:next).
>
> This could work perfectly for the ascending indexes but makes it a bit
> more difficult for the descending use case.
>
> Thinking around a possible algorithm to address the reverse-order case I
> thought about something like "complement 9" where by dealing only with
> letters and numbers I can convert easily
>
> 2013-03-01 becoming 7986-96-97 by doing 9-2 9-0 ... and 9-7 9-9 ... on
> the way back.
>
> Same principle if I deal with letters
>
> A-Z is 65-90 assuming 65=0 we could have A = 65 = 0 = 90-0 = 90 = Z = 90
> - 90 = 0 = 65 = A.
>
> a-z is 97-122.
>
> I think you got the trick by now.
>
> Now the questions.
>
> Unicode. This ugly beast. How deal in that case? How would a String
> represent a unicode value that should be then a node name? Or to put it
> in another way what will it be in a String (before or afterKeys) of the
> update() method
>
> http://goo.gl/D5FtYk
>
> Second question. By getting rid of the skip list we won't be able to
> quickly seek items on big indexes when searching. Ideas around it?
>
> Thank you
> Regards
> Davide
>

Mime
View raw message