Andreas Braun

> Also class aliases will be needed since we change namespace. We haven't done so for inflector, lexer, collections, or other packages, which is why I didn't think of it....

> That should probably also change in major release of those packages + providing forward compat by adding class aliases in 1.x FWIW, this is something that has been discussed...

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

Then don't assume on the order of your sequence, but use special, hardcoded identifiers. Using sequences in such instances is extremely risky.

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

Thanks for pointing this out @W0rma! @ChrisTitos can you please check with the latest release and let me know if this is fixed?

Purging only tables based on the fixture classes is going to be difficult: there’s nothing stopping you from creating multiple different entities in a single fixture class, so the library...

Note that currently the purger has no idea of what you’re doing in your fixtures. I’m not saying it’s impossible, but it’s also not something that we can just fix....

I don't think we should update the documentation for the `Collection` interface: not all collection will implement this functionality that way.

@shehi that's wrong: all non-deprecated functionality has been extracted into other packages. If any library relies on transitive dependencies (e.g. import doctrine/data-fixtures and expect it to import doctrine/common), this is...