CKAN: Ticket #662: Can't put entity that is returned by posting to package register

dread — Wed, 13 Oct 2010 17:31:19 GMT

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?

johnbywater — Wed, 13 Oct 2010 18:15:27 GMT

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.

priority changed

wwaites — Mon, 01 Nov 2010 15:07:15 GMT

priority changed from awaiting triage to blocker

wwaites — Mon, 01 Nov 2010 15:08:57 GMT

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)

dread — Mon, 01 Nov 2010 16:28:22 GMT

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:

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

Does that sound reasonable John and Will?

owner, milestone set

rgrp — Mon, 22 Nov 2010 21:07:23 GMT

owner set to rgrp
milestone set to ckan v1.3

type changed

dread — Wed, 12 Jan 2011 12:42:52 GMT

type changed from bug to defect

description, milestone changed

rgrp — Mon, 07 Feb 2011 09:11:52 GMT

description modified (diff)
milestone changed from ckan-v1.3 to ckan-v1.4

owner changed

rgrp — Thu, 10 Feb 2011 13:33:10 GMT

owner changed from rgrp to sebbacon

Now part of 'model/validation/forms' meta-ticket #961 so reassigning to Seb.

status changed; resolution set

dread — Thu, 10 Mar 2011 11:07:39 GMT

status changed from new to closed
resolution set to fixed

We want this fixed for CLG customer (DGU), so have put in a quick fix into branch 3.1.2 cset:0010a709edf0 (and merged to default) as a stopgap whilst new forms are on their way.

status changed; repo, theme set; resolution deleted

dread — Fri, 25 Mar 2011 18:07:23 GMT

repo set to ckan
status changed from closed to reopened
theme set to none
resolution fixed deleted

Bug: license_id field is assigned the value of the 'license' parameter.

status changed; resolution set

dread — Fri, 25 Mar 2011 18:07:43 GMT

status changed from reopened to closed
resolution set to fixed

license bug fixed in cset:00038ef33c45