[ckan-discuss] Odd error message from API

[Christopher Gutteridge]

If you do this it will probably result in me adding an extra step to get 
the last revision ID from CKAN, and incrementing it before submitting.

Extra work for me.

Is this the revision of your record or my dataset? That's a very 
important detail. I may have multiple revisions of the CKAN record but 
no change to the dataset (e.g. typos, or adding a new access URL)

William Waites wrote:
> The post should contain the old revision id and the result would contain a new one. For detecting edit conflicts. The actual value being opaque to the client of course.
>
> Christopher Gutteridge <cjg at ecs.soton.ac.uk> a écrit :
>
>   
>> I don't understand your description of the fail condition.
>>
>> Surely a POST will have a *new* revision id?
>>
>> William Waites wrote:
>>     
>>> Related to this, what of handling of the revision id? I think
>>> (1) it needs to be required (not sure if it is at the moment)
>>> and (2) if a POST arrives with a missing revision id or one
>>> that doesn't match the current revision the POST should fail.
>>>
>>> Cheers,
>>> -w
>>>
>>>
>>> * [2011-04-01 10:51:36 +0200] David Read <david.read at okfn.org> écrit:
>>>
>>> ] Hi Chris,
>>> ] 
>>> ] This week, we've changed our API subtly in its handling of 'license'
>>> ] and 'license_id' fields. ckan.net is running our beta release at the
>>> ] moment, and it's useful to catch these issues before it is released
>>> ] elsewhere.
>>> ] 
>>> ] The reasoning behind it is: now you can simply GET a package, edit it
>>> ] and PUSH it. When you GET a package, the 'license' field is the plain
>>> ] text name of the license, and 'license_id' is for the short-code.
>>> ] Previously you could set either to be the ID and it worked, but to
>>> ] avoid confusion you now have to set the 'license_id' field (as per the
>>> ] API spec, I'm afraid...). It could be more clever and permissive, but
>>> ] I fear that might just serve to confuse even more people.
>>> ] 
>>> ] And it looks like the error message has a problem - it should point
>>> ] you to the 'license' field being the issue. Cheers for the heads up on
>>> ] this.
>>> ] 
>>> ] Anyway, do let us know if changing 'license' to 'license_id' solves it.
>>> ] 
>>> ] Dave
>>> ] 
>>> ] On 31 March 2011 19:13, Christopher Gutteridge <cjg at ecs.soton.ac.uk> wrote:
>>> ] >
>>> ] > It's saying "Package format incorrect: Key %r is readonly - do not include
>>> ] > in the package or leave it unchanged."
>>> ] >
>>> ] > On this data:
>>> ] > http://data.southampton.ac.uk/dataset/places.ckan.json
>>> ] >
>>> ] > I don't understand!
>>> ] >
>>> ] > --
>>> ] > Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248
>>> ] >
>>> ] > / Lead Developer, EPrints Project, http://eprints.org/
>>> ] > / Web Projects Manager, ECS, University of Southampton,
>>> ] > http://www.ecs.soton.ac.uk/
>>> ] > / Webmaster, Web Science Trust, http://www.webscience.org/
>>> ] >
>>> ] >
>>> ] > _______________________________________________
>>> ] > ckan-discuss mailing list
>>> ] > ckan-discuss at lists.okfn.org
>>> ] > http://lists.okfn.org/mailman/listinfo/ckan-discuss
>>> ] >
>>> ] 
>>> ] _______________________________________________
>>> ] ckan-discuss mailing list
>>> ] ckan-discuss at lists.okfn.org
>>> ] http://lists.okfn.org/mailman/listinfo/ckan-discuss
>>>
>>>   
>>>       
>> -- 
>> Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248
>>
>> You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/
>>
>>     

-- 
Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248

You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/