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@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@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@gmail.com http://ken.therickards.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@gmail.com PGP: http://ermarian.net/downloads/0x27CA5C74