hook_schema() now in .install, not .schema
Public service announcement: Prior to http://drupal.org/node/150245, hook_schema() was always defined in a module's .schema file. There was never any good reason for it to be there. The bad reason was "to avoid parsing the extra code in .install." However, the results of hook_schema() are cached so the functions only have to be called when modules are enabled/disabled or when CCK type structures change. This is very rare and parsing the .install files only on those occasions is not a performance issue. Now, hook_schema() must be defined in .install. The good reason for this is that it makes much more sense to have the schema definition and the schema update functions in the same place. It will make bugs of the "changed hook_schema() without a hook_update_N() or vice versa" sort less likely. And it is where God intended hook_schema() to be (says the atheist). If this had been an actual emergency, your mail server would already have crashed. Thanks, Barry
Now, hook_schema() must be defined in .install.
Great! Is there a reason for putting hook_schema() not to the beginning of an install file? I just found it at the end of statistics.install, book.install and comment.install. I guess that schema definitions can not be found quickly if a module has "a few" updates. So we should better define a guideline to put _install(), _uninstall() and _schema() to the top of the .install file, shouldn't we? regards, Daniel
Quite true - I'd vote for _schema first, then _install/_uninstall, then _update_N. _schema holds structural information about the module _(un)install are 'only' operational, _update_N is 'only' incidental (and meant to be read from bottom up anyway) yched Daniel F. Kudwien a ecrit le 09/10/2007 02:20:
I guess that schema definitions can not be found quickly if a module has "a few" updates. So we should better define a guideline to put _install(), _uninstall() and _schema() to the top of the .install file, shouldn't we?
regards,
Daniel
Consistent .install file layout proposal is now available: http://drupal.org/node/181955 sun
Barry Jaspan wrote:
Public service announcement:
Prior to http://drupal.org/node/150245, hook_schema() was always defined in a module's .schema file. There was never any good reason for it to be there. The bad reason was "to avoid parsing the extra code in .install." However, the results of hook_schema() are cached so the functions only have to be called when modules are enabled/disabled or when CCK type structures change. This is very rare and parsing the .install files only on those occasions is not a performance issue.
Now, hook_schema() must be defined in .install. The good reason for this is that it makes much more sense to have the schema definition and the schema update functions in the same place. It will make bugs of the "changed hook_schema() without a hook_update_N() or vice versa" sort less likely. And it is where God intended hook_schema() to be (says the atheist).
If this had been an actual emergency, your mail server would already have crashed.
Personally, I think this was a mistake. Not that the idea itself wasn't good, but module developers have already started porting stuff over, and now there are no modules that can simultaneously work with Drupal 6-beta1 and Drupal 6-beta2. This is one of the things that can really frustrate module developers, and I don't see a pressing need for this change. Yes, it was an error and probably shouldn't have been this way, but it wasn't hurting anything, either.
Quoting Earl Miles <merlin@logrus.com>:
Barry Jaspan wrote:
Public service announcement:
Prior to http://drupal.org/node/150245, hook_schema() was always defined in a module's .schema file. There was never any good reason for it to be there. The bad reason was "to avoid parsing the extra code in .install." However, the results of hook_schema() are cached so the functions only have to be called when modules are enabled/disabled or when CCK type structures change. This is very rare and parsing the .install files only on those occasions is not a performance issue.
Now, hook_schema() must be defined in .install. The good reason for this is that it makes much more sense to have the schema definition and the schema update functions in the same place. It will make bugs of the "changed hook_schema() without a hook_update_N() or vice versa" sort less likely. And it is where God intended hook_schema() to be (says the atheist).
If this had been an actual emergency, your mail server would already have crashed.
Personally, I think this was a mistake.
Not that the idea itself wasn't good, but module developers have already started porting stuff over, and now there are no modules that can simultaneously work with Drupal 6-beta1 and Drupal 6-beta2. This is one of the things that can really frustrate module developers, and I don't see a pressing need for this change. Yes, it was an error and probably shouldn't have been this way, but it wasn't hurting anything, either.
And .schema is self explanatory. While .install is to be used only at install time at first glance (I know it is used during update as well). Tools can be developed using just the .schema alone. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
participants (6)
-
Barry Jaspan -
bilal bhat -
Daniel F. Kudwien -
Earl Miles -
Earnie Boyd -
Yves Chedemois