Field generators definition restrictions.

[hwms]

.. code-block:: python

# on your settings.py file:
def gen_func():
    return 'value'

MOMMY_CUSTOM_FIELDS_GEN = {
    'test.generic.fields.CustomField': gen_func,
}

could be

.. code-block:: python

# somewhere in your code:
def gen_func():
    return 'value'

# in your settings.py
MOMMY_CUSTOM_FIELDS_GEN = {
    'test.generic.fields.CustomField': 'somwhere.in_your_code.gen_func',
}

because it is usefull to provide value generators which need to import settings. Personally i have a generator which generates ascending characters in each test-case instead of random ones just for readability and the same algorithm is used in production code.

Another problem is the not so funny replacement of make with prepare in class Mommy prepare(), it handles only ForeignKey and OnetoOneField from django, no derived Field-Models.

.. code-block:: python class MyForeignKey(models.ForeignKey): pass class MyModel(models.Model): foo = MyForeignKey(...)

MOMMY_CUSTOM_FIELDS_GEN = {'MyForeignKey': make}

mommy.prepare(MyModel) -> raises Exception/wants to write to the DB, because make never gets commit=False / gets replaced with prepare.

Ideas to circumvent the lack of commit=False passing for ForeignKeys: A) Accept tuples (make_gen, prepare_gen) in MOMMY_CUSTOM_FIELDS_GEN B) Check for issubclass, not mapping[CLASS] =

[vandersonmota]

merged.