[development] Doing hook_update_N() when module is installed
arancaytar.ilyaran at gmail.com
Fri Nov 13 09:09:20 UTC 2009
The pattern of hook_update_N() being related in any way to the install
functions is an unfortunate side effect of both being in the same
file. As I understand it, they should ideally remain separate: No
update function should be called anywhere in the module, nor call any
of the other functions (particularly hook_schema). This ensures that
a) update functions can safely be left as-is when the rest of the code
changes, and can be relied on to keep a clean upgrade path, and b) old
update functions can safely be deleted. A little duplicated code for a
new table is not so bad...
On Fri, Nov 13, 2009 at 1:08 AM, Ken Rickard <agentrickard at gmail.com> wrote:
> Yes, Moshe is right. hook_install() is better, though I prefer the
> hook_enable / hook_disable combo to running specific "must have"
> routines in hook_update_N.
> - Ken
> On Thu, Nov 12, 2009 at 4:07 PM, Moshe Weitzman <weitzman at tejasa.com> wrote:
>> We've run in this pattern a lot with economist.com. We avoided code
>> duplication for a while and just ran all our updates in
>> hook_install(). That became awful after a while since were doing and
>> undoing things that had changed over time during hook_install. Now, we
>> set ourselves up to the latest, good configuration in hook_install().
>> In a few cases, that does mean calling into an update function
>> directly but most of the time we just set the variables and such in
>> both the install and update hooks. Thats the drupal way, right now.
>> Also, I think Ken meant hook_install, not hook_enable when he offerred
>> a place to do one-time install related activity. hook_enable is
>> potentially run many times.
> Ken Rickard
> agentrickard at gmail.com
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare,
The lone and level sands stretch far away.
AOL: realarancaytar / 282026638
XMPP: arancaytar.ilyaran at gmail.com
More information about the development