Reset sequences before loading fixtures (maybe)

[davars]

Currently the only time sequences are modified is after fixtures are loaded. I propose that, in addition to the current behavior, to set sequences to 1 before loading fixtures.

When omitting the serial columns from the fixture files, subsequent test runs result in fixture records with serial values greater than ResetSequencesTo. Thus when the sequences are reset, it is reset to a value before the fixture records.

That was confusing to type. Example, run 1:

  id   |       name        
-------+-------------------
     1 | 1) fixture
 10000 | 2) from test
 10001 | 3) also from test

Run 2:

  id   |       name        
-------+-------------------
 10002 | 1) fixture
 10000 | 2) from test
 10001 | 3) also from test

As soon as you increase the number of rows generated by a given run, conflict.

I've worked around this by specifying ids in the fixture files. This is probably a good practice anyway, and the current behavior acts as a reasonable forcing function. An alternative fix for this issue might be simply documenting a best practice of specifying values for serial columns.

A robust fix would be to take the max of the serial columns, though that's a bit more involved. The query in this question would be a good starting point though: https://dba.stackexchange.com/questions/47098/how-do-i-determine-if-a-column-is-defined-as-a-serial-data-type-instead-of-an-in

TLDR, please do one of:

1. Reset sequences to 1 before loading fixtures then to ResetSequencesTo afterwards.
2. Update docs to recommend that all serial columns have values and that they be less than ResetSequencesTo
3. At least in the case of postgres, set ResetSequencesTo automatically using the result of select max(<serial column>)+1 from <schema>.<table>.

[andreynering]

Hi @davars, thanks for opening this issue!

I never noticed this behavior, exactly because I always specified ID columns in the fixtures

AFAIK, you're kind of obligated to inform IDs if that table is referenced in another one, specially if you have foreign key constraints. Otherwise, should be fine

I think we can do both 1) and 2) here, i.e.: update documentation suggesting informing IDs on fixtures, but also do the fix in case someone prefer not informing them