Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.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.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 1804518-3.revision_id_default_values.patch | 4.73 KB | rszrama |
| #2 | 1804518-avoid-unnecessary-lock-revision-id.patch | 4.07 KB | Damien Tournoud |
| 1804518-avoid-unnecessary-lock-revision-id.patch | 5.06 KB | Damien Tournoud | |
Comments
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedUntested 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.
Comment #3
rszrama CreditAttribution: rszrama commentedWas 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?
Comment #4
rszrama CreditAttribution: rszrama commentedCommitted.