From 1.8 onwards, this crashes: >>> a = MyModel() # Don't save >>> b = MyOtherModel(fkey_to_mymodel=a) In turn, it breaks: class MyModelFactory(factory.django.DjangoModelFactory): class Meta: model = MyModel class MyOtherModelFactory(factory.django.DjangoModelFactory): class Meta: model = MyOtherModel fkey_to_mymodel = factory.SubFactory(MyModelFactory) MyOtherModelFactory.build() # Breaks The error message is: Cannot assign "MyModel()": "MyModel" instance isn't saved in the database. See https://code.djangoproject.com/ticket/10811 for details.
The previous version tries to use ``cls._default_manager`` all the time, which breaks with ``manager.using(db_name)``.
Previously, they ran as post_generation hooks, meaning that they couldn't be checked in a model's ``save()`` method, for instance.
The ``factory.django.DjangoModelFactory`` now takes an extra option: ``` class MyFactory(factory.django.DjangoModelFactory): class Meta: model = models.MyModel database = 'replica' ``` This will create all instances of ``models.Model`` in the ``'replica'`` database.
Previously, if a factory was decorated with ``@mute_signals`` and one of its descendant called another one of its descendant, signals weren't unmuted properly.
This allows the following idiom: ``user = factory.fuzzy.FuzzyChoice(User.objects.all())`` Previously, the ``User.objects.all()`` queryset would have been evaluated *at import time*; it is now evaluated with the first use of the ``FuzzyChoice``.
Users may now call ``factory.fuzzy.get_random_state()`` to retrieve the current random generator's state (isolated from the one used in Python's ``random``). That state can then be reinjected with ``factory.fuzzy.set_random_state(state)``.
Related to issues #78, #92, #103, #111, #153, #170 The default value of all sequences is now 0; the automagic ``_setup_next_sequence`` behavior of Django/SQLAlchemy has been removed. This feature's only goal was to allow the following scenario: 1. Run a Python script that uses MyFactory.create() a couple of times (with a unique field based on the sequence counter) 2. Run the same Python script a second time Without the magical ``_setup_next_sequence``, the Sequence counter would be set to 0 at the beginning of each script run, so both runs would generate objects with the same values for the unique field ; thus conflicting and crashing. The above behavior having only a very limited use and bringing various issues (hitting the database on ``build()``, problems with non-integer or composite primary key columns, ...), it has been removed. It could still be emulated through custom ``_setup_next_sequence`` methods, or by calling ``MyFactory.reset_sequence()``.