data-fixtures
data-fixtures copied to clipboard
doctrine
Recreate exists sequences on truncate table
In case of sequences based auto-increment (for example in PgSQL), fixture loading not clean sequence. This causes certain difficulties with testing, for example, when we need to link cross project entities.
This PR resolve that issue, by re-creating sequences, if fixtures loading requested with "truncate" flag.
TBH, I disagree here. If you need to rely on specific identifiers, sequences are the wrong solution anyways, so resetting them isn’t necessary. If you need to know what entity to reference, there’s a section in the readme that explains how to do that: https://github.com/doctrine/data-fixtures/blob/master/README.md
All in all, I don’t think this should be merged, but I’m happy to hear your argument for it.
I'd also add that requiring stable identifiers in a test suite is extremely dangerous: you are hardcoding assumption about sequence generation that should be details of the system, rather than features
@alcaeus README.md provides info, how to made connection between two entities in fixtures via the addReference method, this can only be used if fixtures are loaded through one project. But what if we have related fixtures in several projects with different code base? For example:
- we have a service that provides user authorization (for example, a JWT generator)
- a service that works with tokens provided by the first service, and contains in some of its entities a link to the user id from the first service
Then don't assume on the order of your sequence, but use special, hardcoded identifiers. Using sequences in such instances is extremely risky.
What is the risk, in using sequences? Using hardcoded identifiers is also way, but it more difficult, because in that case, I need to create custom doctrine generator, that will be check, if id set to entity or not.
You should not rely on the sequence assigning the same values on subsequent operations - the only thing you can count on is that they will assign sequential values without duplicates. If you are relying on hardcoded identifiers, you need to control both sides: the generation and the consumption of these identifiers.