Add starting_at option to CryptoGetAccountRecordsQuery
#144
Conversation
Signed-off-by: tinker-michaelj <michael.tinker@hedera.com>
Signed-off-by: tinker-michaelj <michael.tinker@hedera.com>
|
|
||
| /** | ||
| * If set, a restriction on the first payer record to be returned. The queried node will | ||
| * return this record (assuming one qualifies), and up to to the next 179 records, in |
There was a problem hiding this comment.
Isn't the limit (180) configurable? In which case we shouldn't document 179 here, we should just say we will return all records up to some maximum amount (put it in better words, but that's the idea). Same with the 180 on line 54.
There was a problem hiding this comment.
Updated comment with link to the Services property.
| /** | ||
| * The transaction id of the first record to return. | ||
| */ | ||
| TransactionID transaction_id = 3; | ||
| /** | ||
| * The earliest consensus time of the first record to return. | ||
| */ | ||
| Timestamp earliest_consensus_time = 4; |
There was a problem hiding this comment.
Is there any difference in performance depending on which of these two is used? In both cases are we going to iterate through the records looking for the first that meets the criteria?
There was a problem hiding this comment.
Yes, with current FCQ implementation, we need to iterate through all records no matter what. (If random access was supported, we could do binary search for earliest consensus time, but it isn't.)
There was a problem hiding this comment.
Not sure we should add this feature until the data structure has a performant way to allow it...
There was a problem hiding this comment.
The current implementation already iterates through all records. 😬
There was a problem hiding this comment.
Yeah, but we're adding a limit now so it will only iterate through the first K records where K is the limit and N is the total number of records. But with this feature they could pick the last transaction id so it will be O(N).
There was a problem hiding this comment.
Oh, unless it has to iterate through all to filter down by account ID. I'm guessing it's not in a map by account id.
There was a problem hiding this comment.
Right, these records are in an FCQueue which doesn't support random access (or even reverse traversal).
No matter how the user restricts (or doesn't restrict) the query, we must iterate through the entire FCQ.
Signed-off-by: tinker-michaelj <michael.tinker@hedera.com>
Description:
CryptoGetAccountRecordsQueryto restrict the first payer record returned.TransactionIDof the first record returned.