> Thanks for your information. And I would suggest we improve > Jackrabbit implementation by converting the number formats > automatically. Or just simply throw out an exception if the > input format is not the same as property format. I personally > don't think current implementation makes sense.
How can you tell from an xpath the property format? Even worse, there is in nt:unstructured no limit on using the same property one time as long, then a double and then a string. I do agree the current impl is quite ambiguous because you cannot tell what kind of property value type you are querying for. Dates do have a special thing for this, the xs:dateTime kind of function. IMO, for doubles and longs something similar is needed, though, it looks kind of strange ofcourse in xpath. But, I can never tell when I see '@someprop < 5' whether the 5 should be interpreted as a string, as a double or a long. Ard > > Best, > Kevin > > > > > ----- Original Message ---- > From: Alexander Klimetschek <[email protected]> > To: [email protected] > Sent: Tuesday, January 20, 2009 1:25:58 AM > Subject: Re: A bug? Query returns wrong records > > On Sat, Jan 17, 2009 at 5:48 AM, Cheng Zhang > <[email protected]> wrote: > > Problem: query below returns one row which is wrong. > > > > select * from oag:CustomerReviews where AverageRating > 5 > > > > but query below is ok: > > > > select * from oag:CustomerReviews where AverageRating > 5.0 > > > > A bug? > > AFAIK a double value (such as AverageRating) must be compared > against a double literal in sql/xpath queries, ie. include a > dot like "5.0". > The JCR spec does not mandate long<->double conversion in that case: > "In case of type mismatches in a comparison LONGs can be > converted to DOUBLEs". > > [1] http://www.day.com/specs/jcr/1.0/8.5.4.3_WHERE.html > > Regards, > Alex > > -- > Alexander Klimetschek > [email protected] > >
