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?

Comments

killes@www.drop.org’s picture

Considering that drupal.org itself has such a setup, this is of some importance.

sun’s picture

Issue tags: +simpletests

Any 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).

killes@www.drop.org’s picture

maybe it is possible to create a function that determines the to be expected next ID by querying the DB?

nnewton’s picture

That is certainly possible for MySQL, the problem will be making it portable to postgres.

boombatower’s picture

We 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.

bjaspan’s picture

Is 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.

bjaspan’s picture

Oh, 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.

mr.baileys’s picture

scor’s picture

maybe it is possible to create a function that determines the to be expected next ID by querying the DB?

Would 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?

bleen’s picture

@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

scor’s picture

@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....

tstoeckler’s picture

scor’s picture

db_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).

scor’s picture

Status: Active » Needs review
StatusFileSize
new6.02 KB

I 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.

sun’s picture

+++ modules/simpletest/simpletest.module
@@ -130,6 +130,16 @@ function simpletest_run_tests($test_list, $reporter = 'drupal') {
+  // Inserts two records in the database to find out the value of auto_increment
+  // for this database.
+  $auto_increment_id1 = db_insert('simpletest_auto_increment')
+    ->useDefaults(array('id'))
+    ->execute();

Very odd that this has to be done manually. Aren't there PDO methods to retrieve that info?

Powered by Dreditor.

Status: Needs review » Needs work

The last submitted patch, 549662_14_test_auto_increment.patch, failed testing.

scor’s picture

Status: Needs work » Needs review
StatusFileSize
new4.41 KB

Very odd that this has to be done manually. Aren't there PDO methods to retrieve that info?

I doubt it. some database engines don't even have the notion of auto_increment.

reroll against fresh head.

Status: Needs review » Needs work

The last submitted patch, 549662_17_test_auto_increment.patch, failed testing.

scor’s picture

ah, 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.

robloach’s picture

anavarre’s picture

Version: 7.x-dev » 8.0.x-dev
Parent issue: » #1962572: [META] Tests fail when auto-increment is not 1

Looks like this should be fixed in 8.0.x-dev first and backported to 7.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

quietone’s picture

Component: simpletest.module » phpunit

Triaging 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.

Version: 8.9.x-dev » 9.2.x-dev

Drupal 8 is end-of-life as of November 17, 2021. There will not be further changes made to Drupal 8. Bugfixes are now made to the 9.3.x and higher branches only. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.15 was released on June 1st, 2022 and is the final full bugfix release for the Drupal 9.3.x series. Drupal 9.3.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.4.x-dev branch from now on, and new development or disruptive changes should be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.9 was released on December 7, 2022 and is the final full bugfix release for the Drupal 9.4.x series. Drupal 9.4.x will not receive any further development aside from security fixes. Drupal 9 bug reports should be targeted for the 9.5.x-dev branch from now on, and new development or disruptive changes should be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

pameeela’s picture

Status: Needs work » Closed (duplicate)
Issue tags: -simpletests +Bug Smash Initiative
Related issues: +#1962572: [META] Tests fail when auto-increment is not 1

There 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