run lazy aggregate reads on a stale snapshot - #239
Conversation
58ad58a to
3fb7d7f
Compare
commit: |
3fb7d7f to
6af4ee0
Compare
6af4ee0 to
af978ff
Compare
|
For read operations, I wonder if |
af978ff to
88bdb4a
Compare
88bdb4a to
b6200fb
Compare
ianmacartney
left a comment
ianmacartney
left a comment
There was a problem hiding this comment.
overall lgtm. However, I do agree that "stale" makes more sense on the read path. I feel like I led you astray by pointing out the awkwardness on the write path. What do you think about naming:
- stale:true on queries where it's using stale snapshot & ignoring pending ops
- async:true on mutations where it's enqueueing the operation
?
| }); | ||
| } | ||
| // `lazy` is ignored in actions and queries, where all reads may be stale. | ||
| // We will throw an error in queries if there are pending operations that have not been applied. |
There was a problem hiding this comment.
nit: try to avoid comments that describe actions at a distance that may not stay up to date
| useStaleSnapshot: true, | ||
| }); | ||
| } | ||
| // `lazy` is ignored in actions and queries, where all reads may be stale. |
There was a problem hiding this comment.
nit: this isn't quite true: all reads aren't stale in queries, and from actions they're sort of "stale", in that they don't conflict, but there isn't something non-stale to compare them to there.. so maybe just clarify that from actions, it won't conflict but from queries it will?
There was a problem hiding this comment.
yeah that makes sense - I think I was trying to express that if there are still pending operations, the aggregate isn't fully consistent yet, so lazy reads in actions and queries do not see the effects the pending operations.
|
I like |
b6200fb to
62d070c
Compare
0dd012a to
b574acb
Compare
b574acb to
6da7560
Compare
2 participants
Adds a
lazyoption to read methods, which will run the query withuseStaleSnapshotin mutations.