Action API is inconsistent #473
Conversation
ghost
assigned 
|
@domoritz I think ux label is really for front-end syuff so the api would fall outside that even if it is part of the ckan experience |
|
@tobes Okay. |
…ogic.ValidationError
…t consistent with logic.validate
…paths and similar validation procedures
Otherwise errors occur when doing a deep copy of the context in validate
…, {group, dataset}_followee_list,
Conflicts: ckan/tests/logic/test_action.py
The problem was that `facet.field` is not always a list of strings but sometimes a string of a python list of strings. Furthermore, needless parameters are reported in search and not in the validation step so that they are reported as SearchQueryErrors and not ValidationErrors.
|
I think this is ready for review now. |
…d code style, fixed potential server error
… improved code style, fixed potential server error" This reverts commit 8cf11e4.
…otential server error
|
@johnglover I removed the ast code and use json instead. Are there any things left that prevent the merge (apart form getting master into this branch, of course)? |
|
Concerning the breaking changes: http://xkcd.com/1172/ |
|
@domoritz No I don't think so, I'll merge. |
|
@domoritz Merged, tests pass locally but have a few failures on Travis, any ideas? |
|
Not without further looking into the individual issues. |
|
Yes, it seems to be specific to this branch though, the last time I merged it was also passing in master but failing here. Perhaps something strange is going on with this branch and Travis... |
|
I restarted the build. Let's see what happens. |
|
The current test failures are triggered by calling get_or_bust to get the model object from the context dict. The model is going through the validation functions and causing an exception when we try to deepcopy it in augment_data. @domoritz is going to have a look at this. |
|
@johnglover when you ran the tests locally did you run them all? or just the ckan ones? try specifically
|
|
@tobes This is with just the ckan tests, but with the datastore loaded as a plugin. I think we have a fix for this, which is just to keep get_or_bust as a special case like it currently is (doesn't go through validate) but raises a proper ValidationError. |
|
@tobes Can you elaborate a little bit on "hopelessly broken"? |
|
To be honest I'm not sure where to start. Essentially you get the plugin and then go in and replace the methods and then test these new methods. It is so broken it makes me cry. I had looked at fixing it but the whole thing is too confused. The plugins are a mess which I'm trying to fix in #549 but some of the stuff done to get around these problems is dubious and I think that a lot of what is being tested may not be the same as you think is being tested and more specifically often I don't think you actually are testing the plugin but instead a highly modified version of the plugin that the user will never encounter in the wild. but things like importing a plugin in a test for example causes major issues and should never happen. in this example you permanently have the datastore plugin at least partially enabled for tests when it should not have been present. |
|
Well, this file has unit tests and we had to mock functions so that we only test a single function and not the whole thing. Obviously these tests do not run in a realistic environment since we don't ever talk to the db. If you think that this is not necessary, I'd be happy to delete the whole file. |
…because it caused problems with validate on dictionaries with objects such as context
|
Replacing |
|
I also think it's fine (and probably preferable) for get_or_bust to not go through the validate function but create a proper ValidationError. Using validate seems like adding unnecessary overhead to what should be a very simple function. |
|
Can not see obvious problem with using copy. The data is flattened and most values are strings so it should not make much difference. |
|
Wohooo 💃 |
This pr is not supposed to make everything correct but to make it better that it is at the moment and refactor some code to a point from which we can do more refactoring.
What has changed so far:
limitandoffsetis a negative integer or no integer at all. Also validation for other parameters. Kind of breaking because instead of a 500, you get a 409.ParameterErrorwas removed in favour ofValidationErrorbreaking_get_or_bustgoes through the validation code (common code paths)_get_or_bustreturns a list instead of a single string for a missing field (consistent with validate) breakingcurrent_package_list_with_resourcessupportsoffset,pageis deprecatedqis now required in all auto complete actions breaking, all actions support limit[package|resource]searchhave proper parameter validationThere are still many functions that have no proper validation. Often bad input is not tested and adding validation takes time because new validation definitions have to be written.
One thing to discuss is whether we want to have basic validation for all action functions in
controllers/apiinstead of in every single action. This would require a parameter schema for every action function.