differs correctly between meta properties and attribute propertie…
#1049
Conversation
…s in component schemas.
| if field.field_name in list( | ||
| getattr(serializer.Meta, "meta_fields", list()) | ||
| ): | ||
| meta[format_field_name(field.field_name)] = schema |
There was a problem hiding this comment.
Thanks. Nice catch this can certainly be a problem.
meta dict is never used so I guess meta fields could simply be ignored? further up with a if meta_field then continue for instance. Otherwise would need to think about changing how we represent meta in the schema in general.
Also a test which test this use case will be needed for merging.
There was a problem hiding this comment.
i wouldn't remove it from the schema.
Example usecase:
"components": {
"schemas": {
"WebMapService": {
"type": "object",
"properties": {
"type": {
"type": "string",
"description": "The [type](https://jsonapi.org/format/#document-resource-object-identification) member is used to describe resource objects that share common attributes and relationships.",
"enum": [
"WebMapService"
]
},
"attributes": {
"type": "object",
"properties": {
}
},
"relationships": {
},
"meta": {
"type": "object",
"properties": {
"stringRepresentation": {
"type": "string",
"readOnly": true,
"title": "The string representation of the object it self"
"description": "This representation could be used to display a short title of the object"
}
}
}
}
}The stringRepresentation could be the string from the __str__ function of the model object. This would be usefull for several use cases, such as autocomplete widgets.
Sure, the stringRepresentation could be part of the regular attributes of the object, but i dont know if it is the best place for it.
There was a problem hiding this comment.
@n2ygk You have more in-depth knowledge about openapi. What is your take on the meta issue?
There was a problem hiding this comment.
if sparse fields are used, the meta object is still part of the response with possible null data. For that reason i would say it is better to place it in the attributes. Then it is possible to get only the stringRepresentation attribute in autocomplete cases.
There was a problem hiding this comment.
This is actually a bug see #332 and needs to be fixed.
There was a problem hiding this comment.
@sliverc sorry I missed this mention from 5 days ago. It looks like you figured it out?
There was a problem hiding this comment.
not really... what was the reason to represent meta on a resource level as stringRepresentation? Couldn't there be a more detailed representation as with attributes as all meta fields are actually serializer fields? Or did I overlook something here?
There was a problem hiding this comment.
Spending all of 30 seconds looking at this, it looks like confusing Django Models' Meta attribute with the optional meta jsonapi field: https://jsonapi.org/format/#document-meta
They are not related.
There was a problem hiding this comment.
It is a bit confusing that within DJA we sometimes mix up the API with DRF but this is a discussion for another time... 😄 but actually in this case meta_fields even though defined in Meta class is a DJA feature (see docs)
It works the way that serializer fields are used to build the JSON:API spec resource meta (not the top level which is build manually by overwriting get_root_meta). So as i see the resource meta class could be defined in more detail where as the root meta cannot.
There was a problem hiding this comment.
As a follow up as of my explanation above in my opinion can the meta fields be assigned to the result schema further below with something like this:
if relationships:
result["properties"]["meta"] = {
"type": "object",
"properties": meta,
}
|
@jokiefer Wanted to follow up whether you are still interested in working on this PR? |
…s in component schemas.
Fixes #
Description of the Change
Checklist
- [ ] unit-test added- [ ] documentation updatedCHANGELOG.mdupdated (only for user relevant changes)AUTHORS