Given the function xyz_install installs schema xyz.
Now it is not possible to use drupal_get_schema('xyz') from within the function, because the schema doesn't seem to be automatically rebuilt.
Therefore it is also not possible to use drupal_write_record() from within the _install function, which would be a great thing to add some records to the newly created database.
You could say that's "by design" and should stay the way it is. Then it should be at least properly documented, so developers don't fiddle around with drupal_write_record(), before finding out that it can't be used.
But falling back to the good old db_query means this is still a barrier to creating cross-dbs compatible code. That's not what we wanted when we introduced the schema system. Therefore I mark this a bug.
| Comment | File | Size | Author |
|---|---|---|---|
| #28 | schema_not_available-200931-28.patch | 459 bytes | albert volkman |
| #17 | module.inc-200931-15.patch | 753 bytes | asimmonds |
| #14 | module.inc-200931-14.patch | 734 bytes | darren oh |
| #12 | module.inc-200931-12.patch | 634 bytes | darren oh |
| #12 | module.inc-200931-12_D6.patch | 669 bytes | darren oh |
Comments
Comment #1
moshe weitzman commentedcould you not force a schema rebuild?
Comment #2
Anonymous (not verified) commentedor, implement hook_enable and put your drupal_write_record calls in there.
Comment #3
mercmobily commentedHi,
Justin: that's not really a solution. I am writing a module and would like to set some defaults when the module is _installed_, not _enabled_. The difference is quite important. People can enable/disable a module and they shouldn't expect the module to set/reset some default values as they do that.
I really, really think drupal_write_record() needs to work in hook_install()...
Merc.
Comment #4
ingacosta commentedHi,
I have the same issue with my module. I think, like you, it's a bug that must be resolved.
Meanwhile I'm using hook_enable.
Regards
Hernán
Comment #5
stella commentedIt isn't possible to use drupal_get_schema() in hook_enable() functions either. It is returning false for me. It's happening in a module where the tables have already been created on a previous installation of the module. The module was then disabled and re-enabled and it still returns false. I'm not using drupal_get_schema() directly, but rather through drupal_write_record().
Comment #6
stella commentedRe-assigning to 7.x as it happens in the latest HEAD version too.
Comment #7
ingacosta commentedStella, you are right.
I was using hook_enable(), but I tested deactivating and reactivating my module instead of reinstalling it.
Comment #9
ssiruguri commentedBah, I had a long comment here saying I couldn't understand why this wasn't working, and then I realized why it isn't -- a new module can't be enabled until it is installed and so the schema is not available (rather the module is not in the module list returned by module_list() while inside the _install hook.)
Comment #10
scor commentedsame problem here. drupal_write_record() is not working in neither hook_install() nor hook_enable(). A work around I use is to force a schema rebuild
EDIT: this only works for hook_enable().
Comment #11
ufku commentedA workaround is to use register_shutdown_function
Comment #12
darren ohThe following patch runs
drupal_get_schema(NULL, TRUE);after invoking hook_install() and before invoking hook_enable().Comment #14
darren ohComment #16
David_Rothstein commentedSubscribing, and moving to critical in anticipation of a possible commit at #511286: D7UX: Implement customizable shortcuts, which needs this in order to be enabled correctly on an existing Drupal install.
Comment #17
asimmonds commentedThis appears to fix the issue with enabling shortcut module after installation.
Rerolling because of fuzz
Comment #18
David_Rothstein commentedYup, this works and should go in.
In addition to the shortcut module, I also found that this bug can cause subtle problems with certain installation profiles. If you have an install profile that uses enough modules which depend on each other's schema in hook_enable() - for example, the way forum module depends on taxonomy - then running a command line installation (where the installation happens in one page request) causes failures because the schema is not up to date. This patches fixes that issue as well.
Comment #19
dries commentedCommitted to CVS HEAD. Thanks!
Comment #20
scor commentedsetting to 6.x since this issue was originally reported for 6.x
Comment #21
David_Rothstein commentedAlso, the original bug report was about hook_install(), whereas this patch only fixed things for hook_enable(), so I've split the hook_install() stuff off into a separate issue at #620298: Schema not available in hook_install().
That one is a less serious bug, though, since there are workarounds for doing what you want to do in hook_install() in hook_enable() instead - just run a check first to make sure it was not already done before. For an example, see http://api.drupal.org/api/function/shortcut_enable/7
Comment #22
tmetzger commentedI've noticed a similar issue. I'm trying to create workflow-related records in the hook_install of a custom module, but I can't use workflow_create() because it uses drupal_write_record. Keep in mind, this is long after workflow has been installed. I can make it work by manually reloading the modules page, which seems to initialize the workflow module properly.
I'd rather be doing all this inside my installation profile, but it seems I can't use other modules upon which my modules depend.
Is there a way to get all previously loaded modules properly initialized within the installation profile, so I can call them from mine?
Comment #23
dpearcefl commentedIs there any interest in this issue? Has this been fixed in the latest D6?
Comment #24
dpearcefl commentedComment #25
schildi commentedit looks that it is still not possible in D6.22 to populate a table (using drupal_write_record) in hook_install.
Comment #26
zfreaker commentedComment #27
zfreaker commentedIs this attended to be fixed?
Comment #28
albert volkman commentedHere's my attempt at a D6 backport.