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.
