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 14:05:03 GMT


On 23.4.14 3:34 , Davide Giannella wrote:
> 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.

On the SegmentNS there is still a potential for conflicts between 
sessions. So we'd need some conflict validation there too.

>
> 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?

Yes and we actually have that with 
org.apache.jackrabbit.oak.plugins.document.rdb.RDBDocumentStore.

>>
>> 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.

This works since for ISO-8601 the chronological order is the same as the 
lexicographical one.


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.

And I'm pretty sure the lexicographical order of the string 
representation will in general not be the one required. For example 
longs and doubles will probably not work correctly.  See 
http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.6.5.1%20CompareTo%20Semantics

Michael

>
> D.
>
>

Mime
View raw message