Project

Profile

Help

Test #2603

Search API does weird filtering on association

Added by mihai.ibanescu@gmail.com over 2 years ago. Updated 6 months ago.

Status:
NEW
Priority:
Normal
Assignee:
-
Category:
API
Sprint/Milestone:
-
Version:
Platform Release:
Tags:
Sprint:

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.

History

#1 Updated by mhrivnak over 2 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.

#2 Updated by bizhang over 2 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

#3 Updated by pthomas@redhat.com over 2 years ago

  • Smash Test set to 567

#4 Updated by Ichimonji10 over 2 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.

#5 Updated by mihai.ibanescu@gmail.com over 2 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.

#6 Updated by amacdona@redhat.com 11 months ago

  • Tracker changed from Issue to Test

#7 Updated by bmbouter 6 months ago

  • Tags deleted (Pulp 3)

Please register to edit this issue

Also available in: Atom PDF