| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Closes #140, as this won't be implemented in the next few weeks.
|
| | |
|
| |
|
|
|
|
|
| |
This note was added to document a regression in Django 1.8.0; the
regression has been fixed in 1.8.4.
Closes #232
|
| |
|
|
|
|
| |
This method has been deprecated in `mogo.model.Model` since 2012.
Thanks to @federicobond for spotting this!
|
| |
|
|
| |
As spotted by @stephane, thanks!
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Properly install dependencies from examples folders.
|
| | |
|
| |
|
|
|
| |
This should contain examples of "using factory_boy with third-party
frameworks".
|
| |
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
requirement.txt was introduced in 6f37f9b, after requirements.txt
had already put in place. dev_requirements.txt installs the contents
of requirements.txt (which is empty) while a single dependency is
specified in requirement.txt. It looks like requirement.txt was added
accidently and it's content should always have been in requirements.txt.
This removes requirement.txt and puts the dependency delcared in there
in requirements.txt.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
As spotted by @proofit404
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
The wording of the readme suggested that "attributes" is a strategy just like "build" and "create", but this is not the case in the implementation (for example keyword arguments do not work, SubFactory fields don't behave as expected), so I have removed the mention of this and replaced the attributes example to mention the "stub" strategy.
|
| |
|
|
| |
Thanks to @nikolas for spotting it!
|
| |
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Avoid hitting bugs with max shebang line length in jenkins.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
You may now use: ``make DJANGO_VERSION=1.7 test``.
Valid options:
* ``DJANGO_VERSION``
* ``MONGOENGINE_VERSION``
* ``ALCHEMY_VERSION``
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| |
|
|
| |
Thanks to @nikolas for spotting it!
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Thanks to @DasAllFolks for spotting it!
|
| |
|
|
|
|
|
| |
Builds upon pull request by @shinuza:
- Properly import ``get_model``
- Run ``django.setup()`` before importing any models.
|
| | |
|
| |
|
|
| |
So that it doesn't fail on ci...
|
| |
|
|
|
|
|
| |
mongoengine>=0.9.0 and pymongo>=2.1 require extra parameters:
- The server connection timeout was set too high
- We have to define a ``read_preference``.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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)``.
|
| | |
|
| | |
|
| | |
|