D6 SAPI: using hook_install to ALTER {tables}
Hello, I just read through the Schema API documentation: http://drupal.org/node/146843 All the examples of hook_install() assume the module is creating a whole new table. E.g. here http://drupal.org/node/146862 and here: http://api.drupal.org/api/function/hook_install function hook_install() { drupal_install_schema('upload'); } What if a contrib module wants to ALTER an existing table (created by another module)? Q1) Do I still use hook_schema() to define the extra field and call it from hook_install() as in the examples? Q2) Or, do I call db_add_field() from hook_install()? Q3) Is it considered best practice to create your own tables rather than adding fields to existing tables "belonging" to other modules? Blessings, Augustin.
On Dec 27, 2007, at 12:15 AM, Augustin (Beginner) wrote:
Q3) Is it considered best practice to create your own tables rather than adding fields to existing tables "belonging" to other modules?
definitely! the other module might alter the schema and your data could be destroyed. for example, sometimes, the best way to add a new (computed) column is to create a new table with the schema you need, populate it with fancy SELECT logic, and then drop the old one[1]. if your contrib has hidden its own columns in the original table, the author of the schema update won't know about your columns and will blindly drop all your data after safely migrating their own columns to the new table. -derek (dww) [1] see for example, http://drupal.org/node/203313 http://drupal.org/files/issues/project_203313_releases_table.patch_5.txt function project_release_update_5200()
On Thursday 27 December 2007 18:44, Derek Wright wrote:
Q3) Is it considered best practice to create your own tables rather than adding fields to existing tables "belonging" to other modules?
definitely! the other module might alter the schema and your data could be destroyed.
Thanks. I documented it in the title :) If one tells me where else this should be documented, I'll do it. Blessings, Augustin.
Q3) Is it considered best practice to create your own tables rather than adding fields to existing tables "belonging" to other modules?
definitely! the other module might alter the schema and your data could be destroyed.
for example, sometimes, the best way to add a new (computed) column is to create a new table with the schema you need, populate it with fancy SELECT logic, and then drop the old one[1]. if your contrib has hidden its own columns in the original table, the author of the schema update won't know about your columns and will blindly drop all your data after safely migrating their own columns to the new table.
-derek (dww)
i'll agree with dww that this is best practice for Contrib. But for a custom site, I think hook_schema_alter() is a terrific way to add columns to tables owned by other modules. this avoids joins, which can be very useful for improving performance. many core objects now use drupal_write_record() to write their data to the database and that function is designed to work with altered tables like this. In other words, core is deliberately moving towards allowing custom fields attached to "foreign" tables. We do need to some conventions for safe update functions so we avoid a scenario like dww describes.
What if a contrib module wants to ALTER an existing table (created by another module)?
Q1) Do I still use hook_schema() to define the extra field and call it from hook_install() as in the examples?
Q2) Or, do I call db_add_field() from hook_install()?
Q3) Is it considered best practice to create your own tables rather than adding fields to existing tables "belonging" to other modules?
Generally, case (3) is correct: Don't modify other modules' tables; create your own instead. D6 does in fact support a hook_schema_alter(). In principal, you could (a) implement hook_schema_alter() to put your changes into an existing table and (b) implement a hook_update_N() function or hook_install() function using the db_*() functions to actually make the change. However, no part of core (or contrib that I know of) does this and it certainly has not been tested. There are many unanswered questions; for example, what if the module whose table you altered changes its schema and drops the table? Your data will be lost. So it is best for now not to use it (and it is not documented for this exact reason). Thanks, Barry
participants (4)
-
Augustin (Beginner) -
Barry Jaspan -
Derek Wright -
Moshe Weitzman