I'd like to be able to load a custom fields list to model_mommy so that Models with these fields can also be generated.

Maybe this is similar to a Recipe but it would be a one time config load of fields that comply to an interface potentially, and then mommy.make(MyModelWithACustomField) would be able to still generate the Model instance. Thus avoiding the error: <Field> is not supported by mommy

Specifying field values of related model instances within the baker.make() signature (e.g. baker.make(my_related_model__field=value) is not possible anymore with v1.2.1. This still works in v1.2.0.

Expected behavior

The model instance AND its required related model instances should be created, populated with random defaults except the values we explicitly passed in the call.

Actual behavior

ValueError: Cannot assign "<fk-id>": "<model>.<fk-field>" must be a "<fk-model>" instance.

Reproduction Steps

Try creating a model instance with baker.make() using related field assignments for an FK field that has a default value/callable returning an ID as seen in the following example. Any related models will do, these are just for illustration:

# models.py

def get_default_category():
    """ 
    Returning an ID here will make model_bakery fail, returning an instance is fine, but see:
    https://docs.djangoproject.com/en/3.1/ref/models/fields/#django.db.models.Field.default 
    """
    return 1


class SpotCategory(models.Model):
    name = models.CharField(max_length=128)


class TVSpot(models.Model):
    category = models.ForeignKey(SpotCategory, on_delete=models.CASCADE, default=get_default_category)


# tests.py

class TestBugWithModelBakeryVersion_1_2_1:

    def test_creating_related_models_separately_works(self, db):
        """This seems to always work, no matter the version of model_bakery."""

        category = baker.make("SpotCategory", name="Special")
        baker.make("TVSpot", category=category)

    def test_specifying_related_model_fields_within_constructor_fails_with_v1_2_1(
        self, db
    ):
        """This worked up until 1.2.0, but fails with 1.2.1 as follows:

        ValueError: Cannot assign "1990": "TVSpot.category" must be a "SpotCategory" instance.

        """
        baker.make("TVSpot", category__name="Special")

Run tests with different model_bakery versions like:

$ pip install model_bakery==1.2.0 && pytest -k TestBugWithModelBakeryVersion_1_2_1  # should pass
$ pip install model_bakery==1.2.1 && pytest -k TestBugWithModelBakeryVersion_1_2_1  # should fail

Versions

OS: Ubuntu 20.04 Database: MySQL 5.7.32 Python: 3.8 Django: 2.2.17 pytest: 6.1.2 Model Bakery: 1.2.1

Maybe you do have an idea which of the changes in 1.2.1 is related to this. Let me know what I can do to help fix this, thanks.

As detailed in https://github.com/model-bakers/model_bakery/issues/129, you cannot pass iterators for m2m kwargs when creating objects. Iterators may be useful when you've created a set of objects, and want to assign them one-by-one to the M2M fields of another list of objects.

This changes the behavior such that the iterator is iterated for each object being created, leaving the M2M's with one object each:

class Foo(Model):
    pass

class Bar(Model):
    foos = models.ManyToManyField(Foo)

# Foos in this case may either be 'made' or 'prepared'
foos = baker.make(Foo, _quantity=3)
bars = baker.make(Bar, _quantity=3, foos=iter(foos))

bars[0].foos.first() == foos[0]
bars[1].foos.first() == foos[1]
bars[2].foos.first() == foos[2]

The typehinting in the init method of Recipe is wrong. It states that _model is supposed to be str - but it can be an instance of django model as well.

Expected behavior

from typing import Union
from django.db import models
class Recipe(object):
    def __init__(self, _model: Union[str, models.Model], **attrs) -> None:

Actual behavior

class Recipe(object):
    def __init__(self, _model: str, **attrs) -> None:

Reproduction Steps

PyCharm will always show an error if I pass a model class to the Recipe. That is quite annoying and misleading.

Versions

Python: 3.8 Django: 3.1.2 Model Bakery: 1.2.0

Thanks!

We should add Black to enforce some code styles to improve legibility and maintenance.

• [x] Add Black as a development requirement
• [x] Add it to the pre-commit config

The existing QueryCount test utility class was implemented without the knowledge of an existing django built-in way of asserting that a certain number of database queries were performed.

The following code snippet is an example of an existing use of QueryCount:

def test_bulk_create_multiple_one_to_one(self):
    queries = QueryCount()

    with queries.start_count():
        baker.make(models.LonelyPerson, _quantity=5, _bulk_create=True)
        assert queries.count == 6

    assert models.LonelyPerson.objects.all().count() == 5
    assert models.Person.objects.all().count() == 5

The next code snippet is what it could look like using the provided assertNumQueries:

def test_bulk_create_multiple_one_to_one(self):
    with self.assertNumQueries(6):
        baker.make(models.LonelyPerson, _quantity=5, _bulk_create=True)

    assert models.LonelyPerson.objects.all().count() == 5
    assert models.Person.objects.all().count() == 5

Then the QueryCount class can be removed entirely.

'related' keyword doesn't seem to function properly: 2 model instances are persisted in the db, the first one bypassing the recipe (completely random), the other respecting the recipe.

Expected behavior

only 1 model instance should be persisted in the db.

Actual behavior

first created model instance does not apply anything from the recipe (random). second created model instance correctly applies the recipe.

Reproduction Steps

I have the following recipes:

default_equipment = Recipe(Equipment, constructor_code="abc", eurotax_group="def", is_visible=True)
default_tires = Recipe(Tires, rim_size=50, tire_wall=50, tire_width=50)
default_vehicle = Recipe(
    Vehicle,
    registration_date=date.today,
    is_registered=True,
    mileage=10000,
    equipment_set=related(default_equipment),
    tires=foreign_key(default_tires),
)

If I comment out the 'equipment_set =' line, everything works as expected -> only one model instance is persisted with the values defined in the recipe.

edit

more strange behaviour: if I create multiple instances from the recipe:

    vehicle = baker.make_recipe("django_apps.vehicle.default_vehicle", _quantity=2)

then, 3 instances are created. The first two vehicles are not created with the values from the recipe, but the 3rd one is correct. That is really strange behaviour.

If I omit the "related" in the recipe, and pass the equipments directly, no issue:

equipments = baker.prepare_recipe("django_apps.vehicle.default_equipment", _quantity=2)
vehicle = baker.make_recipe("django_apps.vehicle.default_vehicle", equipment_set=equipments)

Bottom line: I think bakery, using the "related" keyword, creates an empty vehicle when creating the equipments, then assigns the newly created vehicle to those equipments, leaving the old vehicles in the db (which were created randomly)

I think this behaviour is quite confusing if I am correct...

Versions

Python: 3.8.1 Django: 3.1.1 Model Bakery: 1.1.1 pytest-django = "==3.9.0" => I do not use django tests, but the pytest-django plugin @pytest.mark.django_db annotation

After update from 1.3.2 to 1.3.3 started getting exception from title.

Sorry I didn't debug properly this issue and can't say why this is happening but my best guess would be because of this change https://github.com/model-bakers/model_bakery/compare/1.3.2...1.3.3#diff-e5857deb915e241f429a0c118e89e06a3388d3ce1466e3aa4b960b7055172b6dL322

Expected behavior

Baker.get_fields() 1.3.2 version
(
    <django.db.models.fields.AutoField: id>,
    <django.db.models.fields.related.ForeignKey: group>,
    <django.db.models.fields.related.ManyToManyField: service_lines>,
)

Actual behavior

Baker.get_fields() 1.3.3 version
{
    <django.db.models.fields.AutoField: id>,
    <django.db.models.fields.related.ForeignKey: group>,
    <django.db.models.fields.related.ManyToManyField: service_lines>,
    <ManyToManyRel: myapp.foo1>,  # I guess it not suppose to be here
}

And as a result of new element from Baker.get_fields()

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
/python3.8/site-packages/model_bakery/baker.py:89: in make
    return [
/python3.8/site-packages/model_bakery/baker.py:90: in <listcomp>
    baker.make(
/model_bakery/baker.py:324: in make
    return self._make(**params)
/model_bakery/baker.py:371: in _make
    self.model_attrs[field.name] = self.generate_value(

>       if field.has_default() and field.name not in self.rel_fields:
E       AttributeError: 'ManyToManyRel' object has no attribute 'has_default'

/model_bakery/baker.py:566: AttributeError

Reproduction Steps

I don't think that model that I use has any custom behavior and it's just because of how Baker.get_fields() works in new 1.3.3 version

Models that I use anyway

class Foo(models.Model):
    slug = models.SlugField("Service line slug", unique=True, max_length=150)
    name = models.CharField("Service line name", max_length=150, null=True)

class Foo1(models.Model):
    bars = models.ManyToManyField("myapp.Bar")

class Bar(models.Model):
    foo = models.ManyToManyField("myapp.Foo", related_name="foos")

baker.make("core.Bar", _quantity=3, slug=cycle(["1", "2", "3"]), _fill_optional=True)

Versions

Python: 3.8.10 Django: 2.2.24 Model Bakery: 1.3.3

Hi,

itertools.count does not seem to be working in recipe or in a direct make statement

when I declare:

import itertools as it
baker.make('Play',  puzzle_id=it.count(start=1), _quantity=7)

or fake_play = Recipe(Play, puzzle_id=it.count(start=1))

I expected puzzle_id to take incremental values 1,2,3, ... 7

Instead, I receive an error message:

TypeError: int() argument must be a string, a bytes-like object or a number, not 'itertools.count'

I have tried different things but I don't really see what is happening as itertools.cycle is working well.

There seem to be nothing on the internet about it, not on the documentation. So I would assume it normally works

Could you help me out?

Versions

Python:Python 3.7.4 Django: 2.2.7 Model Bakery:1.0.2

Model Bakery has a module to deal with timezones that was implemented before Django had a built in support for it. We should replace it by the timezone API from Django 1.11.

https://github.com/model-bakers/model_bakery/blob/c2b609f6b065e587cf4a2e4253b518634d4995b3/model_bakery/timezone.py

Expected behavior

This lib should use Django's built in timezone library instead of bakery's timezone module.

Things I could think of:

• [ ] Replace calls to smart_datetime
• [ ] Replace calls to tz_aware
• [ ] Replace calls to now
• [ ] Replace calls to utc
• [ ] Delete bakery's timezone module

A TypeError is produced when creating multiple model instances using baker.make() with the _quantity param, and the model in question has a GenericForeignKey field where an iterator or generator is passed to baker.make as the value for the GenericForeignKey field.

Expected behavior

Values yielded by the iterator/generator should become the successive field values for each of the instances created by baker.make() for a GenericForeignKey field as with other fields.

Actual behavior

A TypeError is produced.

The reason is that this line (https://github.com/model-bakers/model_bakery/blob/main/model_bakery/baker.py#L362) only handles iterator parameters when they exist on fields in model._meta.fields or model._meta.many_to_many, however a GenericForeignKey field exists on model._meta.private_fields instead (since it's a virtual field). Consequently, next() is never called on the iterator/generator and as a result, the iterator/generator itself is ultimately passed as the field value when constructing the model, producing a TypeError since that's an incorrect value type for the field.

Reproduction Steps

# models.py

class MyModel(models.Model):
    content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
    object_id = models.PositiveIntegerField()
    myfield = GenericForeignKey()

# Any model for the purpose of relating generically to MyModel
class OtherModel(models.Model):
    ...

...

objs = baker.make('OtherModel', _quantity=2)
# This line produces TypeError: MyModel() got an unexpected keyword argument 'myfield'
baker.make('MyModel', myfield=iter(objs), _quantity=2)

Versions

Python: 3.9.1 Django: 3.1.7 Model Bakery: 1.2.1

If a test run fails intermittently due to random data satisfying certain conditions it is useful to be able to set/use the random seed for repeatability and debugging purposes. This is common with other testing packages (ex. faker) and would be a nice addition to baker.

In the meantime, perhaps it is sufficient to force the random seed used by python at tests start? Ref: https://github.com/model-bakers/model_bakery/blob/a408873f032dc2eeafc88291f3518396602b7742/model_bakery/random_gen.py#L17

Describe the change

given a django model with a foreign-key to a related model containing a FileField, I would like to just generate an instance and have model_bakery create the file on the child model if required.

PR Checklist

• [x] Change is covered with tests
• [x] CHANGELOG.md is updated

Describe the change Migrate setup.py to setup.cfg using setuptools-py2cfg plus manual modifications. Then migrate setup.cfg to pyproject.toml using ini2toml to do the file conversion and running pyproject-fmt and then validate-pyproject in pre-commit to validate the results.

• Currently, flake8 is not yet compatible with pyproject.toml so put its config into the file .flake8.

PR Checklist

• [ ] Change is covered with tests
• [x] CHANGELOG.md is updated

Describe the change

Currently we're using some random data to feed the fields. In this PR I'm proposing an approach where the user can enable an extra feature by adding _use_faker_generator=True when using baker.make. When enabled, we will use Faker to generate the data. For now we only have a small list but it can grow as needed:

• username
• email
• first_name
• last_name
• name
• fullname
• full_name
• ip
• ipv4
• ipv6

I think this is a really interesting feature because it will provide the users to have a more realistic data to work on.

PR Checklist

• [X] Change is covered with tests
• [X] CHANGELOG.md is updated

Describe the issue

Generating random data is not working below the condition. ArrayField with default=list FileField with default=None

To Reproduce

class A(models.Model):
    career = ArrayField(models.CharField(max_length=30), default=list)
    main_image = models.ImageField(blank=True, null=True, default=None)

a = baker.make(A, _fill_optional=True, _create_files=True)
print(a.career, a.main_image)

[], None

Expected behavior ArrayField and FileField should be filled with random data.

Versions

• Python: 3.10.3
• Django: 4.1.2
• Model Bakery: 1.8.0

Describe the issue As part of testing an abstract model, within the tests, we create a dummy model which is used for testing and then is later dropped. This dummy model represents a view.

In other models we have fields which are a foreign key on the content type model. The problem arises when we try to use baker.make to create an instance of that model. Most of the time it works fine, but sometimes, baker tries to set the content type field to the dummy view content type we had previously dropped.

To Reproduce models.py

from django.db import models
from django.contrib.contenttypes.models import ContentType


class MyModel(models.Model):
    related_object_type = models.ForeignKey(
        to=ContentType,
        on_delete=models.PROTECT,
    )

Within the tests somewhere:

class TestUserMatView:
   
    username = models.CharField(max_length=64)
    
    class Meta:
        db_table = "test_user_mat_view"
        managed = False

    @classmethod
    def create_view(cls) -> None:
        cls.drop_view()  # Ensures any previous creations will be torn down.
        with connection.cursor() as cursor:
            cursor.execute(
                """CREATE MATERIALIZED VIEW IF NOT EXISTS %s
                AS SELECT * FROM auth_user;
                """,
                [AsIs(cls._meta.db_table)],
            )
            cursor.execute(
                "CREATE UNIQUE INDEX ON %s (username);",
                [AsIs(cls._meta.db_table)],
            )

    @classmethod
    def drop_view(cls) -> None:
        with connection.cursor() as cursor:
            cursor.execute(
                "DROP MATERIALIZED VIEW IF EXISTS %s",
                [AsIs(cls._meta.db_table)],
            )

Create some tests that involve running TestUserMatView.create_view and then later TestUserMatView.drop_view (to clean). Then, create tests where we use baker.make(MyModel). This should work a couple of times, but at some point, there should be an error that moans about the table test_user_mat_view not existing.

Expected behavior It should create the instance without a hitch.

Versions

• Python: 3.9.5
• Django: 3.2.11
• Model Bakery: 1.0.0 (we can't use a newer version due to a memory leak issue that I've raised).