You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2007/10/08 14:39:26 UTC
Missing MatchingRule (for ObjectClass, DN, etc ...)
Hi guys,
I have committed ( and reverted) some silly fix for what I thought was
a bug in the server : when you try to filter searches using substring,
like :
(objectClass=org*)
or
(uniqueMember=dc=ex*)
applying the following rule (RFC 4511, par 4.5.1.7)
"A filter item evaluates to Undefined when the server would not be
able to determine whether the assertion value matches an entry.
Examples include:
- An attribute description in an equalityMatch, substrings,
greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
is not recognized by the server.
- The attribute type does not define the appropriate matching rule."
we should set the evaluation to undefined. This is not what we have
currently, as we get a NPE if we don't have a defined MatchingRule,
resulting to an undefined Exception :
...
Normalizer normalizer = type.getSubstr().getNormalizer();
...
public MatchingRule getSubstr() throws NamingException
{
if ( substrOid == null )
{
return findSubstr( getSuperior() );
...
public AttributeType getSuperior() throws NamingException
{
if ( superiorOid == null )
{
return null;
...
The tests semantics is a little bit biased though.
I have some questions now :
- How does other servers react with such searches ?
- Should we default to EqualityMatch if we don't have a matchingRule
for an AttributeType ?
wdyt ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Missing MatchingRule (for ObjectClass, DN, etc ...)
Posted by Emmanuel Lecharny <el...@gmail.com>.
yep, sure. Nothing urgent here.
On 10/9/07, Alex Karasulu <ak...@apache.org> wrote:
> Yeah I want to touch base with you and do this but my mental stack is on
> this
> redesign and then I have work related matters to tend to. I promise to sit
> down
> and revisit this but I have to keep focused on the big bang when I have
> time.
>
> The deal is getting this done fast enough so we can stabilize changes soon.
> This
> issue we're discussing is not a massive change and can be fixed in a 2.0-RC
> no?
>
> Alex
>
>
> On 10/9/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > I'm your man with this review, when you have 1 hour. At the same time,
> > I have to tell you that there is some room for improvement, for sure.
> > For instance, if a node is evaluated with a 0 count (because there is
> > no matching value), we can reorganize the filter, which is not
> > currently done, so I se this hour as a valuable expense of our time :)
> >
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Missing MatchingRule (for ObjectClass, DN, etc ...)
Posted by Alex Karasulu <ak...@apache.org>.
Yeah I want to touch base with you and do this but my mental stack is on
this
redesign and then I have work related matters to tend to. I promise to sit
down
and revisit this but I have to keep focused on the big bang when I have
time.
The deal is getting this done fast enough so we can stabilize changes soon.
This
issue we're discussing is not a massive change and can be fixed in a 2.0-RCno?
Alex
On 10/9/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> I'm your man with this review, when you have 1 hour. At the same time,
> I have to tell you that there is some room for improvement, for sure.
> For instance, if a node is evaluated with a 0 count (because there is
> no matching value), we can reorganize the filter, which is not
> currently done, so I se this hour as a valuable expense of our time :)
>
Re: Missing MatchingRule (for ObjectClass, DN, etc ...)
Posted by Emmanuel Lecharny <el...@gmail.com>.
It's just shocking that LDAP ran into
> this
> catch 22 since static groups are driven by DNs: one just expects it to work.
On the other side, people usually feed the static group
programatically with what they get from a search request, so I don't
really see that as such a big problem ...
I'm your man with this review, when you have 1 hour. At the same time,
I have to tell you that there is some room for improvement, for sure.
For instance, if a node is evaluated with a 0 count (because there is
no matching value), we can reorganize the filter, which is not
currently done, so I se this hour as a valuable expense of our time :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Missing MatchingRule (for ObjectClass, DN, etc ...)
Posted by Alex Karasulu <ak...@apache.org>.
Cool we just need to look into all this business of what to do when we don't
have a valid SUBSTR matchingRule when we have time. You're absolutely
right about DN not being a string. It's just shocking that LDAP ran into
this
catch 22 since static groups are driven by DNs: one just expects it to work.
Alex
On 10/8/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi Alex,
>
> I just fixed the potential NPE which occurs in certain cases (for
> instance, when you have a 0 count for a node : the matching rule was
> null, but was not assumed to be null, when the MR was transformed to
> Equality if there is more than one element. Now, when you get a null,
> the Equality is used in any case).
>
> Tests are passing just OK, without modification.
>
> On 10/8/07, Alex Karasulu <ak...@apache.org> wrote:
> > Sounds good to me. However let's let this one sit in the head for a
> while
> > since it has
> > potentially wide reaching effects. It effects the semantics of search
> and
> > there are several
> > things that I cannot easily foresee. So I want to think about this one a
> > little bit.
> >
> > Alex
> >
> > On 10/8/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > > After investigation, the problem is a little bit more complex than
> > > what I just described.
> > >
> > > We have done some tests with Studio, and here is what we found :
> > > - if you define an attributeType _without_ any matching rule, then you
> > > should have a problem. As we cannot use an identity MR (because none
> > > has been defined), you will get a NPE at some point, unless we define
> > > the filter as undefined.
> > > - I have fixed many places in the server where we didn't replaced a
> > > missing Substring MR by the identity MR. I will commit those fixes
> > > after integration tests.
> > > - Now, some users want to do searches using filters like
> > > (uniqueMember=uid=g.kelly*). Of course, we can say that it should
> > > return nothing, as the filter is undefined, but I find this a little
> > > bit too tight. What if we simply use th equality MR in this case ?
> > >
> > > I would say that if we don't have Substring MR, we should use Equality
> > > MR, and if we don't have Equality MR, then we should simply consider
> > > the filter as undefined. This could be done during the filter parsing,
> > > instead of doing it during the filter evaluation.
> > >
> > > wdyt ?
> > > --
> > > Regards,
> > > Cordialement,
> > > Emmanuel Lécharny
> > > www.iktek.com
> > >
> >
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: Missing MatchingRule (for ObjectClass, DN, etc ...)
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Alex,
I just fixed the potential NPE which occurs in certain cases (for
instance, when you have a 0 count for a node : the matching rule was
null, but was not assumed to be null, when the MR was transformed to
Equality if there is more than one element. Now, when you get a null,
the Equality is used in any case).
Tests are passing just OK, without modification.
On 10/8/07, Alex Karasulu <ak...@apache.org> wrote:
> Sounds good to me. However let's let this one sit in the head for a while
> since it has
> potentially wide reaching effects. It effects the semantics of search and
> there are several
> things that I cannot easily foresee. So I want to think about this one a
> little bit.
>
> Alex
>
> On 10/8/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > After investigation, the problem is a little bit more complex than
> > what I just described.
> >
> > We have done some tests with Studio, and here is what we found :
> > - if you define an attributeType _without_ any matching rule, then you
> > should have a problem. As we cannot use an identity MR (because none
> > has been defined), you will get a NPE at some point, unless we define
> > the filter as undefined.
> > - I have fixed many places in the server where we didn't replaced a
> > missing Substring MR by the identity MR. I will commit those fixes
> > after integration tests.
> > - Now, some users want to do searches using filters like
> > (uniqueMember=uid=g.kelly*). Of course, we can say that it should
> > return nothing, as the filter is undefined, but I find this a little
> > bit too tight. What if we simply use th equality MR in this case ?
> >
> > I would say that if we don't have Substring MR, we should use Equality
> > MR, and if we don't have Equality MR, then we should simply consider
> > the filter as undefined. This could be done during the filter parsing,
> > instead of doing it during the filter evaluation.
> >
> > wdyt ?
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
>
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Missing MatchingRule (for ObjectClass, DN, etc ...)
Posted by Alex Karasulu <ak...@apache.org>.
Sounds good to me. However let's let this one sit in the head for a while
since it has
potentially wide reaching effects. It effects the semantics of search and
there are several
things that I cannot easily foresee. So I want to think about this one a
little bit.
Alex
On 10/8/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> After investigation, the problem is a little bit more complex than
> what I just described.
>
> We have done some tests with Studio, and here is what we found :
> - if you define an attributeType _without_ any matching rule, then you
> should have a problem. As we cannot use an identity MR (because none
> has been defined), you will get a NPE at some point, unless we define
> the filter as undefined.
> - I have fixed many places in the server where we didn't replaced a
> missing Substring MR by the identity MR. I will commit those fixes
> after integration tests.
> - Now, some users want to do searches using filters like
> (uniqueMember=uid=g.kelly*). Of course, we can say that it should
> return nothing, as the filter is undefined, but I find this a little
> bit too tight. What if we simply use th equality MR in this case ?
>
> I would say that if we don't have Substring MR, we should use Equality
> MR, and if we don't have Equality MR, then we should simply consider
> the filter as undefined. This could be done during the filter parsing,
> instead of doing it during the filter evaluation.
>
> wdyt ?
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: Missing MatchingRule (for ObjectClass, DN, etc ...)
Posted by Emmanuel Lecharny <el...@gmail.com>.
After investigation, the problem is a little bit more complex than
what I just described.
We have done some tests with Studio, and here is what we found :
- if you define an attributeType _without_ any matching rule, then you
should have a problem. As we cannot use an identity MR (because none
has been defined), you will get a NPE at some point, unless we define
the filter as undefined.
- I have fixed many places in the server where we didn't replaced a
missing Substring MR by the identity MR. I will commit those fixes
after integration tests.
- Now, some users want to do searches using filters like
(uniqueMember=uid=g.kelly*). Of course, we can say that it should
return nothing, as the filter is undefined, but I find this a little
bit too tight. What if we simply use th equality MR in this case ?
I would say that if we don't have Substring MR, we should use Equality
MR, and if we don't have Equality MR, then we should simply consider
the filter as undefined. This could be done during the filter parsing,
instead of doing it during the filter evaluation.
wdyt ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: Missing MatchingRule (for ObjectClass, DN, etc ...)
Posted by Alex Karasulu <ak...@apache.org>.
Hi Emmanuel,
On 10/8/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> Hi guys,
>
> "A filter item evaluates to Undefined when the server would not be
> able to determine whether the assertion value matches an entry.
> Examples include:
>
> - An attribute description in an equalityMatch, substrings,
> greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
> is not recognized by the server.
>
> - The attribute type does not define the appropriate matching rule."
Right now ApacheDS uses the following algorithm:
1). Attempt to use the correct matchingRule for the the AVA in a search
filter. For example
if SUBSTR matching is to be used ApacheDS will search for this first on
the attribute
associated with the attribute identifier used in the AVA.
2). If it cannot find the matchingRule for the attribute the registries are
used to find a SUBSTR
matchingRule on superior attributeTypes going up the ancestry of the
AT.
3). If no matchingRule for the AVA type was found in the entire AT ancestry
then equality
matching rules are used with the same tactic of checking from child up
through the
ancestry.
Now #3 is an issue for several reasons. First of as you cleverly pointed
out the EQUALITY
matchingRule may not work for several reasons but mainly because the
attributeType's syntax
may not be a String. Also there are semantic issues with this.
We can fix this in 2 ways. First we can only take option #3 if the syntax
is a syntax that
is human readable.
Or we can prune the filter leaving that AVA as undefined. When we pull
search out of the partition
into the server we may want to look at making sure all the matchingRules are
in place and resolved
for the filter AST before begining the search descent. At this point we can
prune correctly.
I'd rather follow the spec exactly to the T so the later option is perhaps
the best.
Alex
- How does other servers react with such searches ?
Yes I am curious about this too. Perhaps once I setup a lab I can look at
this.
- Should we default to EqualityMatch if we don't have a matchingRule
> for an AttributeType ?
Talked about this above.
Thanks,
Alex