| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
See issue #280.
|
| |
|
|
|
|
|
|
|
| |
Connecting signals (with use_caching=True) inside mute_signals
was breaking unmute on exit. Paused receivers were not running.
This was caused by signal cache not being restored after unpatching.
Workaround is to clear signal cache on exit.
Fixes #212
|
| |
|
|
|
|
| |
The actual behavior of Django with custom managers and inherited
abstract models is rather complex, so this had to be adapted to the
actual Django source code.
|
| |
|
|
|
|
|
|
|
|
|
| |
factory.Iterator no longers begins iteration of its argument
on declaration, since this behavior may trigger database query
when that argument is, for instance, a Django queryset.
The ``factory.Iterator``'s argument will only be called when
the containing ``Factory`` is first evaluated; this means that
factories using ``factory.Iterator(models.MyThingy.objects.all())``
will no longer call the database at import time.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Builds upon pull request by @shinuza:
- Properly import ``get_model``
- Run ``django.setup()`` before importing any models.
|
| | |
|
| |
|
|
| |
Previously, the declarations (``factory.Sequence`` & co) weren't properly computed.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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()``.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
The latest pillow has changed the default gif palette, so we'll use a normalized RGB palette instead.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
See issue #61.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|