[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