Process in code when experiencing an install error in a custom module
I'm curious what others are building into their module install process in the event of an error partway through. For example, if your install script creates one or more bundles, fields and field instances, if an error occurs at some point during that process, do you handle it all like a transaction and back out what you have created to that point? My instinct would be to do that, though I realize it can get complicated, such as the event where some of the fields that were to be created earlier on in the process already existed, etc. I'm asking, though, because of the several modules I've looked at so far, none seem to be doing this. Jeff --- drupal.org/user/367108 linkedin.com/in/jeffrgreenberg accidentalcoder.com / ayendesigns.com @accidentalcoder
I hadn’t thought of doing that. Sounds like it should be best practice. Thanks for bringing it up. On Oct 6, 2012, at 8:28 PM, Jeff Greenberg wrote:
I'm curious what others are building into their module install process in the event of an error partway through. For example, if your install script creates one or more bundles, fields and field instances, if an error occurs at some point during that process, do you handle it all like a transaction and back out what you have created to that point?
My instinct would be to do that, though I realize it can get complicated, such as the event where some of the fields that were to be created earlier on in the process already existed, etc. I'm asking, though, because of the several modules I've looked at so far, none seem to be doing this.
I'm not sure about that; I don't really see what problem it would solve. An install error might be caused by a bug in the contrib module, in which case the module's broken (so this becomes moot), or it might be caused somewhere in the Drupal core API (not the responsibility of contrib), or some problem in the host system, in which case it's the host's problem. If code fails it should fail hard, right? If you're trying to work around failures of Drupal core, then patch core instead. There are some core issues around data integrity (e.g. http://drupal.org/node/911352). And copying the behaviour of well-established, stable modules, with caution, is probably a reasonable rule of thumb. On 7 October 2012 04:25, Darren Oh <darrenoh@sidepotsinternational.com>wrote:
I hadn’t thought of doing that. Sounds like it should be best practice. Thanks for bringing it up.
On Oct 6, 2012, at 8:28 PM, Jeff Greenberg wrote:
I'm curious what others are building into their module install process in the event of an error partway through. For example, if your install script creates one or more bundles, fields and field instances, if an error occurs at some point during that process, do you handle it all like a transaction and back out what you have created to that point?
My instinct would be to do that, though I realize it can get complicated, such as the event where some of the fields that were to be created earlier on in the process already existed, etc. I'm asking, though, because of the several modules I've looked at so far, none seem to be doing this.
Patrick, Transactionalizing the install process would allow the steps of the install for the DB portions to rollback to the initial state should the process fail within the install method. Therefore the problem solved by this would be the issue of some steps having already been performed during the install phase and the need to perform those steps again; there is no need to filter the logic for the possibility. Earnie On Sun, Oct 7, 2012 at 4:56 PM, Patrick Dawkins <pjcdawkins@gmail.com> wrote:
I'm not sure about that; I don't really see what problem it would solve. An install error might be caused by a bug in the contrib module, in which case the module's broken (so this becomes moot), or it might be caused somewhere in the Drupal core API (not the responsibility of contrib), or some problem in the host system, in which case it's the host's problem. If code fails it should fail hard, right? If you're trying to work around failures of Drupal core, then patch core instead. There are some core issues around data integrity (e.g. http://drupal.org/node/911352).
And copying the behaviour of well-established, stable modules, with caution, is probably a reasonable rule of thumb.
On 7 October 2012 04:25, Darren Oh <darrenoh@sidepotsinternational.com> wrote:
I hadn’t thought of doing that. Sounds like it should be best practice. Thanks for bringing it up.
On Oct 6, 2012, at 8:28 PM, Jeff Greenberg wrote:
I'm curious what others are building into their module install process in the event of an error partway through. For example, if your install script creates one or more bundles, fields and field instances, if an error occurs at some point during that process, do you handle it all like a transaction and back out what you have created to that point?
My instinct would be to do that, though I realize it can get complicated, such as the event where some of the fields that were to be created earlier on in the process already existed, etc. I'm asking, though, because of the several modules I've looked at so far, none seem to be doing this.
-- Earnie -- https://sites.google.com/site/earnieboyd
Right. One example is simply losing the database connection in the middle of the process. Basically, for whatever cause the installation is unable to finish, I am typically then left in a position where I cannot uninstall the module and cannot reinstall it because of spurious db entries. And since Drupal doesn't really care which type of db tables are being created (and at some point, which type of db), depending on db transactions and rollback is not viable.
On Mon, Oct 8, 2012 at 7:59 AM, Jeff Greenberg <listmail.ayendesigns@gmail.com> wrote:
Right. One example is simply losing the database connection in the middle of the process. Basically, for whatever cause the installation is unable to finish, I am typically then left in a position where I cannot uninstall the module and cannot reinstall it because of spurious db entries. And since Drupal doesn't really care which type of db tables are being created (and at some point, which type of db), depending on db transactions and rollback is not viable.
You could always check to see if the table exists and if it does drop it first. But if the Drupal system table row already states installed you're really SOL with the failed install anyway and must manually reset the column in the system table. Another step that could be performed is a variable_set() which indicates a successful installation so that you can filter the drop based on whether or not the install occurred successfully once. Make sure to variable_del() on uninstall. -- Earnie -- https://sites.google.com/site/earnieboyd
participants (4)
-
Darren Oh -
Earnie Boyd -
Jeff Greenberg -
Patrick Dawkins