| Project: | Drupal core |
| Version: | 6.x-dev |
| Component: | install system |
| Category: | bug report |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | patch (to be ported) |
Issue Summary
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.
Comments
#1
could you not force a schema rebuild?
#2
or, implement hook_enable and put your drupal_write_record calls in there.
#3
Hi,
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.
#4
Hi,
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
#5
It 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().
#6
Re-assigning to 7.x as it happens in the latest HEAD version too.
#7
Stella, you are right.
I was using hook_enable(), but I tested deactivating and reactivating my module instead of reinstalling it.
#9
Bah, 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.)
#10
same 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
drupal_get_schema(NULL, TRUE);EDIT: this only works for hook_enable().
#11
A workaround is to use register_shutdown_function
register_shutdown_function('drupal_get_schema', NULL, TRUE);register_shutdown_function('custom_function_using_drupal_write_record');
#12
The following patch runs
drupal_get_schema(NULL, TRUE);after invoking hook_install() and before invoking hook_enable().#13
The last submitted patch failed testing.
#14
#15
The last submitted patch failed testing.
#16
Subscribing, 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.
#17
This appears to fix the issue with enabling shortcut module after installation.
Rerolling because of fuzz
#18
Yup, 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.
#19
Committed to CVS HEAD. Thanks!
#20
setting to 6.x since this issue was originally reported for 6.x
#21
Also, 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
#22
I'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?
#23
Is there any interest in this issue? Has this been fixed in the latest D6?
#24
#25
it looks that it is still not possible in D6.22 to populate a table (using drupal_write_record) in hook_install.
#26
#27
Is this attended to be fixed?