Posted by Damien Tournoud on October 5, 2012 at 1:06pm
4 followers
| Project: | Drupal Commerce |
| Version: | 7.x-1.x-dev |
| Component: | Other |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
For consistency with the change in {commerce_order} done in #1363826: Deadlock issues when saving orders concurrently, we should not use 0 as the default value for revision_id of {commerce_payment_transaction} and {commerce_customer_profile}.
This avoids the database from having to obtain a gap lock at the beginning of the unique key, thus increasing the concurrency in some types of load.
Comments
#2
Untested patch. The change in {commerce_product} is purely for consistency. It's a non-operation and as a consequence doesn't need an update function.
#3
Was about to commit the attached (fixed the calls to db_change_field()) when I reread your comment and saw you intentionally didn't update commerce_product. Not entirely sure what you mean by it being a "non-operation" - any site created using Commerce 1.2 or 1.3 would have a default value of 0 still set for the revision_id column on that table, just not those that updated from 1.1 or earlier to 1.2 or later.
Did you leave it out for performance concerns or should I just commit my update as is?
#4
Committed.
#5
Automatically closed -- issue fixed for 2 weeks with no activity.