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 <[email protected]> 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 <[email protected]> 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 > [email protected] > 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: [email protected] PGP: http://ermarian.net/downloads/0x27CA5C74
