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

[johnbywater]

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.

[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?

[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.

[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)

[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?

[rgrp]

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

[dread]

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.

[dread]

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

[dread]

license bug fixed in cset:00038ef33c45