Filter parsing and values

[Emmanuel Lecharny <el...@gmail.com>]

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).

Thoughts ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Filter parsing and values

[Emmanuel Lécharny <el...@apache.org>]

On 3/30/11 3:01 PM, Alex Karasulu wrote:
> On Wed, Mar 30, 2011 at 1:35 AM, Emmanuel Lecharny<el...@gmail.com>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

Re: Filter parsing and values

[Alex Karasulu <ak...@apache.org>]

On Wed, Mar 30, 2011 at 1:35 AM, Emmanuel Lecharny <el...@gmail.com>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.

How we do this however is important since this impacts virtually everything
in the server.

Regards,
Alex