Todo List: Working on ParentGUID Fix

[tridge at samba.org]

Hi Fernando,

It is best to get it all working correctly before trying to make it
async. See my previous reply for what still needs to be fixed.

 > I'm starting thinking about the Async coding... I debuged a few code through
 > modules requests but I still have a few doubts about how it works ... Is
 > there any documentation about the modules and/or any similar existing code
 > that I could follow as an example for the Async implementation?

There is no documentation, but there are plenty of examples in the
dsdb/samdb/ldb_modules/ directory. I should warn you that it is quite
tricky to get right. Andrew and I are still discussing whether we
should just avoid using the async design for new code in dsdb ldb
modules, as it is so hard to code, and makes the code very difficult
to read.

If you want to do it anyway, then have a look at the code you removed
in objectclass.c. That code added the parentGUID in a rename in an
async fashion. 

 > When operational_search() is called, it builds a search request with
 > operation_callback as the callback function... That function is only called
 > after the search is done, right?

that's right.

 > I couldn't find where the reply message passed to this function is
 > filled (I suppose there would be the place where I should fill with
 > the parentGUID, would it be right?), could you give me some tip?

have a close look at objectclass_rename_callback(). See that it gets a
result in ac->search_res->message? 

I'd suggest you add a lot of DEBUG() messages to an existing piece of
async code (such as the example above) and then trace through how it
works. It can be a bit mind-bending, but if you look at it for a while
then I hope it will start to make sense.

btw, the reason we put this async code in is that ldb can use a remote
ldap database as a backend. In that case an ldb call might have to
wait a few seconds for a remote ldap server to complete an
operation. By doing the operation in an async fashion it allows other
processing in Samba to continue while the ldap server is
responding. This is particularly important when Samba is running in
single process mode (ie. with -M single).

It isn't a common use case however, and it could be argued that we
should just use a new event context for ldb, and always treat it as a
"local database" in the s4 dsdb ldb modules. In that case we would
assume that the backend is "sufficiently responsive" and we would not
need all this async code.

We're still thinking about this, so if you find the async code too
hard, then you should know that you are not along in thinking this,
and perhaps we will just make future changes to dsdb modules be sync,
like you did in your initial patch.

Cheers, Tridge