I dislike calling update functions in the install hook. Update functions change a lot over time, so this creates maintenance issues (it's easy to forget that the old update is no longer valid to call, and every new update means some refactoring). Also, for settings the install function should only set up good defaults, and the update function should only change settings when the old setting was no longer valid or it's entirely new,
so they really don't even operate on the same scope.

Some duplication of .install code is a lesser evil, and a helper function can be appropriate.

For settings, I prefer to just put the defaults in the code when calling variable_get and not have to deal with the .install at all. There can be some minor duplication,
but I never have to worry about the DB being in an invalid state.

- Ken Winters

On Nov 12, 2009, at 9:09 AM, Pierre Rineau wrote:

On Thu, 2009-11-12 at 08:55 -0500, Nancy Wichmann wrote:
My suggestion would rather be to just call the appropriate hook_update_N() within the hook_install(). It may look a bit of a kludge, but it is the
safer thing to do.

I often does some thing like:

function _mymodule_some_new_really_important_business_stuff() {
 // Bla bla
}

function mymodule_install() {
 // Some stuff
 _mymodule_some_business_stuff();
 // Some other stuff
}

function mymodule_update_N() {
 // Some stuff again
 _mymodule_some_business_stuff();
 // Some other stuff again
}

To remove some ambiguity. It does nothing more than calling the
mymodule_update_N() function into the hook_install(), but it allows you to put other things that don't have to be called at install in the same
hook_update_N() implementation.

Pierre.


Reply via email to