- 🇦🇺Australia pameeela
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.
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?
Closed: duplicate
11.0 🔥
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
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.