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.Problem/Motivation
EntityReferenceFieldTest fails currently with PostgreSQL as database backend.
The Entity unit tests attempt to assign an integer for entity from 1 to 0xFFFFFFFF, but this is greater than the maximum size for integers in PostgreSQL. See Numeric DataType specification.
Test Backtrace:
Drupal\Core\Entity\EntityStorageException: SQLSTATE[22003]: Numeric value out of range: 7 ERROR: value "2620798132" is out of range for type integer LINE 1: ...3019entity_test_update_id_seq', GREATEST(MAX(id), '262079813... ^ in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 934 of /var/www/drupal8.dev/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object)
Drupal\Core\Entity\Entity->save()
Drupal\system\Tests\Entity\EntityReferenceFieldTest->testTargetEntityNoLoad()
Proposed resolution
Change the value from 0XFFFFFFFF to 0x7FFFFFF instead. This affects test only.
| Database | Maximum Safe Integer | |
|---|---|---|
| MySQL | 0XFFFFFFFF | |
| SQLite | 0X7FFFFFFFFFFFFFFF | |
| PostgreSQL | 0x7FFFFFFF | |
| SQL Server 2014 | 0x7FFFFFFF | |
| Oracle 10 | 0x7FFFFFFF |
Remaining tasks
Write patch.
User interface changes
None.
API changes
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | 2443655-16.patch | 903 bytes | daffie |
Comments
Comment #1
bzrudi71 CreditAttribution: bzrudi71 commentedThis seems like a random exception. Can't reproduce locally and got pass on testbpt also. We should keep an eye on this...
Comment #2
mradcliffeI ran this on my vagrant vm running debian with the above result.
Comment #3
bzrudi71 CreditAttribution: bzrudi71 commentedAh yes, that explains the random - nice. Should we really complicate things more than needed? I mean, it's just about creating a random value so why not using a value of 7FFFFFFF (int 2147483647) instead? That should be save enough for having some randomness and is save for all types of databases I guess :-)
Comment #4
BerdirAgreed, let's just use a max value that works for all database backends, should be a trivial fix then?
Comment #5
mradcliffeYes, that makes sense. Oracle, SQL Server, and PostgreSQL all have the same maximum signed integer (bigints obviously bigger). SQLite is absurdly large.
Comment #6
daffie CreditAttribution: daffie commentedComment #7
anksy CreditAttribution: anksy commentedTested the patch successfully. The tests don't throw any error.
Comment #8
alexpottLet's a comment to explain how the value is arrived at.
Comment #9
mradcliffeI was reading the patch on the bus this morning, and wondering the same thing about the need for a comment.
Comment #10
daffie CreditAttribution: daffie commentedComment added.
Comment #11
anksy CreditAttribution: anksy commented@daffie : Shouldn't the comment say "The value 0x7FFFFFFF is the maximum integer value that is ..." instead of lowest maximum integer value ...
Comment #12
bzrudi71 CreditAttribution: bzrudi71 commented@anksy: It's not wrong to say the lowest maximum value, as MySQL and SQLite allow for higher int values, so would something like this explain it better?
0x7FFFFFFF is the maximum allowed value for integers that works for all Drupal supported databases and is known to work for other databases like SQL Server 2014 and Oracle 10 too.
Comment #13
anksy CreditAttribution: anksy commented@bzrudi71 Yeah that explains it clearly. Its better.
Comment #14
daffie CreditAttribution: daffie commented@anksy: Can you do a review of the patch?
Comment #15
anksy CreditAttribution: anksy commented@daffie so should we change the comment as bzrudi71 suggested or keep it the same?
Comment #16
daffie CreditAttribution: daffie commentedI think that the text from bzrudi71 is better.
Comment #17
tstoecklerlooks good.
Comment #18
webchickCommitted and pushed to 8.0.x. Thanks!