Hi, Last night I converted E-Commerces old update system to the very cool new one. However I did run over 1 issue. When I am loading a fresh version of the schema, how do I tell the system which revisions have already been loaded. I know that the update system takes this from the system table, but I couldn't even find where Drupal does this. If anyone can enlighten me, I will be much appreciated. Thanks in advance. Gordon.
Hi, I don't know if this was because everyone was at DrupalCon or no one really knows. But I have worked out the answers to my questions. On Tue, 2006-02-07 at 10:15 +1100, Gordon Heydon wrote:
Hi,
Last night I converted E-Commerces old update system to the very cool new one. However I did run over 1 issue.
When I am loading a fresh version of the schema, how do I tell the system which revisions have already been loaded.
I know that the update system takes this from the system table, but I couldn't even find where Drupal does this.
If anyone can enlighten me, I will be much appreciated.
What happens is that when you install a new module is 2 things happen. 1. all the .install files are included and {module name}_update_n, where n is considered the schema version is inserted into the system table. 2. the {module name}_install() is called where if you want you can create the database tables. I still haven't really found out much information on the 4.7 update system which this is hooked into, hopefully the documentation team has something that they are putting together. I hope this helps anyone else. Gordon.
Gordon Heydon wrote:
What happens is that when you install a new module is 2 things happen.
1. all the .install files are included and {module name}_update_n, where n is considered the schema version is inserted into the system table. 2. the {module name}_install() is called where if you want you can create the database tables.
Yep, thats exactly right.
I still haven't really found out much information on the 4.7 update system which this is hooked into, hopefully the documentation team has something that they are putting together.
Go ahead and throw it in whereever it fits. There is some incoming hook documentation over at http://drupal.org/node/48722. -- Neil Drumm http://delocalizedham.com/
Hi, On Tue, 2006-02-14 at 19:33 -0800, Neil Drumm wrote:
Gordon Heydon wrote:
What happens is that when you install a new module is 2 things happen.
1. all the .install files are included and {module name}_update_n, where n is considered the schema version is inserted into the system table. 2. the {module name}_install() is called where if you want you can create the database tables.
Yep, thats exactly right.
Cool, 1 question about the best method of using this for E-Commerce since it is made of multiple modules. At this stage I have just moved all this into the store.install, but should I instead use an individual install file for each module. So there would be a product.install, cart.install, payment.install, etc or leave the core modules in the store.install?
I still haven't really found out much information on the 4.7 update system which this is hooked into, hopefully the documentation team has something that they are putting together.
Go ahead and throw it in whereever it fits. There is some incoming hook documentation over at http://drupal.org/node/48722.
I think the hook documentation will cover it, but the developer handbook most likely needs some reference to this. It is a pity that there hook_install() doesn't have a method for stopping the install of the module because something failed or there is a dependency missing. Gordon.
Gordon Heydon wrote:
At this stage I have just moved all this into the store.install, but should I instead use an individual install file for each module. So there would be a product.install, cart.install, payment.install, etc or leave the core modules in the store.install?
One per module usually. Ecommerce might be a bit of an exception, but I don't think so.
It is a pity that there hook_install() doesn't have a method for stopping the install of the module because something failed or there is a dependency missing.
Simple patches get in. All that fancy stuff can be added now if anyone wants to write it. Probably the most needed thing is a pre-check on install and update for create, alter, etc permissions. Everyone keeps saying to try creating a temporary table and see if there is an error. PHP's "error handling" scares me. -- Neil Drumm http://delocalizedham.com/
On Tuesday 14 February 2006 08:42 pm, Neil Drumm wrote:
Gordon Heydon wrote:
At this stage I have just moved all this into the store.install, but should I instead use an individual install file for each module. So there would be a product.install, cart.install, payment.install, etc or leave the core modules in the store.install?
One per module usually. Ecommerce might be a bit of an exception, but I don't think so.
Unless it's changed with the heavy development that is going on, ecommerce has it's own contrib modules. I would think that at least those contrib modules would need separate *.install files. -- Jason Flatt http://www.oadae.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 13; Cramer, 11; Travis, 9; Angela; Harry, 5; and William, 12:04 am, 12-29-2005) Linux User: http://www.sourcemage.org/ Drupal Fanatic: http://drupal.org/
Hi, On Wed, 2006-02-15 at 07:25 -0800, Jason Flatt wrote:
On Tuesday 14 February 2006 08:42 pm, Neil Drumm wrote:
Gordon Heydon wrote:
At this stage I have just moved all this into the store.install, but should I instead use an individual install file for each module. So there would be a product.install, cart.install, payment.install, etc or leave the core modules in the store.install?
One per module usually. Ecommerce might be a bit of an exception, but I don't think so.
Unless it's changed with the heavy development that is going on, ecommerce has it's own contrib modules. I would think that at least those contrib modules would need separate *.install files.
Yes the contrib modules will have there own .install files, but the core modules I am lean towards spitting it all back up over the individual files. Modules like paypal not everyone enables it, so you don't really need to create the ec_payment_paypal table. Gordon.
participants (3)
-
Gordon Heydon -
Jason Flatt -
Neil Drumm