Handle the case of still pending promises in ad-hoc queries #5607
Assignees
Labels
Milestone
Comments
teh-cmc
added
📺 re_viewer
5 tasks
|
A very related question that will come up in pretty much all the same places: when are we okay with looking at the raw promise itself rather than waiting for the data to resolve? |
teh-cmc
added a commit
that referenced
this issue
Apr 8, 2024
Now that we have a component-based latest-at cache, we can start replacing legacy uncached helpers with new ones. Commit-by-commit review should be trivial. Because the new APIs are designed with promises in mind, this already highlights a whole bunch of places where we need to think about what to do in case the data is not ready yet. As indicated in #5607, these places have been labeled `TODO(#5607)` in the code. For now, we simply treat a pending promise the same as missing data. This PR also adds the new `Caches` and `PromiseResolver` to the `EntityDb`. To run a cached query, you now need a `DataStore`, a `Caches` and a `PromiseResolver`, i.e. you need an `EntityDb`. --- Part of a PR series to completely revamp the data APIs in preparation for the removal of instance keys and the introduction of promises: - #5573 - #5574 - #5581 - #5605 - #5606 - #5633 - #5673 - #5679 - #5687 - #5755 - TODO - TODO Builds on top of the static data PR series: - #5534
teh-cmc
added this to the 0.18 - Chunks, MHz scalars, Image & Transform changes milestone
6 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Now that we've started integrating the new data APIs into the codebase, there are many, many places where we need to decide on the behavior to adopt if a query happens to return a promise that is still pending.
Every such instance has been tagged in the codebase with the following comment:
At the moment, we simply treat unresolved promises the same as missing data.
The text was updated successfully, but these errors were encountered: