Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
DjangoModelFactory.build hits the database #111
given this constellation:
The test case will hit the database when generating an ID for the model (Stacktrace when using py.test that detects database usage in tests: https://gist.github.com/hannesstruss/f60e038daa588318ea57 )
I would expect .build() to not touch the database at all, but to create in-memory/test-local objects only. As far as I remember that was also how it worked before all Django-specific code was moved to DjangoModelFactory.
If this is expected, sorry for missing the memo :) What would be the best practice then to share code between a factory that does and one that doesn't save the model?
I tested in 2.2.1/Django 1.6.
That's a recurring issue I have with the "auto-next-sequence" code, which I haven't gotten to fix yet : it requires a big rewrite of some internals to pass the "build or create" context around.
The simplest way to solve this would be to override the
Hi, one problem with that solution is that I'm using sequence to disambiguate unique fields (eg: username) and returning the same value for the sequence raises
The best solution I could come with is just maintaining a global counter since I don't care what value the sequence has but that is unique everytime and leaves the database untouched:
_SEQUENCE = 1 _SEQUENCE_LOCK = threading.Lock() ... @classmethod def _setup_next_sequence(cls): with cls._SEQUENCE_LOCK: cls._SEQUENCE += 1 return cls._SEQUENCE