On 3/30/11 3:01 PM, Alex Karasulu wrote:
On Wed, Mar 30, 2011 at 1:35 AM, Emmanuel Lecharny<[email protected]>wrote:
Hi guys,
I'm facing an interesting issue. When we parse a filter, we build a Value
which is a BinaryValue, even if the attribute is H/R. The problem is that we
have to provide a getString() method which translates this byte[] when we
want to process the Value.
I tried to get rid of the getString() method in the StringValue class and
getBytes() in BinaryValue, but I can't because of the above issue.
Now, I'm wondering if it wouldn't be better to store a StringValue() when
we parse a Filter, as a default value, excpet if the Filter is schema aware
(which is not currently the case).
Most of the time ad hoc filters are string based. However we have seen
situations where they will be binary as well. As long as we're
interchangeable there should be no problem and since the binary case is the
exception then it makes sense using string values.
It's a bit more complex than that, in fact. May be I wasn't exposing the
whole issue...
You may use binary values, using \XY for non ascii values. Something like :
(userCertificate=\00\AB\3F*)
is valid. Now, we can't store that in a StringValue, because the escaped
hex are converted to bytes in the filter parser.
I was wonderig if it would not be a better idea to store the value as a
byte[], unless we have a schema aware Filter instance, and then use
either a StringValue or a BinaryValue, accordingly to the AttributeType
used.
I also have more concerns :
1) do we have to deal with a schema aware filter on the client side ?
IMO, it *may* be usefull, as it allows the user to check the filter
before sending it to the server.
2) do we have to expose all the XXXNode classes to the user ? I'm not
sure it's a good idea.
wdyt ?
How we do this however is important since this impacts virtually everything
in the server.
yes, but it's not a big deal, as we correctly construct schema aware
filters high enough in the interceptor chain (namely in the
normalization filter).
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
