[development] Doing hook_update_N() when module is installed

[Earnie Boyd]

On Fri, 13 Nov 2009 Randy Fay wrote:

> Thanks for your comments on this!
>

You're welcome.  Let me apologize for being late in responding.  Other  
duties kept me off list for quite a while.

> While you're right that the original intent of hook_install() is to do a *
> schema* setup and the original intent of hook_update_N() it to update that
> when change occur down the line, they are both actually and widely used to
> set up the Drupal configuration in non-schema ways so that it's ready for
> the module.  You yourself mentioned in a later message a variable_set()
> which is a configuration change, not a schema change.
>

I do understand that hook_install and hook_update_N have been misused  
to help a package maintain sanity.  It is that misuse that needs to be  
addressed by providing either updated documentation for hook_install  
and hook_update_N to allow for the unintended use or to provide  
instruction for how to control the variable default values of a  
package during install and upgrade phases.

> I *think* that the reality is that these two functions are often used in a
> variety of ways to make sure configuration is correct for the current
> version of the module, not just in terms of schema.
>

Yes, I agree that they have been used this way but shouldn't be.   
Perhaps a specialized menu callback that is created during the install  
or update phases that can is then executed on first use and removed  
from then removed from the router table is what is needed for this.   
Only the install or update phase would create the menu callback within  
the menu router table.

> You mention the idea of setting up something for cron to do... but that
> would be a privately implemented hook_update_N, woudn't it?
>

No, a variable can be reset outside of the install/update phase so  
that it can be executed manually if desired.  In D7 hook_update_N will  
only be allowed to be executed once.

> In my case, which is a bit extreme, I'm writing a module whose only job is
> to do one-off configuration changes to staging*.drupal.org. There are 10 of
> these machines, and their configuration is slightly different from
> Drupal.org, but they are occasionally reinstalled with D.o's database. That
> means that the install needs to work to set the config correctly, and also
> that when a config change is introduced, hook_update_N (or a similar
> technique) needs to take care of it. We're trying to avoid reconfiguring
> everywhere.
>

The thing I dislike about this is you are requiring a installation of  
an update to your module just to make a configuration change.  If  
instead you put the changes in a INI file type and create a hook_cron  
(or even a hook_init if the code doesn't take very long) to check for  
a new file date you can make the configuration changes without  
shutting down the site for update.php.

> As others have mentioned, this pattern is quite common.
>

INI files are for configuration.  It makes sense to use what is  
already available for configurations and PHP can read them for you to  
the point that it returns an associative array of values.  You can  
even have a hierarchical tree array.

> A valuable discussion. I'm interested in hearing more.
>

Yes, I agree and I would like to hear more as well.

--
Earnie
-- http://r-feed.com/           -- http://for-my-kids.com/
-- http://www.4offer.biz/       -- http://give-me-an-offer.com/