[development] Doing hook_update_N() when module is installed

[Ken Winters]

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.
>