On Donnerstag, 5. Juni 2008, Howard Chu wrote:
Ralf Haferkamp wrote:
Hi,
as back-config does currently not have support for the delete operation (config_back_delete() just returns LDAP_UNWILLING_TO_PERFORM currently) I am trying to figure out what is needed to get at least delete support for simple overlays (e.g. ppolicy or memberof) running.
Very brave of you. ;)
What I am currently doing is:
- renumber the indexes of the siblings of the overlay that's going
to be deleted
- remove the CfEntryInfo of the overlay from the internal config
tree - remove the Entry from the underlying LDIF database
Additionally I need to remove the overlay's slap_overinst structure from the overlay list of the backend and in case it was the last overlay, restore the original BackendInfo structure and delete the SLAP_DBFLAG_GLOBAL_OVERLAY flag from the BackendDB structure of the underlying database (for global overlays). Currently I use the overlay_destroy_one() function for this task. This also calls the db_destroy() hook of the overlay which should take are of free resources held by the overlay.
I am a bit unsure about the db_destroy() part. Is that enough or is it needed to call the db_close() hooks (when provided by the overlay) before calling db_destroy()? Did I miss something else? Is anybody else currently working on this?
You should call the db_close() hook first.
Ok. I implemented that in a separate function (overlay_remove()) now. Basically that calls the db_close and db_destroy hooks, removes the overlay from the oi_list and cleans up the BackendDB structure when the last overlay is being removed.
I have some preliminary code for back-config delete support ready I think. It currently only supports overlays which do not instantiate child objects (pcache, translucent) and does not touch any data the overlay might have created in the underlying database.
I hope to be able commit that code during the next days. Should it be hidden behind #ifdefs for now? (Probably be enabled with "LDAP_DEVEL")
Up to now I am testing this only with some simpler overlays (memberof, pcache), I assume that deleting overlays that instantiate their own databases (like pcache, translucent(?)) might get a little more hairy.
Right. We need to distinguish between tearing down due to a normal shutdown, which should leave underlying data intact, and tearing down due to removal...
Thinking about this again, if we agree that removing config entries should not touch any data, as previously suggested in this thread, we probably don't need to make this distinction. Though we would need to decide whether back-config should make in implicit subtree delete for overlays that instantiate their own database or if the admin should take care of cleaning up the config tree in the correct order.
An additional hook that could be used to do some config-related cleanup in overlays/databases and that allows to check whether the overlay can be deleted at all, as suggested by Hallvard, might still be useful though.