Project

Profile

Help

Test #2603

closed

Search API does weird filtering on association

Added by mihai.ibanescu@gmail.com about 7 years ago. Updated over 3 years ago.

Status:
CLOSED - WONTFIX
Priority:
Normal
Assignee:
-
Category:
-
Sprint/Milestone:
-
Version:
Platform Release:
Tags:
Sprint:
Quarter:

Description

I am trying to use the search API against a repo.

I was trying to sort the results descending by the association's created field.

I am issuing a call like:

self._req('POST', 'repositories/%s/search/units/' % 
              repo_id, data={'criteria': {u'sort': {'association': 
              [[u'created', u'descending']]}, 'limit': 1000, 'filters': 
              {'unit': {}}, u'fields': {'unit': [u'name', 
              u'pulp_user_metadata', u'sadName', u'unitName', u'unitType', 
              u'version']}, 'type_ids': ['ddf']}}, expected=200, 
              safe_retry=True).json()

This returns 1 item, when it should return some 600.

If I changed the sort criterion to be by unit's created, it returns the expected number of units.

I have discussed this on #pulp-dev and mhrivnak agreed it's worth filing it.

Actions #1

Updated by mhrivnak about 7 years ago

The offending code is here:

https://github.com/pulp/pulp/blob/pulp-2.12.0-1/server/pulp/server/managers/repo/unit_association_query.py#L73

The comment explains the behavior I think, but I'm not sure if the reasoning is still valid. I'm not sure why a user would want to limit and skip on the association collection when querying for units in a repo.

Actions #2

Updated by bizhang about 7 years ago

  • Triaged changed from No to Yes
  • Tags Pulp 3 added

This issue will be fixed with the pulp3 release, we're keeping it open to ensure that we test this use case in pulp3

Actions #4

Updated by Ichimonji10 about 7 years ago

If I changed the sort criterion to be by unit's created, it returns the expected number of units.

Can I get a concrete example of a search query that behaves as expected? It'll aid in creating an automated test.

Actions #5

Updated by mihai.ibanescu@gmail.com about 7 years ago

I think you would have to:

  • create 10 units with a created_time TS1
  • create 10 units with a created_time TS2 (newer than TS1)
  • add one of the TS1 units to a repo, with a created_time (in the association) of TS1
  • add one of the TS2 units to the same repo, with a created_time (in the association) of TS2
  • issue a query like the above, with a limit of 10

The expectation would be for the call to return two units.

If my theory about constructing the reproducer is right, you would only get one unit back. If you queried with a limit of 20 you would get both of them back.

Please let me know if this helps reproduce it.

Actions #6

Updated by amacdona@redhat.com over 5 years ago

  • Tracker changed from Issue to Test
Actions #7

Updated by bmbouter almost 5 years ago

  • Tags deleted (Pulp 3)
Actions #8

Updated by bmbouter almost 4 years ago

  • Category deleted (14)

We are removing the 'API' category per open floor discussion June 16, 2020.

Actions #9

Updated by daviddavis over 3 years ago

  • Status changed from NEW to CLOSED - WONTFIX

Also available in: Atom PDF