[Pulp-dev] Not equal filters

Dana Walker dawalker at redhat.com
Wed Jan 29 17:04:26 UTC 2020


Given dalley's point regarding the bindings, option 3 sounds best.

Dana Walker

She / Her / Hers

Software Engineer, Pulp Project

Red Hat <https://www.redhat.com>

dawalker at redhat.com
<https://www.redhat.com>



On Wed, Jan 29, 2020 at 11:45 AM Daniel Alley <dalley at redhat.com> wrote:

> Going by the comments in this PR [0], if something like this would be used
> with the API bindings, wouldn't the name__ne=value scheme be better?  It
> also just generally seems a bit more consistent.
>
> [0] https://github.com/pulp/pulpcore/pull/316/files
>
> On Wed, Jan 29, 2020 at 10:51 AM David Davis <daviddavis at redhat.com>
> wrote:
>
>> If we went with django-rest-framework-filters, I'm not sure we could go
>> with other options later. Our REST API is semantically versioned so we
>> couldn't switch from name!=value to name__ne=value. Perhaps we could label
>> not equal filters as a tech preview to get around this?
>>
>> Also, I'm curious about how we'd upgrade to django 3.0. It looks like
>> they haven't been merging PRs so I imagine we'd have to fork the project,
>> add django 3.0 support ourselves, and then vendor it. Is my understanding
>> correct?
>>
>> David
>>
>>
>> On Wed, Jan 29, 2020 at 10:13 AM Brian Bouterse <bmbouter at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Jan 29, 2020 at 10:03 AM David Davis <daviddavis at redhat.com>
>>> wrote:
>>>
>>>> A few weeks ago, Katello opened an issue[0] requesting a set of "not
>>>> equal" filters (ie filters where a field is not equal to a certain value).
>>>> I created a pulpcore issue[0] to investigate whether pulpcore could provide
>>>> this functionality and it seems there are a few different options. I wanted
>>>> to ask for feedback though as this would affect the user experience and
>>>> thus whatever option we choose would be permanent.
>>>>
>>>> There are three options:
>>>>
>>>> 1. First there is a package which adds functionality on top of
>>>> django-rest-framework-filters[1] which dynamically provides filters for
>>>> every field using ! (eg name!=value, state!=value). The problem is that the
>>>> package doesn't look like it's well maintained[2] and we'd quickly run into
>>>> problems when we try to upgrade to django 3 for example[3]. We'd probably
>>>> have to fork the project or take over ownership somehow.
>>>>
>>> I default to this choice because even though it's not code that is in
>>> our control and that can feel uncomfortable, they wrote it and it does what
>>> we need. If it doesn't work out we can go with other options later.
>>>
>>>
>>>> 2. The second solution is that we can try to import the code from
>>>> django-rest-framework-filters that creates these dynamic filters. This
>>>> would free us from having to support any other features
>>>> from django-rest-framework-filters we don't want to support.
>>>>
>>>> 3. The third option is to create a django scope (ie "ne") that would
>>>> allow plugin writers to manually define filters like "name__eq=value". This
>>>> solution seems the most verbose/explicit/straightforward but also the most
>>>> work for plugin writers. I have a couple PRs open to demonstrate this
>>>> solution:
>>>>
>>>> https://github.com/pulp/pulp_rpm/pull/1559
>>>> https://github.com/pulp/pulpcore/pull/452
>>>>
>>>> I'll try to move forward with a solution next week. Feedback before
>>>> then would be much appreciated.
>>>>
>>>> [0] https://pulp.plan.io/issues/5854
>>>> [1] https://github.com/philipn/django-rest-framework-filters
>>>> [2] https://github.com/philipn/django-rest-framework-filters/issues/324
>>>>  and
>>>> https://github.com/philipn/django-rest-framework-filters/issues/287
>>>> [3] https://github.com/philipn/django-rest-framework-filters/issues/326
>>>>
>>>> David
>>>> _______________________________________________
>>>> Pulp-dev mailing list
>>>> Pulp-dev at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>>>
>>> _______________________________________________
>> Pulp-dev mailing list
>> Pulp-dev at redhat.com
>> https://www.redhat.com/mailman/listinfo/pulp-dev
>>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20200129/da10d029/attachment.htm>


More information about the Pulp-dev mailing list