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
