The 'sequence' patch (http://drupal.org/node/149176) introduced a minor bug in form.inc's batch_process() :
we need to have the batch id to generate the error redirection url.

That error url was broken anyway since the 'op=error' query param was deprecated at some point during the work on the 'batch' feature. We now go to 'finished'.

Attached patch fixes both errors, plus a side-case 'undefined variable' warning in batch.inc's _batch_page for $output when browsing to an invalid 'op' query param.

CommentFileSizeAuthor
#7 batch_fix_6.patch7.82 KByched
#1 batch_fix_5.patch4.24 KByched
batch_fix_4.patch2.63 KByched
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yched’s picture

FileSize
4.24 KB

As both issues are related (follow-up to the db_last_insert_id() patch), I merged this patch with bjaspan / hunmonk's patch in http://drupal.org/node/152383 ('update.php fails on pgsql', because of missing value for not-null 'token' column in {batch} table).

Additionally, the patch :
- fixes a bug with successive batch sets when processing is 'paused' just after one set has been completed (we return progress = 100, and the following sets are not processed)
- moves the js-result callback to the new drupal_json(), function instead of drupal_set_header() / drupal_to_js(),

I can provide separate patches for those two last points, if needed. All fixes are needed if we want to go ahead with http://drupal.org/node/144337 (batch node access rebuild), though.

yched’s picture

Title: small batch bugfixes » batch API bugfixes
Priority: Normal » Critical

updating status according to reflect both http://drupal.org/node/152383 and http://drupal.org/node/144337 'critical' flag.

bjaspan’s picture

I'm fine with your merging my/hunmonk's batch patch into this one. I will review this patch (not tonight, though) if you look at http://drupal.org/node/157682. :-) It addresses a wide variety of update.php problems, including the batch problem (though it currently solves it as my previous patch did, not as this one does).

Dries’s picture

I reviewed this patch and I'm a bit puzzled by:

+      db_query('INSERT INTO {batch} (token) VALUES ("")');
+      $batch['id'] = db_last_insert_id('batch', 'bid');

What are you trying to achieve here? Could you document in the patch why it is important to have a valid bid -- will the other batch steps use this bid to write to the batch table? Please add one more line of documentation to make this clear.

That said, I think this may be fundamentally broken. 'bid' is a pimary key so there can only be one "" string in the database. When two batch processes run concurrently, this will trow SQL errors?

jakeg’s picture

To me, I'm not sure if I agree with this by bjaspan here http://drupal.org/node/152383#comment-270233:

My fix is to insert a temporary value explicitly for the 'token' column. Adding a default value would work as well, but my thinking is that a default value should be one that is actually correct most of the time unless a specific value is provided. In this case, a default value will never be right and will always be immediately overriden, so it makes more sense to demonstrate that explicitly in the code.

but then doing this:

<?php
+      db_query('INSERT INTO {batch} (token) VALUES ("")');
+      $batch['id'] = db_last_insert_id('batch', 'bid');
?>

The way I've always dealt with MySQL, is that every varchar column gets a default value. Why don't we just add the default value for the token varchar ( http://drupal.org/node/158918 ).

yched’s picture

@Dries : this is puzzling essentially because the patch in #1 omits the part where 2 similar lines are removed 10 lines below - what the patch _intends_ to do is actually move those lines up, because we need the batch id a few lines earlier. Sorry for the confusion this caused. I'll post a new patch shortly.

@jakeg : -1. As I already explained on IRC, I do agree with bjaspan on this. Changing the schema would give a false impression on the semantics of the column, like an empty string is a valid value for token. It is not. We only use an empty string temporarily for technical reasons (ids are now known post-insert rather than pre-insert in D5), that are anecdotal wrt db schema. Fixing the code is best suited in this specific case.

yched’s picture

FileSize
7.82 KB

Updated patch :
- clarifies the INSERT / db_last_insert_id / UPDATE part
- Improved processing speed by taking page bootstrap out of the '1 sec execution time' limit.
- my fix for the "100% progress prevents subsequent sets to be processed" bug I mentioned in #1 was wrong, better fix attached. It should also (slightly) improve processing speed, as we only gather progress info when actually preparing progress feedback.
- fixes an 'undefined index' warning with programmatic (and batching) forms : no db storage, so no batch['id'].

Tested (MySQL only) with update.php, and with my own regression tests...

moshe weitzman’s picture

Status: Needs review » Reviewed & tested by the community

i tested this along with node_access_rebuild patch. all worked well - this one is ready.

bjaspan’s picture

I meant to test this on pgsql and dropped the ball. Kicked in gear by Moshe, I just did.

I upgraded a Drupal 5.1 site with all optional core modules except locale enabled by Drupal 6 with this patch applied and with my update.php patch applied (I got one conflict with my patch b/c it also tries to fix a batch table problem that this patch already fixed). I got no errors, which improves on my patch that produces one error about 'id' being undefined somewhere in the batch code. Also, the final schema report is clean.

So, +1 from me. When this is applied, I'll re-roll my update.php patch it is will be ready, too.

Dries’s picture

Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

Anonymous’s picture

Status: Fixed » Closed (fixed)