You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 11, 2024. It is now read-only.
Right now, filling in attribute values uses a one-call-one-item approach. However, I just realized today that it's possible to search for such things as researchers using a list syntax like this:
search publications where researchers.id in ["ur.015050223327.40", "ur.07402772253.38"] return researchers
This means that it would be possible to reduce the number of API calls in some situations by getting the results for multiple people at once. This would help avoid hitting the API rate limit as much.
The tricky part is figuring out in what situation you can group a call for data like this. In the current scheme of things, a fill operation is initiated when something accesses an attribute that has not yet been set, like the list of affiliations on a researcher. To do that for multiple researchers in one shot, you would need to know ahead of time that the user's code is going to access the fields on multiple objects, and know which specific objects they will be. That means some kind of predictive heuristic approach. This needs more thought.
The text was updated successfully, but these errors were encountered:
Right now, filling in attribute values uses a one-call-one-item approach. However, I just realized today that it's possible to search for such things as researchers using a list syntax like this:
This means that it would be possible to reduce the number of API calls in some situations by getting the results for multiple people at once. This would help avoid hitting the API rate limit as much.
The tricky part is figuring out in what situation you can group a call for data like this. In the current scheme of things, a fill operation is initiated when something accesses an attribute that has not yet been set, like the list of affiliations on a researcher. To do that for multiple researchers in one shot, you would need to know ahead of time that the user's code is going to access the fields on multiple objects, and know which specific objects they will be. That means some kind of predictive heuristic approach. This needs more thought.
The text was updated successfully, but these errors were encountered: