We have a multi-tenant app where all models are ultimately owned by a customer model, but some of the models are only indirectly owned by that customer model, some pseudocode:

class Job(Model):  has foreignkey to Customer
class Call(Model): has foreignkey to Job
  contains PositionTitle(Model): has foreignkey to Customer
class Position(Model): has foreignkey to Call
class Assignment(Model): has foreignkey to Position

That isn't all the models in my code, but when I do

mommy.make(Assignment) 

mommy creates 32 Customer objects because of the generation. It would be nice if you could say something like

with mommy.register({"customers.customer": mommy.make(Customer)}):
    assignment = mommy.make(Assignment)

Admittedly the syntax needs some work, and you would probably need to do with nesting of the with clauses. Recipes might work for this case, but it seems like a HUGE amount of overhead for something simple like this.

Started some code on a feature branch. Needs more work and discussion. Doing a pull_request for further discussion following #90.

Not sure about the decorators. They don't really make sense, as we aren't really wrapping the fields.

def gen_func():
    return "random_value"

class CustomField(models.Fields):
    ... #some field code

add_value_generator(gen_func, CustomField)

Is the same LOC. But make more sense semantically, than

def gen_func():
    return "random_value"

@custom_field_gen("gen_func")
class CustomField(models.Fields):
    ... #some field code

I do still see a usecase for the context_manager as it is better at handling exception cases than a single_use parameter would.

And what about a model_field param? When I did the model param, I thought, about a model using the same CustomField multiple times for different model_fields. But when implementing that, I felt like I was redoing stuff, that can already be done pretty well with recipes.

Hello @vandersonmota.

This is a great project, but in my day to day work uses a lot of geospatial information, so I need model_mommy to generate spatial data as well.

This a first draft that includes a point generator, using the already consolidated formulaes used by model_mommy.

In here I've updated the association between a field type and generators and created the spatial generator.

perhaps there are other ways to handle this, but let me know.

I'll explain the idea given by @henriquebastos during our last lunch. Suppose that we have the following model:

class Person(models.Model):
    name = models.CharField(max_length=60)
    age = models.PositiveIntegerField()

Now, imagine some test situation that we need to create 4 objects with the same age but different, but not random, names. Today, the way we can achieve this with model mommy is as following:

person1 = mommy.make(Person, age=20, name='bob')
person2 = mommy.make(Person, age=20, name='alice')
person3 = mommy.make(Person, age=20, name='john')
person4 = mommy.make(Person, age=20, name='peter')

There is a lot of code repetition on the previous snippet and maybe we can improve this. This issue is to start this discussion to explore possibilities of how we can implement something better. The first suggestion was using something like this:

names = ['bob', 'alice', 'john', 'peter']
persons = mommy.make(Person, age=20, name=names)

So, we can instantiate an iterable object with the multiple values that we expect and pass it to the model attribute that we want to change. Although this is an easy approach, it could make the API more complex and confusing. I mean, on the previous code we have a model attribute receiving a list as a parameter, which is something king of odd if we think about model creation...

Well, let the discussion begins =)

I have the following models

app1.models.py

class UserProfile(Subject): """ UserProfile class """ # This field is required. user = models.OneToOneField(User) # Other fields here company = models.CharField(max_length=50, null=True, blank=True, verbose_name=("Company")) contact = models.CharField(max_length=50, null=True, blank=True, verbose_name=("Contact")) msg = models.TextField(null=True, blank=True, verbose_name=_("Message"))

def __unicode__(self):
    return self.user.username

class ParentImportJob(models.Model): """ Class to store importing jobs """

STATUS_ACTIVE = u'A'
STATUS_SUCCESS = u'S'
STATUS_PARTIAL = u'P'
STATUS_ERROR = u'E'

STATUS_CHOICES = (
    (STATUS_ACTIVE, _(u'In Progress')),
    (STATUS_SUCCESS, _(u'Successfully Imported')),
    (STATUS_PARTIAL, _(u'Partially Imported')),
    (STATUS_ERROR, _(u'Aborted with error')),
)

status = models.CharField(max_length=1, choices=STATUS_CHOICES)
user_profile = models.ForeignKey(UserProfile)
errors = models.TextField(null=True, blank=True)
start_date = models.DateTimeField(auto_now_add=True)
end_date = models.DateTimeField(blank=True, null=True)
instance_class = models.CharField(max_length=200)

app2.models.py

class ImportJob(ParentImportJob): """ Class to store jobs of files being imported Extends ParentImportJob ParentImportJob is not abstract! But I am interested in 2 separated tables """

_imported_file = models.TextField(null=True,
                                  blank=True,
                                  db_column='imported_file')
import_result = models.TextField(null=True, blank=True)

def set_import_file(self, imported_file):
    """ Set method for import_file field """
    self._imported_file = base64.encodestring(imported_file)

def get_import_file(self, imported_file):
    """ Set method for import_file field """
    return base64.decodestring(self._imported_file)

imported_file = property(get_import_file, set_import_file)

The following recipe:

ob_mock = Recipe(ImportJob, import_file=ofile.read(), import_result=EXCEL_DICT)

When I ran self.job = mommy.make_recipe('excel2db.job_mock') inside the testcase I get IntegrityError: column user_id is not unique

I'm doing something wrong?

Is there a way to provide a recipe that replaces mommy's default recipe for a model? In other words, when I run mommy.make('myapp.MyModel'), I want it to use a custom recipe, without having to worry about mommy.make_recipe.

I really only need to write a recipe to populate one field--not all of them. Is it possible to have the remaining fields auto-populate? If not, I'd be happy to add this functionality.

These changes add a little more magic to Recipe and allow us to eliminate the need for Sequence, and allow Recipe to accept iterators (and generators) as field values.

Advantages:

• no need for users to work with Sequence, they can use Python generators or iterators which are more familiar and more powerful.
• the "seq" function still works the same as it always has, and is a simple 2 line generator.
• all the original unit tests pass, and all new code is covered by new tests

Disadvantages:

• The Recipe _mapping function is more complicated.

This is my first pull request ever. If there are any problem please be patient. I'm open to any feedback you may have.

(Pdb) mommy.make(Post)
*** DoesNotExist: Post matching query does not exist. Lookup parameters were {'pk': 1}
(Pdb) Post.objects.all()
[]
(Pdb) Article.objects.all()
[<Article: /article/3apmB5cyN0yDsyzZwmBhqhf0mDlsIA-BlNrdcJVul0zpiLIM-Y/HY1y3VDgxuERG5-a0Sys8RbzJaQpOl2hlKA9eZuGbF_S09o6mW>]
(Pdb)

Model Post extend model Article (not abstract).

mommy.make: Article created and not created Post

I have been using version 1.2 for a while without a problem, but since I installed 1.2.1 I started to get a lot of ValueError as the one you see above. Basically, it looks like that when mommy creates a ManyToManyField for a model it's not able to relate it to the instance being created.

An example will help me explain it: this worked with version 1.2 (simplified):

    tag1 = mommy.make_recipe('myapp.TagRecipe')
    tag2 = mommy.make_recipe('myapp.TagRecipe')
    tag3 = mommy.make_recipe('myapp.TagRecipe')
    params = {
        'tags': [tag1, tag2, tag3],
    }
    article = mommy.make_recipe("myapp.ArticleRecipe", **params)

The recipes simply being:

TagRecipe = Recipe(Tag, name = seq('tag'))
ArticleRecipe = Recipe(Article, name = seq('article'))

And the models:

class Tag(models.Model):
     name = models.CharField(max_length=255, unique=True)
     [...]

class Article(models.Model):
    name = models.CharField(max_length=255, unique=True)
    tags = models.ManyToManyField(Tag, related_name="articles", blank=True, null=True)
    [...]

Since version 1.2.1 I'm getting:

ValueError: Cannot assign None: "Article_tags.article" does not allow null values.

If you need more information I'll be happy to provide it.

This is related to #89, but it looks like recent versions of taggit's TaggableManager now subclasses Field and provides has_default() == False.

../../.virtualenvs/dashboard/lib/python2.7/site-packages/model_mommy/mommy.py:75: in make
>           return mommy.make(**attrs)
../../.virtualenvs/dashboard/lib/python2.7/site-packages/model_mommy/mommy.py:241: in make
>       return self._make(commit=True, **attrs)
../../.virtualenvs/dashboard/lib/python2.7/site-packages/model_mommy/mommy.py:277: in _make
>                   model_attrs[field.name] = self.generate_value(field)
../../.virtualenvs/dashboard/lib/python2.7/site-packages/model_mommy/mommy.py:351: in generate_value
>       return generator(**generator_attrs)
../../.virtualenvs/dashboard/lib/python2.7/site-packages/model_mommy/mommy.py:75: in make
>           return mommy.make(**attrs)
../../.virtualenvs/dashboard/lib/python2.7/site-packages/model_mommy/mommy.py:241: in make
>       return self._make(commit=True, **attrs)
../../.virtualenvs/dashboard/lib/python2.7/site-packages/model_mommy/mommy.py:277: in _make
>                   model_attrs[field.name] = self.generate_value(field)
../../.virtualenvs/dashboard/lib/python2.7/site-packages/model_mommy/mommy.py:342: in generate_value
>           raise TypeError('%s is not supported by mommy.' % field.__class__)
E           TypeError: <class 'taggit.managers.TaggableManager'> is not supported by mommy.

I can't provide a generator function for a custom field either, because the tags cannot be set from the model constructor.

I don't see an easy way to identify this kind of fake field. :/