[ckan-dev] allow_partial_updates - issues with demo site - where should we be going?

[Sean Hammond]

> With the demo site we are using package_update action
> 
> we are using allow_partial_updates when we are doing the updates - this is
> great for things like not loosing all our resources when we update a
> package however it also means that we cannot for example remove all our
> tags as an empty tags is seen as non-existent and so the tags are not
> updated
> 
> What I would prefer is that tags is in pkg_dict we would update it but if
> it wasn't we wouldn't

Yes I agree, for everything in dictionaries. It's a PITA to have to pass
the entire dict back to the CKAN API to avoid it deleting random bits
that you're not interested in. If I just want to change a package's
tags, for example, I should just be able to call package_update passing
only the package ID and the tags, and this should not cause the
package's resources (for example) to get deleted.

> the problem with this is that form data is validated and an empty tag is
> removed from that data - then when we are in the update missing tag data
> ends up becoming [ ]

You mean that if the dict that I pass to package_update has no 'tags'
key at all, then this deletes all the package's tags? I agree this
shouldn't change the package's tags at all, but it sounds like you're
going to have to modify the validate code to fix that, and that could be
hairy.

The other thing is, you would be changing the behaviour of the API (all
the *_update functions I think) so you might break clients.

> It seems to me that tags = [ ] should not be seen as empty by validation
> whereas no tags in the data should be

Don't you have this backwards? tags=[] in the data _should_ be seen as
me trying to remove all of the package's tags, no 'tags' key in the data
should mean don't make any change to the package's tags.

> then when processing the update we should not convert None -> [ ]

Yes

> The other option would be for me to add a more modular
> allow_partial_updates which would allow the items to be updated/or not to
> be more granularly controlled but this would become messy and the code
> would look shitty

Yes this sounds complicated