[PATCH v3 05/16] REST: Explicitly define fields
Andy Doan
andy.doan at linaro.org
Tue Nov 29 08:59:34 AEDT 2016
On 11/25/2016 12:18 PM, Stephen Finucane wrote:
> Explicitly define included fields (using 'Meta.fields') rather than
> those that should be excluded (using 'Meta.exclude'). This ensure fields
> that are exposed by the API don't change unless we explicitly change
> them
>
> The only side-effect of this change should be a consistent ordering of
> the output - the ordering used in the 'Meta.fields' will be consistently
> used, thus ordering is now important and some fields are moved around
> to reflect this.
>
> Signed-off-by: Stephen Finucane <stephen at that.guru>
Feel free to add my:
Reviewed-by: Andy Doan <andy.doan at linaro.org>
After answering my question below:
> diff --git a/patchwork/api/patch.py b/patchwork/api/patch.py
> index 3f464b2..3af5994 100644
> --- a/patchwork/api/patch.py
> +++ b/patchwork/api/patch.py
> @@ -72,11 +72,12 @@ class PatchSerializer(HyperlinkedModelSerializer):
> class Meta:
> model = Patch
> list_serializer_class = PatchListSerializer
> + fields = ('url', 'project', 'msgid', 'date', 'name', 'commit_ref',
> + 'pull_url', 'state', 'archived', 'hash', 'submitter',
> + 'delegate', 'mbox', 'check', 'checks', 'tags', 'headers',
> + 'content', 'diff')
> read_only_fields = ('project', 'name', 'date', 'submitter', 'diff',
> 'content', 'hash', 'msgid')
> - # there's no need to expose an entire "tags" endpoint, so we custom
> - # render this field
> - exclude = ('tags',)
You are adding "tags" as a field here. You have a "TODO" in the previous
patch for "get_tags". Is performance acceptable when including, or is
there a potential side-effect?
More information about the Patchwork
mailing list