-
Notifications
You must be signed in to change notification settings - Fork 441
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent behavior in API when listing packages in project #9715
Comments
this is a mismatch of backend and api answers. The backend maybe should not list flavors. However, where is the problem? |
OK, call me pedantic, but if the docs say the boolean parameter
|
I also think that using |
The =0 and =1 is anyway just a workaround of a limitation in rails cgi parameter handling, it should be only &deleted actually, from my side I consider deleted=0 as something which should actually not be used. One could of course add code at plenty places in the api to handle =0 special by removing the parameter entirely, but I am not really convinced that this is worth the effort though. |
The controller just checks for the existence of the parameter and passes it on. if params.key?(:deleted)
...
pass_to_backend
return
end So it will also pass on |
Again, call me pedantic. I'm aware that GET query strings can have an arbitrary format, but given that my only resources are the API docs and the sources of Except for OBS, I'm not aware of a single case where the convention of using So, as somebody who is used to virtually every system following the convention, I would consider it good practice if these queries produced identical output:
I'd like to remind you, these queries return a list of the same packages, only the amount of information is different. And that difference is bothering me. As @dmach pointed out, it is terribly confusing to use the On the other hand, Footnotes
|
On Freitag, 25. Februar 2022, 13:21:32 CET Henne Vogelsang wrote:
> The =0 and =1 is anyway just a workaround of a limitation in rails cgi parameter handling
[The controller](https://github.com/openSUSE/open-build-service/blob/master/src/api/app/controllers/source_project_controller.rb#L5-L12) just checks for the existence of the parameter and passes it on.
```ruby
if params.key?(:deleted)
...
pass_to_backend
return
end
```
So it will also pass on `?deleted=` or `?deleted`
might work meanwhile (or only here), but it used not to be and therefore we
had to introduce the =X workaround (not limited to deleted, but in general).
And now it is unfortunatly part of the documented api.
In this case might want to update the documentation that the parameter
alone is enough. The =X ways must still work of course.
However, this is independend of the inconsistency, we discussed it and will
most likely change the backend that the source server is not reporting the
flavors anymore by default. But adding a parameter to list them again.
…--
Adrian Schroeter ***@***.***>
Build Infrastructure Project Manager
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg) Geschäftsführer: Ivo Totev
|
If I'm not mistaken, many high-level frameworks and languages, do not follow strictly the standard definition, which allows flags (i.e. parameters without value), but rather the mantra "explicit is better than implicit". So, if your framework and many others are not favoring flags, maybe should abandon the idea of flags? |
As I showed in the code it has nothing to do with any framework and just with the way it's implemented :) |
the docu is stating already that deleted is a boolean. The =somehting is just there for backward compability, but should not be used anymore. |
I learned that a boolean is either Instead of a Boolean, there is So, while I would have considered this issue to be a bug, I certainly don't see that the documentation describes the behavior of the API accurately. |
The build service has a rather specific interpretation of boolean parameters: They are flags (i.e. without value) instead of params with explicit values. This change explicitly tries to not send values for boolean params in order to avoid confusing API responses. (see e.g. openSUSE/open-build-service#9715)
* Handle boolean query params (fixes #72) The build service has a rather specific interpretation of boolean parameters: They are flags (i.e. without value) instead of params with explicit values. This change explicitly tries to not send values for boolean params in order to avoid confusing API responses. (see e.g. openSUSE/open-build-service#9715) * Fixed linter issues
The `deleted` parameter interferes with other `view` parameter values, too. This is another fallout of openSUSE/open-build-service#9715
The `deleted` parameter interferes with other `view` parameter values, too. This is another fallout of openSUSE/open-build-service#9715
@adrianschroeter for some endpoints it does, but for others it does not, e.g. (screenshot taken just now on OBS): According to the docs, |
This way `?deleted=0` and `?` behaves consistently, and only `?deleted=1` activates the behaviour for deleted projects Fixes openSUSE#9715
This way `?deleted=0` and `?` behaves consistently, and only `?deleted=1` activates the behaviour for deleted projects Fixes openSUSE#9715
Issue Description
During development I like looking at the raw XML of API responses and I came this inconsistency in the API route
GET /source/<project>
:The API docs say that the
deleted
parameter can be used to "show deleted package instead of existing" ones. That lead me to the believe thatdeleted=0
would be the default and could be omitted.Now imagine my surprise that these queries return different results:
The first query only returns ordinary package names and a count:
, whereas the second one includes multibuild flavored packages, but no count:
Expected Result
I agree with the docs that
deleted=0
should be assumed as the default.However omitting the
deleted
parameter in the query should not affect the API response in this way.How to Reproduce
diff
the responsesThe text was updated successfully, but these errors were encountered: