Issue #1490
closed
Errata IDs not showing up correctly in the API
Description
When I run the equivalent of following in 2.6
RestClient.post "https://katello-pulp-nightly.example.com/pulp/api/v2/content/units/erratum/search/", "{\"criteria\":{}}", "Accept"=>"*/*; q=0.5, application/xml", "Accept-Encoding"=>"gzip, deflate", "Content-Length"=>"15", "accept"=>"application/json", "content_type"=>"application/json"
I get a list of errata back with each errata row having the following keys
["_href", "issued", "references", "_content_type_id", "id", "from", "severity", "title", "children", "version", "reboot_suggested", "type", "pkglist", "status", "updated", "description", "_last_updated", "pushcount", "_storage_path", "rights", "solution", "summary", "release", "_id"]
However in 2.8 the same call returns errata with each row having the keys of
["_href", "issued", "references", "pulp_user_metadata", "_content_type_id", "children", "from", "severity", "title", "version", "reboot_suggested", "type", "pkglist", "status", "updated", "errata_id", "description", "_last_updated", "pushcount", "downloaded", "_storage_path", "rights", "solution", "summary", "release", "_id"]
This breaks api compatibility for existing users and needs to be fixed.
Related issues
Updated by paji@redhat.com almost 9 years ago
One field that stands out amongst the differences here is errata_id in 2.8 vs id in 2.6
Updated by semyers almost 9 years ago
- Status changed from NEW to ASSIGNED
- Assignee set to semyers
Quick diff for lazy eyeballs...
Items in the 2.6 set not in the 2.8 set: {'id'}
Items in the 2.8 set not in the 2.6 set: {'downloaded', 'errata_id', 'pulp_user_metadata'}
Updated by mhrivnak almost 9 years ago
- Priority changed from Normal to High
- Severity changed from 2. Medium to 3. High
- Platform Release set to 2.8.0
- Triaged changed from No to Yes
Updated by semyers almost 9 years ago
- Related to Issue #1478: POST request to /pulp/api/v2/repositories/<reponame>/search/units/ does not transform id correctly when unit results returned added
Added by semyers almost 9 years ago
Added by semyers almost 9 years ago
Revision 6fdf3c7d | View on GitHub
content unit search views use content unit serializers
Recent changes in the pymongo > mongoengine conversion have resulted in different ways to represent mongo documents in the REST api views; the correct way is to use the mongoengine Document serializers wherever possible. When that isn't possible, remap_fields_with_serializer exists to use the information in a mongoengine serializer to modify serialized results properly.
Anything that is using the serialization functions in pulp.server.webservices.views.serializers.content should automaticaly benefit from this change, which implicitly fixes redmine #1490.
These changes can also be used to benefit views that don't call the existing serialization functions by explicitly using the new remap_fields_with_serializer function as-needed, such as RepoUnitSearch, which will help (but not fix) redmine #1478.
Updated by semyers almost 9 years ago
- Status changed from ASSIGNED to MODIFIED
- % Done changed from 0 to 100
Applied in changeset pulp:pulp|6fdf3c7d5148d1bc320f114189fedcc360036b28.
Updated by semyers almost 9 years ago
"old" pymongo objects weren't been serialized when coming out of some search api views dealing with content units. The solution (after normalizing the model serializer location to model.SERIALIZER) was to create a helper function to serialize those objects using the field remapping rules from the newer mongoengine serializers. Most search views will transparently benefit from this change, with the issue in #1478 being a noted exception.
Updated by dkliban@redhat.com almost 9 years ago
- Status changed from 5 to CLOSED - CURRENTRELEASE
.
content unit search views use content unit serializers
Recent changes in the pymongo > mongoengine conversion have resulted in different ways to represent mongo documents in the REST api views; the correct way is to use the mongoengine Document serializers wherever possible. When that isn't possible, remap_fields_with_serializer exists to use the information in a mongoengine serializer to modify serialized results properly.
Anything that is using the serialization functions in pulp.server.webservices.views.serializers.content should automaticaly benefit from this change, which implicitly fixes redmine #1490.
These changes can also be used to benefit views that don't call the existing serialization functions by explicitly using the new remap_fields_with_serializer function as-needed, such as RepoUnitSearch, which will help (but not fix) redmine #1478.
fixes #1490 https://pulp.plan.io/issues/1490
re #1478 https://pulp.plan.io/issues/1478