You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It does not cast the retrieved value into a xs:boolean.
Expected behavior
I would expect – as mentioned in the functions docs and the documentation on the index – that the value is casted or and error is raised. But instead it returns true as xs:string.
To Reproduce
See description above.
Context (please always complete the following information)
Build: eXist-6.2.0
Java: build 1.8.0_392-b08 (OpenJDK)
OS: Alpine-Linux (Docker)
Notes
I am not a Java person, but after a quick search in the eXist-source I would assume the problem is the missing case in bytesToAtomic. I think the addition of the following case might enable correct casting:
It looks like correct conversion for quite a lot of the XDM types is sadly still missing from both the bytesToAtomic and stringToAtomic functions. In fact this is something I flagged as a problem in the PR when the code was previously proposed! Unfortunately it was not corrected before it was merged.
I think the addition of the following case might enable correct casting
In principle your suggestion looks good, but it is only 1/2 of the equation. At the moment when the xs:boolean value is indexed as a binary field, it is stored as a String. Ideally, it should be stored as a single bit (i.e. 0 or 1, representing false or true respectively).
but you would also need to implement the function BooleanValue.deserialize as it is not yet present in the code base. Something like the following should suffice:
Please free free to send a PR for this enhancement.
One concern though - Binary Fields in eXist-db appear to have been implemented by using Lucene's BinaryDocValuesField class. The documentation for that class in Lucene clearly states:
The values are stored directly with no sharing, which is a good fit when the fields don't share (many) values, such as a title field. If values may be shared and sorted it's better to use SortedDocValuesField.
It would seem to me that this would be a bad fit for xs:boolean (and some other XDM types) as they have a very limited value space (e.g. just true or false), and therefore there will potentially be many shared values if you have more than one xs:boolean field. Unfortunately as far as I can see, eXist-db does not currently make SortedDocValuesField available in any way for indexing.
@adamretter thanks for you reply! @line-o self-assigned this issue – so I think he will took a closer look at this issue (let me know, if I can support you in any way).
Describe the bug
Assuming I have a binary-field definition in my
collection.xconf
like this:and I am using
ft:binary-field
in the following way:It does not cast the retrieved value into a
xs:boolean
.Expected behavior
I would expect – as mentioned in the functions docs and the documentation on the index – that the value is casted or and error is raised. But instead it returns
true
asxs:string
.To Reproduce
See description above.
Context (please always complete the following information)
Notes
I am not a Java person, but after a quick search in the eXist-source I would assume the problem is the missing case in
bytesToAtomic
. I think the addition of the following case might enable correct casting:Otherwise it should be documented what values can be casted by calling
ft:binary-field
.The text was updated successfully, but these errors were encountered: