> > a double. I really do not see how it could even work > properly currently.
> Alexander Klimetschek wrote: > You are right, if there are properties with different types > found under that name in the repository, it is not easy to do > generally. I was thinking that one could do the cast > deep-down in the lucene query handler at a point where you > know which property type you have (since it is indexed > somehow). But I don't know if this point exists. AFAIK, there is no such point. During indexing, LONGs and DOUBLEs are converted to a lexical representation (see NodeIndexer.addLongValue for example) such that lucene can query and sort on it (lucene works lexically only). The LONG's and DOUBLEs end up in the very same lucene field as normal String properties. As one single property can sometimes be a LONG, and other times a String, it is not possible from the query *or* from the lucene index (as String and LONG values are indexed in the same field) to find out what kind of types we are dealing for the property. Perhaps the node type manager could hand you some info, but this would never work for querying on nt:unstructured kind of nodes. > > >> eg. from long to double, before doing the conversion. This is what > >> the spec suggests (but only saying "can"). I can imagine > > > > Do you know which section this is? (170 or 283?) > > I mentioned it in my previous mail: 170, section 8.5.4.3 (sql > part, not mentioned at all for xpath). I think I have overlooked something in my previous mails: when you search for something like [...@x < ...] and ... Is not surrounded by '', will the query parser then try to parse it as a LONG/DOUBLE? In that case, obviously, xs:long() and xs:double() from my previous mail is nonsense. Also I then understand your suggestion about the 'if this is the case, one might think about storing both double and long properties in the lucene docs as double and always convert the literal from the query to double'. This makes sense. Only, still I would favour to index LONGs and DOUBLEs in a separate lucene field, because still you could get very strange results with [...@x < 5], where the 5 is translated to some String representation (call this StringRep5 ) (see for example LongField). Though, if some other node has the property x as a string value, where that string value is < StringRep5, it would count as a hit, because all is in one single lucene field. Ard > > Regards, > Alex > > -- > Alexander Klimetschek > [email protected] >
