Yes, it did change under the hood, but we're supposed to be translating it back to "id" it at the API boundaries. We're tracking this similar bug: https://pulp.plan.io/issues/1478
Can you file this also as a bug? We'll make it a top priority. For a little context, the switch to using mongoengine for data access (the benefits of which are already paying off hugely) required us to rename any database field previously named "id". Michael On Thu, Jan 7, 2016 at 7:14 PM, Partha Aji <[email protected]> wrote: > > > 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"] > > One field that stands out amongst the differences here is errata_id in 2.8 > vs id in 2.6 > > 1) Are they meant be the same field > 2) Do we need to change our API implementation and runcible, to cater to > this change? > > > Partha >
_______________________________________________ Pulp-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-list
