On Sat, Sep 12, 2009 at 9:38 PM, Marc - A. Dahlhaus <[email protected]> wrote: > > How to solve the other problems that i spotted in the hook design draft? >
I think these problems are the same for hooks and triggers, and they can both be solved. > <quote> > Also i still have the opinion that the configuration of a hook-script should > be contained in the script itself as this is the only way that i could come > up with at the moment that would activate the hook automatically on > installation of the hook. Another way would be to add the hook configuration > into the database and parse this info from there. But the user created hooks > would only work if the user builds his own hook-package then... > packages could just install filehook config in a hook.d directory > Another problem with hooks and the points on which they should be executed > is that if you have a large transaction in which some packages add hooks > that are needed for packages that are installed in the same transaction need > to be parsed on installation time to give you the option to run the hooks on > the point they should be executed. Also what about a package that wants hook > X needs to be installed before the hook X is added by another package? Would > be a classic chicken-egg problem i think. Triggers like i proposed them > don't have this problem as they get executed after the transaction is > completed. At this point all triggers are where they should be. > </quote> filehooks can also work at transaction level
