I’ve noticed that when you yield a list of players, with a request like this https://online-go.com/api/v1/players, there are several fields, including one so called ui_class.
The problem however seems to be that some players have an empty string as their ui_class, and that brakes whatever query one may want to make on it.
For example, the following will all result in bad requests (status 400):
and the detail is always the same: “Player has no field named u’ui_class’”
I wonder, if this intentional? because it really cripples the possibility to make certain meaningful requests.
Thanks
Edit Changed the wording for clarity. Also a side note: I don’t mean to sound accusing, I really wonder if matburt and anoek did not intend to provide such queries to begin with.
This is not about game records, and certainly not about the real time api. I am yet to see a single player that has no ui_class field, even if it is blank.
The problem I’m pointing out is that queries, which are handled by the server, don’t seem to work at all, if they involve the ui_class field.
So, for example, I cannot ask for a list of non-provisional players, or those who haven’t timed out. But neither can I ask for those who are indeed provisional or timed out.
The reason you can’t query on ui_class is because it isn’t actually a field in the database. Rather it’s a field that is materialized when the api view is requested through the data serializer. We do this kind of thing on the back-end mainly to help the UI (surprise!) so that it doesn’t have to grab a bunch of other fields from different places to come up with it on its own.
It’s much faster for us to gather up the data on the backend and serve it in a single request than for the UI to make 3 or 4 api calls (per player in this case) to generate it on its own.
So it’s totally not to act as a roadblock to anyone wanting to use it. The alternative is to pre-calculate this at certain points during the backend request-response cycle or as periodic batch jobs but neither of those are ideal. They’d either add too much time when processing the response or they wouldn’t be fast enough to provide instant feedback for the UI. It also has the potential to lead to more bugs due to logic gaps.
The API really has two purposes… to drive the UI and to act as a programatic interface to our system. So sometimes we’ll do these kinds of things to help the UI out.
Possibly the better question is… what are you hoping to achieve using ui_class and is there a better way to arrive at the result?
That’s folks who have 0 provisional games. We alias that due to the legacy naming in the database of numProvisional when looking at player detail. You can use some cool operators if you want to dice things up a bit:
That was an excellent response, very much exactly what I wanted to know.
By the way, is there a way to collaborate with the documentation? Say the Player Guide, the FAQs or even the API docs.
I say this because I’m very aware you have to prioritize the time you spend on the server, but some users (among which I’d include myself) have become reasonably familiar with the system and could help explain it (alas! even the undocumented parts of the API, we’ve smuggled out a few things by trial and error ;))