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.