Ticket #662 (new defect) — at Version 8

Opened 4 years ago

Last modified 3 years ago

Can't put entity that is returned by posting to package register

Reported by: johnbywater Owned by: rgrp
Priority: blocker Milestone: ckan-v1.4
Component: ckan Keywords:
Cc: Repository: ckan
Theme: none

Description (last modified by rgrp) (diff)

It's because Package carries several out-of-band values, which are snagged on the way back out. Entity get response also can't be posted.

However, post response can be re-posted (because it isn't the same as the register-post/entity-get responses.

An issue for CKAN too.

Sub-ticket of #961 (form, validation, model sync meta-ticket) and depends on that work.

Change History

comment:1 Changed 4 years ago by dread

I agree we should not have the 'read-only' things like Ratings in the default returned Package Entity. What do you think of having a parameter to be able to get these if you want them though?

Do you mean you *can* re-post the *entity* post response?

Not sure what you mean by "An issue for CKAN too."?

In addition to this ticket, what do you think about changing the behaviour of the Package Entity PUT/POST, so that you replace the entire Package, not just the fields you specify? So you don't keep left-over values, just because you didn't specify them as null?

comment:2 Changed 4 years ago by johnbywater

It might be natural for the locator of the rating for a package to be "/package/{id}/rating".

I've got not idea what I meant by "An issue for CKAN too." I may have intended to log this againt ckanclient. Anyway, it seems to be just a CKAN thing. :-)

I think I would like to do this:

$data = c.package_register_post({'name': 'example'}) $datatitle? = 'Example' c.package_entity_put($dataid?, $data)

and this:

$data = c.package_entity_get('example') $datatitle? = 'Example' c.package_entity_put($dataid?, $data)

I don't think either work. We could write a test for each.

I think this does work:

$data = c.package_entity_get('example') $data = c.package_entity_put($dataid?, $data) $datatitle? = 'Old Example' c.package_entity_put($dataid?, $data)

Which is inconsistent. The reason is that the data returned by the update operation ("entity put") isn't given the same treatment as the read and create operations, which adds various read-only values.

That's as far as I got. I inferred that one or several of the read-only values, when present in the update request data, cause the update to fail. I'm not sure how it fails. Rather than cutting down the response data, we could make the update call more robust. One fix would pick out from the request package data only the attributes that are permitted. A alternative fix would make what ever is choking on the extra values ignore them. I mean, ids are read-only, but we wouldn't want to reject an update because it has an id in the data. We do need to be careful about loading up the package entity data, but the 'id' is read-only and we aren't going to quible about that being present in the data of an update request (even if it doesn't match the referenced entity).

I would rather not support "replace the entire package" with especial functionality and documentation. I think the model create/update/delete, where update is "set attributes" is sufficient, simple, and fairly optimal. To obliterate all registerd values without deleting, I would get the package entity data, loop over the keys and set the values to , [] or {} depending on the type, and then PUT the entity. We could write a test for that.

comment:3 Changed 4 years ago by wwaites

  • Priority changed from awaiting triage to blocker

comment:4 Changed 4 years ago by wwaites

Ran into this with RDF export (that then updates the CKAN package with LOD2-compatible extras from the results). Cannot use ckanclient.package_entity_put(ckanclient.package_entity_get("ckan")).

Is this related to the modifications htat are showing up in the changelog with no apparent package (the package that should be appearing there is "ckan" itself)

comment:5 Changed 4 years ago by dread

Yes we all agree this needs fixing it.

I'm tempted by John's 'permissive' suggestion of ignoring these 'read-only' values, but to avoid confusion we should except with a 400 error if the user has changed these values.

Read only fields: 'id', 'relationships', 'ratings_average', 'ratings_count', 'ckan_url'

Use cases for changes between GET package, PUT package:

  1. package unchanged - 200 OK
  2. user changes id, ckan_url, relationships, ratings_* expecting that value to change - 400 error.
  3. just license changes (but not license_id) - 400 error
  4. both license and license_id change in step - 200 OK

Does that sound reasonable John and Will?

comment:6 Changed 3 years ago by rgrp

  • Owner set to rgrp
  • Milestone set to ckan v1.3

comment:7 Changed 3 years ago by dread

  • Type changed from bug to defect

comment:8 Changed 3 years ago by rgrp

  • Description modified (diff)
  • Milestone changed from ckan-v1.3 to ckan-v1.4
Note: See TracTickets for help on using tickets.