| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
Based on a boolean flag, those will alter the definitions of the current
factory, taking precedence over pre-defined behavior but overridden by
callsite-level arguments.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This handles parameters that alter the declarations of a factory.
A few technical notes:
- A parameter's outcome may alter other parameters
- In order to fix that, we perform a (simple) cyclic definition
detection at class declaration time.
- Parameters may only be either naked values or ComplexParameter
subclasses
- Parameters are never passed to the underlying class
|
| | |
|
| |
|
|
|
| |
The ``_now()`` method wasn't declared on the base class, only in its
subclasses.
|
| |
|
|
| |
No need to wrap it in a lambda to strip the object argument from LazyAttribute or the sequence argument from Sequence.
|
| | |
|
| |\
| |
| | |
Make safe repr more safe
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Under Python 2.7+, the previous versions was directly casting fuzzy
Decimal values into a float, which led to warnings in code trying to
avoid such conversions in its tested code.
Since we're just building random values, that behavior led to false
positives or required jumping through weird hoops whenever a
FuzzyDecimal was used.
We now go trough a ``str()`` call to avoid such warnings.
|
| | |
| |
| |
| | |
fixes rbarrois/factory_boy#81
|
| | |
| |
| |
| |
| |
| | |
From dc7d02095fff, spotted by @federicobond too.
See #219.
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
This method has been deprecated in `mogo.model.Model` since 2012.
Thanks to @federicobond for spotting this!
|
| | |
| |
| |
| |
| |
| | |
Loading this function will, on pre-1.8 versions, load Django settings.
We'll lazy-load it to avoid crashes when Django hasn't been configured
yet (e.g in auto-discovery test setups).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
factory_boy wraps faker and it stores Faker generators in a 'private'
_FAKER_REGISTRY class attribute dict. There needs to be a way to extend
the Faker generators with additional custom providers (without having to
access _FAKER_REGISTRY directly).
This commit adds a (factory_boy) Faker.add_provider class method which calls Faker's
own `add_provider` method on internally stored (via _FAKER_REGISTRY)
Faker generators.
|
| | |
| |
| |
| |
| | |
As suggested by @adamchainz, use lazy computation of args/kwargs pprint
to only perform complex computation when running with debug.
|
| | |
| |
| |
| | |
Signal caching didn't exist until Django 1.6.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
You may now use the following code:
import factory
factory.alchemy.SQLAlchemyModelFactory
factory.django.DjangoModelFactory
factory.mongoengine.MongoEngineFactory
|
| | |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
This relies on the ``fake-factory`` library, and provides realistic
random values for most field types.
|
| | |
| |
| |
| |
| |
| | |
Define ``Meta.rename = {'attrs': 'attributes'}``
if your model expects a ``attributes`` kwarg but you can't
define it since it's already reserved by the ``Factory`` class.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| | |
``StubFactory.build()`` is now supported, and maps to
``StubFactory.stub()``.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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``.
|
| | |
| |
| |
| | |
Thanks to @shinuza for spotting this!
|
| | |
| |
| |
| | |
As pointed by @glinmac.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
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)``.
|
| | |
| |
| |
| |
| | |
This disables the ``FACTORY_FOR`` syntax and related parameters,
that should be declared through ``class Meta``.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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()``.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|