Mazulo/adds faker generator feature #365
Conversation
There was a problem hiding this comment.
My main concern with these changes is that the new faker_generator_mapping circumvents the existing generator mapping mechanism, which already allows for overriding or providing new custom generators for fields of specific types.
At the very least, the new behavior should coexist with the existing mechanism (meaning it should still use the existing generator mapping in any case that it can). Otherwise, there would be no way to override the generation of, say, EmailFields where the name of the field is in the new list.
I like the idea, but I think it deserves some extra thought/planning to make sure it can be integrated nicely with the existing features.
| @@ -0,0 +1,18 @@ | |||
| from typing import Callable, Dict | |||
|
|
|||
| from faker import Faker | |||
There was a problem hiding this comment.
This import (and its subsequent behavior) should be resilient to ImportError, since we don't want to require users to install faker if they are not going to use it.
| @@ -660,6 +676,11 @@ def generate_value(self, field: Field, commit: bool = True) -> Any: | |||
| `attr_mapping` and `type_mapping` can be defined easily overwriting the | |||
| model. | |||
| """ | |||
| field_name = field.attname | |||
| if self._use_faker_generator and field_name in faker_generator_mapping: | |||
There was a problem hiding this comment.
See other comment about ImportError. I think that if we fail to import faker we should output a warning message (when _use_faker_generator is True) and continue past this logic so that it does not break, but still gives the user feedback that they are trying to use an optional feature for which they do not have all the requirements.
There was a problem hiding this comment.
I think it's cleaner to fail when someone tries to use the feature without installing faker.
But not using the feature should still be possible without faker being installed.
moving the from .faker_gen import faker_generator_mapping inside this if clause should do the trick...?
|
Hey @timjklein36 thank you for your review! I'm going to read and better understand about the changes you requested (mainly the one for the new feature). If you have any other idea please let me know! More than happy to go through them. 😄 |
Co-authored-by: Tim Klein <timjklein36@gmail.com>
mazulo
force-pushed
the
mazulo/adds-faker-generator-feature
branch
from
d6ad3f3
to
77221e9
Compare
| @@ -660,6 +676,11 @@ def generate_value(self, field: Field, commit: bool = True) -> Any: | |||
| `attr_mapping` and `type_mapping` can be defined easily overwriting the | |||
| model. | |||
| """ | |||
| field_name = field.attname | |||
| if self._use_faker_generator and field_name in faker_generator_mapping: | |||
There was a problem hiding this comment.
I think it's cleaner to fail when someone tries to use the feature without installing faker.
But not using the feature should still be possible without faker being installed.
moving the from .faker_gen import faker_generator_mapping inside this if clause should do the trick...?
| @@ -1 +1,2 @@ | |||
| django>=3.2 | |||
| Faker==15.1.3 | |||
There was a problem hiding this comment.
this could be moved to extras_require["faker"]
|
Any chance of merging this? in 2023 there are no working faker baked in fixture gens. |
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=Truewhen usingbaker.make. When enabled, we will useFakerto generate the data. For now we only have a small list but it can grow as needed:usernameemailfirst_namelast_namenamefullnamefull_nameipipv4ipv6I think this is a really interesting feature because it will provide the users to have a more realistic data to work on.
PR Checklist