[development] Process in code when experiencing an install error in a custom module
earnie at users.sourceforge.net
Mon Oct 8 11:37:58 UTC 2012
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.
On Sun, Oct 7, 2012 at 4:56 PM, Patrick Dawkins <pjcdawkins at 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 at sidepotsinternational.com>
>> 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.
More information about the development