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.
