Project

Profile

Help

Story #3240

Add href_in_list as a filter for models

Added by daviddavis almost 2 years ago. Updated 8 months ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Start date:
Due date:
% Done:

0%

Platform Release:
Blocks Release:
Backwards Incompatible:
No
Groomed:
Yes
Sprint Candidate:
No
Tags:
QA Contact:
Complexity:
Smash Test:
Verified:
No
Verification Required:
No
Sprint:

Description

I broke this out into a separate issue while working on filters for other models since there was some uncertainty about a couple things. According to the MVP doc, these models will likely need this filters:

  • Repository
  • Importer
  • Publisher

The questions to answer before we can consider this groomed:

  • Which models should have this filter?
  • What should the name of the field be? href_in_list or id_in_list?
  • Currently, query strings only support thousands of characters. How will users filter on hundreds or thousands of ids/hrefs when they exceed query string size?

Checklist

History

#1 Updated by daviddavis almost 2 years ago

  • Description updated (diff)

#2 Updated by daviddavis almost 2 years ago

  • Description updated (diff)

#3 Updated by dalley almost 2 years ago

  • Tracker changed from Issue to Story
  • % Done set to 0

#4 Updated by daviddavis almost 2 years ago

  • Description updated (diff)

#5 Updated by milan almost 2 years ago

  • Groomed changed from No to Yes
  • Sprint Candidate changed from No to Yes

LGTM; let's just decide (on the sprint planning) about the field naming i.e _href_in_list vs href_in_list

#6 Updated by daviddavis over 1 year ago

  • Sprint Candidate deleted (Yes)

#7 Updated by amacdona@redhat.com over 1 year ago

  • Sprint Candidate set to No
  • Tags deleted (Pulp 3 MVP)

#8 Updated by dalley over 1 year ago

  • What should the name of the field be? href_in_list or id_in_list?

The name of the field should be "href and it should support the "exact" and "in" filters. This would allow you to filter on a list of hrefs with the query "/?href__in=<href1>,<href2>

My filter overhaul recently did something similar with all of the existing filters, e.g. "/?name__in=foo,foo2". It also works for hrefs, though, and I implemented "content__in" to search for repo versions containing multiple content hrefs.

#9 Updated by dalley over 1 year ago

So I thought about this a bit more and I think we should try to nail down some actual use cases for this functionality.

The main purpose of filtering is a human-friendly way of figuring out which objects meet certain human-facing criteria. In order to obtain your list of HREFs you're probably doing some other filter operation first, using dates or names or numbers or online=True or something. But in that case, you could just combine your filters together instead of trying to extract the HREFs and then do a separate filter operation on those HREFs.

e.g. instead of doing

/repository/<uuid>/versions/?number__gte=5
{
   blah blah blah
}

HREFS go into new filter

repository/<uuid>/versions/?content=<content_href>&href__in=<blah1_href>,<blah2_href>,<blah3_href>
{
    blah blah blah
}

Why not just encourage

/repository/<uuid>/versions/?number__gte=5&content=<content_href>

An HREF is a glorified primary key, it seems silly to have the user be chucking those around unless they have nothing else to use, such as with ContentUnits (since the user-friendly names are attached to Artifacts, of which there can be many). That's the only model I can actually think of where it makes sense.

#10 Updated by daviddavis over 1 year ago

I think the main use case is Katello. They store ids for objects and often times will want to look up lists of objects by their ids/hrefs. Since katello is a multi-tennant app, the names Katello is using for resources in Pulp are auto-generated so Katello uses ID to identify objects and often they are dealing with 100s or even 1000s of objects they want to get back. Filtering by ids/hrefs lets them submit a single request.

I'm not too concerned about getting this done anytime soon which is why it's post-MVP but we definitely will need this kind of filter I think. We can confirm with Katello about which specific objects they need to filter by ids/hrefs on.

#11 Updated by bmbouter 8 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF