abartlet at samba.org
Wed Nov 11 14:53:24 MST 2009
On Wed, 2009-11-11 at 23:16 +0200, Kamen Mazdrashki wrote:
> On Wed, Nov 11, 2009 at 22:53, Andrew Bartlett <abartlet at samba.org> wrote:
> > On Wed, 2009-11-11 at 15:04 +0200, Kamen Mazdrashki wrote:
> >> Main purpose of _drs_util_verify_attids() is to verify decoded OID
> >> is real one - i.e. decoding ATTID based on drsuapi_prefixMap leads
> >> to an OID that actually exists.
> > Doesn't loading the schema already check that? (If not, should we not
> > do the checks there?).
> No. _drs_util_verify_attids() is to verify ATTIDs got from GetNCChanges
> are properly decoded using the prefixMap we got from GetNCChanges.
> Which helped me to find out w2k8-r2 does not make same ATTIDs as
> described in MD-DRSR.pdf.
> >> So please, don't remove it.
> >> The cache i've implemented lowers execution time significantly.
> > And this cache is simply a duplicate of the schema we already load. If
> > we must keep this code, then at least let us use the schema, which does
> > a binary, rather than a linear, search of the possible names.
> Yes, you are right.
> By the time I was implementing this tiny cache I wasn't aware you are
> implementing schema loading - hence we collide :).
> > But I still can't see how it validates anything extra.
> As I noted above - it verifies ATTIDs received against the drsuapi_prefixMap
> we receive.
> The whole ideia was that DSSYNC test to use alternative implementation
> for "drsuapi_prefixMap + ATTID => OID" encoding/decoding so that we
> can catch regressions in dsdb implementation.
If you want to do that, then write up a test that uses expected values
for the 'fixed' part of the table. That will give us a real test that
might actually fail on errors. In the meantime, I do propose to remove
this, as I can't see what extra value it gives.
That is: by doing a OID -> attr ID load during the schema load, and a
attrid -> attribute lookup during the syntax conversion, and a
comparison on the converted values (by looking up LDAP with a string
attribute name), I think we have a high degree of confidence that we
have the right mapping.
Can you have a look over my dsdb-dn branch and see if you agree?
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the samba-technical