[RFC 09/11] REST: Add query parameters to filter patches by
Andy Doan
andy.doan at linaro.org
Wed May 11 08:30:17 AEST 2016
On 05/09/2016 09:06 AM, Finucane, Stephen wrote:
> On 15 Apr 13:24, Andy Doan wrote:
>> + def test_query_filters(self):
>> + """Test out our filtering support."""
>> + patches = create_patches(4)
>> + project = Project.objects.create(
>> + linkname='foo', name='Foo', listid='foo.example.com')
>> + patches[0].project = project
>> + patches[0].save()
>> + resp = self.client.get('/api/1.0/patches/?project=Foo')
>
> I have a feeling we've discussed this before (and it doesn't really
> belong in this patch), but why are we not nesting patches under
> projects? Seems like a clear hierarchy to me.
You thought that by nesting patches under a project that you should be
able to get sequential ids like:
projects/foo/1
projects/foo/2
but "2" might be a patch in project bar. And creating a per-project
unique patch ID isn't a fool-proof as you'd think it should be.
>> diff --git a/patchwork/views/rest_api.py b/patchwork/views/rest_api.py
>> + query_filters = {
>> + 'project': 'project__name',
>> + 'submitter': 'submitter__name',
>> + 'delegate': 'delegate__name',
>> + 'state': 'state__name',
>> + 'since': 'date__gt',
>> + 'until': 'date__lt',
>> + }
>> +
>
> This seems to be a reinvention of parts of 'filters.py'. Could that
> code be integrated here in any way?
Its probably possible. Would probably require some re-work of filters.py
to support things like since and until and the default listing needs to
be all patches.
I see a couple of ways forward:
* leave this patch out for now and revisit
* leave the patch as is
* take the time now to integrate nicely with filters.py
let me know what you'd like to see.
More information about the Patchwork
mailing list