Skip to content
This repository has been archived by the owner on Sep 21, 2022. It is now read-only.

Allow filtering based on modfile.filename. #36

Open
leper opened this issue Nov 21, 2017 · 2 comments
Open

Allow filtering based on modfile.filename. #36

leper opened this issue Nov 21, 2017 · 2 comments

Comments

@leper
Copy link

leper commented Nov 21, 2017

Since we will only support showing/downloading mods with a certain extension (due to being portable, somewhat similar to .umod for those that spent too much time with UT; actually just zip files that contain a mod.json file with some data we use, and the files for the mod), it would be nice to do that filtering when submitting the query.

It should be working (unless I'm missing something in the documentation), but the below example does not seem to do what it should.

curl --request GET 'https://api.mod.io/v1/games/57/mods?api_key=use_your_own&filename-lk=*.zip'
curl --request GET 'https://api.mod.io/v1/games/57/mods?api_key=use_your_own&filename-lk=*.zio'

Both return the same results (5, that is), while I would expect the second one to not return any result, as the only files present are some demo.zip files (which also does not seem to have the same md5sum as the filehash would indicate).

@Patskimoto
Copy link

Patskimoto commented Dec 6, 2017

The filtering is working correctly, however, because filename is nested within the modfile object the filter is not being applied. It does not return an error because its an invalid filter so the api simply ignores it. If you supply a filter that is an invalid type (for instance you try to filter the id column by a string) it will return an error. This is what was meant by the documentation stating that only bottom/base level objects can be filtered by. This is something I want to support in the near future, but for the meantime, if you wanted to filter by the filename you would have to do:

curl --request GET 'https://api.mod.io/v1/games/57/mods/{id-here}/files?api_key=use_your_own&filename-lk=*.zip'

@leper
Copy link
Author

leper commented Dec 7, 2017

Thanks, makes sense given the update to #35.

About invalid filters not returning an error, but invalit types doing so that seems slightly strange. I guess not complaining about the former is easier than actually checking if they exist, but from a logical point of view filtering based on x and nothing having x so the filter does not match would make me expect not getting any result.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants