| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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()``.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
There was also a nasty bug: with class FactoryB(FactoryA), FactoryB's sequence
counter started at the value of FactoryA's counter when FactoryB was first called.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Fields listed in this class attributes will be removed from the
kwargs dict passed to the associated class for building/creation.
|
| |
|
|
|
|
| |
Magic abuse is bad.
|
|
|
|
| |
Use Iterator/iterator instead.
|
|
|
|
| |
Stop defaulting to Django's .objects.create().
|
|
|
|
|
|
|
|
|
| |
This will be properly fixed in v2.0.0; the current heuristic is:
- If the user defined a custom _create method, use it
- If he didn't, but the associated class has a objects attribute, use TheClass.objects.create(*args, **kwargs)
- Otherwise, simply call TheClass(*args, **kwargs).
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
|
|
| |
Use it in DjangoModelFactory to save objects again if a post_generation hook ran.
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
|
|
| |
This was just adding noise to an already complex release.
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
|
|
| |
Introduces a new, call-less syntax for the @post_generation decorator.
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Iterator now cycles by default
* Iterator can be provided with a custom getter
* SubFactory accepts a factory import path as well
Deprecates:
* InfiniteIterator
* CircularSubFactory
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
|
|
| |
If it works properly, this would make pylint happy.
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
|
|
| |
And add a deprecation warning too.
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
|
|
| |
With a very simple syntax.
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
|
|
| |
Rely on inheritance instead of handwritten set_creation_function and such.
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|
|
|
|
| |
Signed-off-by: Raphaël Barrois <raphael.barrois@polytechnique.org>
|