On Tue, 2007-04-03 at 11:44 -0600, Richard Megginson wrote:

Andrew Bartlett wrote:

...

I've got my bitwise match plugin to load and run, but now I have an issue. it appears that my matching rule needs to limit what attributes it applies itself to.

That is, when I step though to code, from this query:

[abartlet@piglett source]$ bin/ldbsearch -H ldapi:///data/samba/samba4/svn/source/st/dc/ldap/ldapi -b "dc=samba,dc=example,dc=com" -s sub '(|(&(!(groupType:1.2.840.113556.1.4.803:=1))(groupType:1.2.840.113556.1.4.803:=2147483648)(groupType:1.2.840.113556.1.4.804:=10)))' sAMAccountName groupType # returned 0 records

I seem to be walking all the attributes, not just the attributes in the search expression:

75 errno = 0; 76 a = strtoull((*vals)->bv_val, NULL, 10); 77 if (errno == ERANGE) { 78 ber_bvecfree( vals ); 79 vals = NULL; 80 continue; 81 }

(gdb) p (*vals)->bv_val $5 = 0x8411038 "(targetattr = "*") (version 3.0;acl "full access to all by all";allow (all)(userdn = "ldap:///anyone");)\n"

The collation plugin is again to opaque for me to quite get how I'm meant to handle this...

Well, if it makes you feel any better, after looking at the mr server code, I don't understand it either :-)

:-)

This is what's really puzzling - the interface for the mr match function is this: typedef int (*mrFilterMatchFn) (void* filter, Slapi_Entry*, Slapi_Attr* vals); void *filter is a mr plugin private object (set with slapi_pblock_set (pb, SLAPI_PLUGIN_OBJECT, (void *)obj)) entry is the entry to be tested to see if this entry matches the extensible search filter. You would assume attr is the attribute from the search filter - but you would be wrong. Attr is really just e->e_attrs - the attribute list from entry, beginning with the first attribute in the list. The attribute type in question is not passed in either, which means the mr match function must somehow know which attribute type to look for. The collation plugin handles this by using or_filter_t as the obj - one of the fields is or_type, the attribute type. It also doesn't pass in the value from the filter ava, so the match fn has to keep track of that also.

So it looks like the workaround is to do something similar in the bitwise code - create a structure to use for the match function callback. It looks like the type and value don't have to be a copy - they are pointers into the pblock of the search operation which has a lifetime of well after the match fn is used. The new code is attached.

It looks like the better solution would be to change the code in test_extensible_filter() to pass in the type and value into the match function - it seems stupid for the plugin to have to keep track of that, but perhaps I'm missing something.

Yeah, i think the current interface sucks. But it's great to have this working, and we now pass that portion of our tests.

So, the next blocker is needing something I can use for USN support.

Andrew Bartlett