You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Stefan Zoerner <st...@labeo.de> on 2007/04/22 14:22:12 UTC

Question on searching the schema with LDAP searches (specific to ApacheDS 1.5 schema subsystem)

Hi all!

If I perform a search like this:

$ ldapsearch -h zanzibar -p 10389 -D "uid=admin,ou=system" -w ****** -b 
"ou=schema" -s sub "(m-oid=2.5.6.6)"

I get the expected result from our schema partition

version: 1
dn: m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema
m-may: userPassword
m-may: telephoneNumber
m-may: seeAlso
m-may: description
objectClass: metaObjectclass
objectClass: metaTop
objectClass: top
m-typeObjectClass: STRUCTURAL
m-obsolete: FALSE
m-name: person
m-oid: 2.5.6.6
m-must: sn
m-must: cn
m-description: RFC2256: a person
m-supObjectClass: top
$

I asked myself wether it is also possible to search with a sub string 
filter, but it fails

$ ldapsearch -h zanzibar -p 10389 -D "uid=admin,ou=system" -w ****** -b 
"ou=schema" -s sub "(m-oid=2.5.6.*)"
ldap_search: Loop detected
ldap_search: additional info: failed on search operation: Unexpected 
exception.
$

First of all, the error method with the loop does not look correct to me 
(JIRA?). Then I learned that m-oid does not have a matching rule for 
substring match defined in the schema. Is this intended? Would 
objectIdentifierFirstComponentMatch (OID 2.5.13.30) be appropriate here?

Thanks in advance + Greetings from sunny Hamburg,
     Stefan Zoerner (szoerner)


Re: Question on searching the schema with LDAP searches (specific to ApacheDS 1.5 schema subsystem)

Posted by Emmanuel Lecharny <el...@gmail.com>.
Ersin, Stefan,

when we designed the meta-schema, we didn't defined all the substring
matching rules for each attribute type :
http://cwiki.apache.org/confluence/display/DIRxSRVx11/MetaSchema

This is something we can add easily.

Emmanuel

On 4/22/07, Ersin Er <er...@gmail.com> wrote:
>
> Hi,
>
> I also faced with that situation/error. Current implementation does
> not allow substring searches but I think we should allow them. It
> would be great for doing core schema operations over the wire.
>
> On 4/22/07, Stefan Zoerner <st...@labeo.de> wrote:
> > Hi all!
> >
> > If I perform a search like this:
> >
> > $ ldapsearch -h zanzibar -p 10389 -D "uid=admin,ou=system" -w ****** -b
> > "ou=schema" -s sub "(m-oid=2.5.6.6)"
> >
> > I get the expected result from our schema partition
> >
> > version: 1
> > dn: m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema
> > m-may: userPassword
> > m-may: telephoneNumber
> > m-may: seeAlso
> > m-may: description
> > objectClass: metaObjectclass
> > objectClass: metaTop
> > objectClass: top
> > m-typeObjectClass: STRUCTURAL
> > m-obsolete: FALSE
> > m-name: person
> > m-oid: 2.5.6.6
> > m-must: sn
> > m-must: cn
> > m-description: RFC2256: a person
> > m-supObjectClass: top
> > $
> >
> > I asked myself wether it is also possible to search with a sub string
> > filter, but it fails
> >
> > $ ldapsearch -h zanzibar -p 10389 -D "uid=admin,ou=system" -w ****** -b
> > "ou=schema" -s sub "(m-oid=2.5.6.*)"
> > ldap_search: Loop detected
> > ldap_search: additional info: failed on search operation: Unexpected
> > exception.
> > $
> >
> > First of all, the error method with the loop does not look correct to me
> > (JIRA?). Then I learned that m-oid does not have a matching rule for
> > substring match defined in the schema. Is this intended? Would
> > objectIdentifierFirstComponentMatch (OID 2.5.13.30) be appropriate here?
> >
> > Thanks in advance + Greetings from sunny Hamburg,
> >      Stefan Zoerner (szoerner)
> >
> >
>
>
> --
> Ersin
>



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

Re: Question on searching the schema with LDAP searches (specific to ApacheDS 1.5 schema subsystem)

Posted by Stefan Zoerner <st...@labeo.de>.
Ersin, Emmanuel,

Thanks for your immediate response! I'll raise a JIRA for that one.
Greetings from Hamburg,
     Stefan Zoerner (szoerner)

Ersin Er wrote:
> I also faced with that situation/error. Current implementation does
> not allow substring searches but I think we should allow them. It
> would be great for doing core schema operations over the wire.




Re: Question on searching the schema with LDAP searches (specific to ApacheDS 1.5 schema subsystem)

Posted by Ersin Er <er...@gmail.com>.
Hi,

I also faced with that situation/error. Current implementation does
not allow substring searches but I think we should allow them. It
would be great for doing core schema operations over the wire.

On 4/22/07, Stefan Zoerner <st...@labeo.de> wrote:
> Hi all!
>
> If I perform a search like this:
>
> $ ldapsearch -h zanzibar -p 10389 -D "uid=admin,ou=system" -w ****** -b
> "ou=schema" -s sub "(m-oid=2.5.6.6)"
>
> I get the expected result from our schema partition
>
> version: 1
> dn: m-oid=2.5.6.6,ou=objectClasses,cn=core,ou=schema
> m-may: userPassword
> m-may: telephoneNumber
> m-may: seeAlso
> m-may: description
> objectClass: metaObjectclass
> objectClass: metaTop
> objectClass: top
> m-typeObjectClass: STRUCTURAL
> m-obsolete: FALSE
> m-name: person
> m-oid: 2.5.6.6
> m-must: sn
> m-must: cn
> m-description: RFC2256: a person
> m-supObjectClass: top
> $
>
> I asked myself wether it is also possible to search with a sub string
> filter, but it fails
>
> $ ldapsearch -h zanzibar -p 10389 -D "uid=admin,ou=system" -w ****** -b
> "ou=schema" -s sub "(m-oid=2.5.6.*)"
> ldap_search: Loop detected
> ldap_search: additional info: failed on search operation: Unexpected
> exception.
> $
>
> First of all, the error method with the loop does not look correct to me
> (JIRA?). Then I learned that m-oid does not have a matching rule for
> substring match defined in the schema. Is this intended? Would
> objectIdentifierFirstComponentMatch (OID 2.5.13.30) be appropriate here?
>
> Thanks in advance + Greetings from sunny Hamburg,
>      Stefan Zoerner (szoerner)
>
>


-- 
Ersin

Re: Question on searching the schema with LDAP searches (specific to ApacheDS 1.5 schema subsystem)

Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Stefan,

may be we can add some MatchingRule to those meta attributes.

Seems to me a good idea.


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