Hi Marcel,
Thanks for your explanation.
Now everything is logical.
Best regards
Jakub
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:
> //[EMAIL PROTECTED] >= '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:
//[EMAIL PROTECTED] >= 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:
//[EMAIL PROTECTED] >= '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:
//[EMAIL PROTECTED] >= '2005-01-01T00:00:00.000TZ']
the result set is always full, but when I use a single "less" or
"less than" condition, eg:
//[EMAIL PROTECTED] <= '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
