So I almost want to apologize for raising this issue, but I was recently verifying that Drupal 7 works well on a database cluster that has auto_increment offsets: Meaning that auto_inc columns do not increment by 1, but increment by X, where X is admin configurable. For example, my test cluster was incrementing by 5 on the master (first value 5, second 10, third 15). As part of testing this, I was excited to use Drupal's new test coverage. I was mildly surprised to get over 300 failures and many exceptions on the first run. After investigating, I have found that many of these errors (I'm not fully through them all yet) are caused by unit tests making assumptions on auto_increment values.
For example, in the database system test suite we run testAlterWithJoin which completely fails on an auto_increment offset system, because the join we are altering into the query has a condition with a hard coded "id" of 2. On my system that id was 15. Even after fixing that we have failures because of asserts like this:
$this->assertEqual($records[0]->$tid_field, 4, t('Correct data retrieved.'));
This tid is 35 on my system. My system is correct, but the test fails. My question here is what do we want to do about this? I am an edge case in that I end up on auto_inc offset systems about 90% of the time. While this makes the unit tests pretty useless for me, does it matter? I can work on fixing this, but am not going to do it if its going to benefit only 5 people.
What do people think of this? Do we care about unit tests running correctly on auto_inc offset clusters for core?
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | 549662_17_test_auto_increment.patch | 4.41 KB | scor |
| #14 | 549662_14_test_auto_increment.patch | 6.02 KB | scor |
Comments
Comment #1
killes@www.drop.org commentedConsidering that drupal.org itself has such a setup, this is of some importance.
Comment #2
sunAny code that wants to insert a particular id has to take additional measures to ensure the expected id.
So this is a bug. And I don't think that alternate auto_inc configurations are that seldom (after all, it's one of the few, valid staging/deployment practices).
Comment #3
killes@www.drop.org commentedmaybe it is possible to create a function that determines the to be expected next ID by querying the DB?
Comment #4
nnewton commentedThat is certainly possible for MySQL, the problem will be making it portable to postgres.
Comment #5
boombatower commentedWe most definitely need a facility if we are to convert all tests to use this. It needs to be as easy as possible. I really don't have much experience in the area so I'll leave that to others.
Once we have some sort of idea/solution I am happy to help implement the change or integrate with SimpleTest in whatever way is needed.
Comment #6
bjaspan commentedIs the facility to fix these test bugs not simply to remember the necessary return values to db_insert() and similar calls instead of just assuming they will increment by 1 each time?
Also, I wonder if this should really be a simpletest.module issue. It is in fact a bug in the test suite for any tests that fail on this kind of db setup. Maybe it is easier to just have one issue here, though.
Comment #7
bjaspan commentedOh, one other reason to fix these tests in addition to those listed above: Because some parts of D7 (and D6) have actual bugs pertaining to assumptions about the ids assigned to auto increment columns, and the easiest way to find and fix them is to run the tests on such a system, but that is only helpful if the tests are expected to pass.
Comment #8
mr.baileysMarked #739576: Many Drupal 7 tests fail with auto_increment* > 1 as a duplicate of this one.
Comment #9
scor commentedWould that work for any database engine? how about inserting two dummy records in a tmp table and get the auto_increment value by doing the difference of the ids?
Comment #10
bleen commented@scor ... can't different tables be set to have different auto increment increments? Ex: node is 5, 10 , 15 but user is 3,6,9
Comment #11
scor commented@bleen18 we're talking about the system variable used as default auto_increment value, see http://dev.mysql.com/doc/refman/5.0/en/replication-options-master.html#s....
Comment #12
tstoecklerhttp://api.drupal.org/api/function/db_next_id/7 ?
Comment #13
scor commenteddb_next_id() returns an id unique across a Drupal installation. It's not exactly what we need here. We could call it twice and compare the ids to guess the auto_increment value, but you have to ensure no other function called it in between... quite unlikely but not a great design IMO (having a dummy namespaced table is cleaner I think).
Comment #14
scor commentedI don't think we can use nextId() to detect the value of auto_increment, pgsql for example relies on its own built sequences. The attached patch adds an auto_increment table to the simpletest schema to detect the actual value of auto_increment(_increment). Simpletest exposes this value so that test cases can use it when necessary. I've provided an example fix for the Sequence API test which does not pass when auto_increment_increment is > 1. I've discovered #917134: dblog_cron() deletes too many records when auto_increment > 1 while trying to fix the DBlog tests. I've not added support for offset, but I suspect this will uncover more bugs.
I suspect this is not the best design but I'll let Jimmy suggest a better with simpletest. We might benefit from exposing the value of auto_increment in core, for example I could not think of a good fix for #917134: dblog_cron() deletes too many records when auto_increment > 1 without knowing this value.
Comment #15
sunVery odd that this has to be done manually. Aren't there PDO methods to retrieve that info?
Powered by Dreditor.
Comment #17
scor commentedI doubt it. some database engines don't even have the notion of auto_increment.
reroll against fresh head.
Comment #19
scor commentedah, this patch won't pass the tests since it requires to patch the client drupal site, and the PIFR clients will only patch the new Drupal instance being tested.
Comment #20
robloach#1962572: [META] Tests fail when auto-increment is not 1 too.
Comment #21
anavarreLooks like this should be fixed in 8.0.x-dev first and backported to 7.
Comment #30
quietone commentedTriaging issues in simpletest.module as part of the Bug Smash Initiative to determine if they should be in the Simpletest Project or core.
This looks like it should be in the testing system, changing to phpunit.
Comment #36
pameeela commentedThere is a meta issue for tests that fail because of this, there are currently two issues still open. So I think this should be closed in favour of the meta and child tickets, to avoid doubling up on effort.
#1962572: [META] Tests fail when auto-increment is not 1