New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add exclude to Config #660
Comments
as per #624 we could easily add |
I guess to implements this like exporting roles in Schematics You can simply describe all of public fields in model and inside controllers make dump in required set of fields by specifying only the role name. For example: class User(BaseModel):
id: int
login: str
email: str
password: str
first_name: str
last_name: Optional[str] = None
articles: Optional[List[Article]] = None
register_date: datetime.datetime
last_login: Optional[datetime.datetime] = None
class Config:
roles = {
"self": {"exclude": {"password", "register_date", "last_login"}},
"admin": {"exclude": {"password"}},
"public": {"include": {"id", "email", "first_name", "last_name"}}
} And then: user = User(
id=42,
login="mylogin",
email="email@example.com",
password="hashed secret password",
first_name="Some",
last_name="User",
articles=[Article(id=1, label="foo"), Article(id=2, label="bar"), ...],
register_date=datetime.datetime(...),
last_login=datetime.datetime.now()
)
user.dump(role="public") Should return something like this: {
"id": 42,
"email": "email@example.com",
"first_name": "Some",
"last_name": "User",
} include/exclude describing mechanism can be implemented more simply, for e.g. via function |
Wow thanks for the quick response @samuelcolvin. I have just been exploring pydantic and I really like it. Having quick responses on PR's and active development certainly makes me even more excited to adopt it. Looking forward to working with you. |
+1 for this, we code it into our classes as we have "local" variables that should not exported to other objects. Allowing this in the |
I like this idea and love @JrooTJunior's implementation with roles |
I understand that I think Combining this with #624, we'd have something like: class User(BaseModel):
id: int
username: str
password: str
class Transaction(BaseModel):
id: str
user: User
value: int
class Config:
fields = {
'value': {
'alias': 'Amount',
'exclude': ...,
},
'user': {
'exclude': {'username', 'password'}
},
'id': {
'dump_alias': 'external_id'
}
} |
Hello @samuelcolvin . First of all, I am really amazed by On the point of this issue, as I understand, this has not been implemented yet, correct? Is there currently any work going on for this? If not, I am willing to have a go on this. Having |
I solved this today with the following: class Resource(BaseModel):
class Config:
include: Set[str] = set()
exclude: Set[str] = set()
def json(self, **kwargs):
include = kwargs.pop('include', set())
include = include.union(getattr(self.Config, "include", set()))
if len(include) == 0:
include = None
exclude = kwargs.pop('exclude', set())
exclude = exclude.union(getattr(self.Config, "exclude", set()))
if len(exclude) == 0:
exclude = None
return super().json(include=include, exclude=exclude, **kwargs) Just specify the include/exclude fields as a part of the Class definition: class SR(Resource):
synopsis: str
session: str
class Config:
exclude = {'session'} |
@mtucker502 That is one way to solve when calling the class User(BaseModel):
id: int
username: str
password: str
class Transaction(BaseModel):
id: str
user: User
value: int
class Config:
fields = {
'user': {
'exclude': {'username', 'password'}
},
} And then calling the constructor would look like this.
Correct me if I'm wrong @samuelcolvin . |
@xspirus, this is an interesting concept. And it would actually solve/alleviate problem with copiyng the same model with little changes for different contexts. @enkoder, since this issue is originaly created from your #648 (comment), what do you think? |
No work on this AFAIK, happy to review a PR if it matches my suggestion above. |
I will try to create a PR, as soon as I find some time to work on this 😄 |
@MrMrRobat the approach that @mtucker502 took is how I would expect things to look! Defining excluded and included on the config like they did. |
I'd be using this as well (or a variant of it) so I can also try and take a swing at a PR. |
- Add "exclude" as a field parameter so that it can be configured using model config instead of purely at `.dict` / `.json` export time. - Closes pydantic#660
- Add "exclude" as a field parameter so that it can be configured using model config instead of purely at `.dict` / `.json` export time. - Closes pydantic#660
+1 for this feature! :) |
I started a branch to add this feature, I'll finalize it when I have the time to open a PR https://github.com/anth2o/pydantic/commits/add-config-to-exclude-fields |
Will the implemented behaviour in #2231 mean that recursive serialization respects the config of sub-classes for |
That is definitely the goal. We will see how it works in practice |
- Add "exclude" / "include" as a field parameter so that it can be configured using model config (or fields) instead of purely at `.dict` / `.json` export time. - Unify merging logic of advanced include/exclude fields - Add tests for merging logic and field/config exclude/include params - Closes pydantic#660
- Add "exclude" / "include" as a field parameter so that it can be configured using model config (or fields) instead of purely at `.dict` / `.json` export time. - Unify merging logic of advanced include/exclude fields - Add tests for merging logic and field/config exclude/include params - Closes pydantic#660
- Add "exclude" / "include" as a field parameter so that it can be configured using model config (or fields) instead of purely at `.dict` / `.json` export time. - Unify merging logic of advanced include/exclude fields - Add tests for merging logic and field/config exclude/include params - Closes pydantic#660
- Add "exclude" / "include" as a field parameter so that it can be configured using model config (or fields) instead of purely at `.dict` / `.json` export time. - Unify merging logic of advanced include/exclude fields - Add tests for merging logic and field/config exclude/include params - Closes pydantic#660
* Add exclude/include as field parameters - Add "exclude" / "include" as a field parameter so that it can be configured using model config (or fields) instead of purely at `.dict` / `.json` export time. - Unify merging logic of advanced include/exclude fields - Add tests for merging logic and field/config exclude/include params - Closes #660 * Precompute include/exclude fields for class * Increase test coverage * Remove (now) redundant type checks in Model._iter: New exclusion/inclusion algorithms guarantee that no sets are passed further down. * Add docs for advanced field level exclude/include settings * Minimal optimization for simple exclude/include export Running benchmarks this vs. master is at: this: pydantic best=33.225μs/iter avg=33.940μs/iter stdev=1.120μs/iter version=1.7.3 master: pydantic best=32.901μs/iter avg=33.276μs/iter stdev=0.242μs/iter version=1.7.3 * Apply review comments on exclude/enclude field arguments * Fix/simplify type annotations * Allow both ``True`` and ``Ellipsis`` to be used to indicate full field exclusion * Reenable hypothesis plugin (removed by mistake) * Update advanced include/include docs to use ``True`` instead of ``...`` * Move field info exclude/include updates into FieldInfo class This way, the model field object does not need to concern itself with dealing with field into specific fields. (Same was done for alias in a previous commit). * remove double back tick in markdown. Co-authored-by: Samuel Colvin <samcolvin@gmail.com>
Has this made it's way into production yet? |
@samuelcolvin -- PyPi does not seem to pull this change. I had to update my requirements to pull from the repo. |
It has been merged but not yet released. It will be part of 1.9 |
Thank you! |
Hi Folks, Thank you very much for supporting the config model "exclude" feature in 1.9.! This is going to help my team simplify things a bit. Is there a release cadence or timeline for the 1.9 release? |
Any updates on the 1.9 release timeline? |
…): Define fields to exclude from exporting at config level Eagerly waiting for the release of the version 1.9 because you can [define the fields to exclude in the `Config` of the model](pydantic/pydantic#660) using something like: ```python class User(BaseModel): id: int username: str password: str class Transaction(BaseModel): id: str user: User value: int class Config: fields = { 'value': { 'alias': 'Amount', 'exclude': ..., }, 'user': { 'exclude': {'username', 'password'} }, 'id': { 'dump_alias': 'external_id' } } ``` The release it's taking its time because [the developer's gremlin and salaried work are sucking his time off](pydantic/pydantic#3228). feat(type_hints#Define a TypeVar with restrictions): Define a TypeVar with restrictions ```python from typing import TypeVar AnyStr = TypeVar('AnyStr', str, bytes) ``` feat(type_hints#Use a constrained TypeVar in the definition of a class attributes): Use a constrained TypeVar in the definition of a class attributes. If you try to use a `TypeVar` in the definition of a class attribute: ```python class File: """Model a computer file.""" path: str content: Optional[AnyStr] = None # mypy error! ``` [mypy](mypy.md) will complain with `Type variable AnyStr is unbound [valid-type]`, to solve it, you need to make the class inherit from the `Generic[AnyStr]`. ```python class File(Generic[AnyStr]): """Model a computer file.""" path: str content: Optional[AnyStr] = None ``` feat(python_properties): Give an overview on Python's @Property decorator fix(vim): Correct vim snippet to remember the folds when saving a file
As inspired by @mtucker502 answer, I have solved this issue with a custom class. This class can even includes/excludes the nested model fields too with both model.dict() and model.json(). You can alternatively even pass the params directly in the dict() and json() functions as well. Please try it and let me your suggestions on this. Hope it helps to someone like me.
Usage:
|
From a user perspective I would rather add an exclude in the Config metaclass instead of passing the dict in to .json(). One of my model's fields is a Callable and I would like to call .json() on it, however I need to instead pass a custom encoder to the .json() which still puts the responsibility on the caller.
Originally posted by @enkoder in #648 (comment)
The text was updated successfully, but these errors were encountered: