jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Pawlowicz <cont...@jakubpawlowicz.com>
Subject Re: Searching by date (another problem)
Date Wed, 24 Aug 2005 08:13:19 GMT
Hi Marcel,

Thanks for your explanation.
Now everything is logical.

Best regards

> Hi Jakub,
> The coercing mechanism I mentioned, is actually only used for  
> equals and 'not equals' operations. sorry about my previous  
> misleading post. That means using just string literals in your  
> query will not convert them automatically into a date literal.
> Now, the reason why you see a confusing behaviour is that the index  
> jackrabbit is using does not distinguish typed values. Lucene only  
> supports string values. That means everything has to be converted  
> into a string and can then be indexed.
> E.g. the date: 2005-01-01T00:00:00.000Z is transformed into: mqyalhxc0
> which is much shorter and allows lexicographical comparison
> In case types for a certain property name get mixed up, it can  
> happen that the query returns nodes with property values that do  
> not actually match the query.
> e.g. your example:
> > //*[@myDateProperty >= '2005-01-01T00:00:00.000Z']
> > the result set is always full
> because the string literal is not coerced into a date it will  
> select most nodes with a myDateProperty, even those that have a  
> date in the year 2006. The index representation for 2006 is:  
> 'mrcs57uo0' which is, lexicographically compared, after  
> '2005-01-01T00:00:00.000Z'.
> So, this is some sort of a bug or enhancement. A possible solution  
> is probably to separate values of different types into separate  
> lucene fields. But that's something jackrabbit has to do internally.
> In the meantime you have to stick with the type safe xs:dateTime  
> usage.
> regards
>  marcel
> Jakub Pawlowicz wrote:
>> Hi Marcel,
>> I've tested the xpath queries you've posted yesterday, and I've   
>> noticed that they behave differently.
>> When I use the first one, with the explicit calls to the  
>> xs:dateTime  function, eg:
>> //*[@myDateProperty >= xs:dateTime('2005-01-01T00:00:00.000TZ')  
>> and  @myDateProperty <= xs:dateTime('2005-12-31T23:59:59.999TZ')]
>> everything works perfectly well.
>> But when I use the short version without xs:dateTime function, eg:
>> //*[@myDateProperty >= '2005-01-01T00:00:00.000TZ' and   
>> @myDateProperty <= '2005-12-31T23:59:59.999TZ']
>> the result set is always empty.
>> What's more, when I use a single "greater" or "greater than"   
>> condition, eg:
>> //*[@myDateProperty >= '2005-01-01T00:00:00.000TZ']
>> the result set is always full, but when I use a single "less" or   
>> "less than" condition, eg:
>> //*[@myDateProperty <= '2005-12-31T23:59:59.999TZ']
>> the result set is always empty, no matter what stands on the  
>> right  side of the relation.
>> It seems that the query without xs:dateTime function does not  
>> work  properly.
>> Is this a bug or am I missing something?
>> Regards
>> Jakub

View raw message