Get multiple balances with both acknowledged and saved balances #8
Comments
|
@PaulBernier How do you envision this fitting in with other API calls that use unconfirmed data? Using unconfirmed balances/txs of addresses is very useful many extant calls, not just this purpose built one:
Personally I would prefer either a fatd startup flag or param you could submit with your RPC request for those methods. |
|
Why not just always return both?
…On Fri, Feb 8, 2019, 1:32 PM Devon Katz ***@***.***> wrote:
@PaulBernier <https://github.com/PaulBernier> How do you envision this
fitting in with other API calls that use unconfirmed data? Using
unconfirmed balances/txs of addresses is very useful many extant calls, not
just this purpose built one:
- get-balance (single address version of above)
- get-nf-balance
- get-transaction
- get-stats (circ. supply, burned, last tx timestamp which would
otherwise be 0-10 mins off, etc)
Personally I would prefer either a fatd startup flag or param you could
submit with your RPC request for those methods.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF2XcCcBm-RNUxncdOn2n0je4YCHzsJBks5vLfsRgaJpZM4aZbo2>
.
|
|
@AdamSLevy Just returning both mutates and clutters the responses a bunch, if I'm taking your meaning correctly. For example, there would have to be |
|
Good point. So how about an optional request parameter as you suggested? |
|
@AdamSLevy That would be just fine 👍 |
The long awaited pending transaction support is here. This implementation fully leverages the existing validation and database code. No new tables, nor schema changes were required. When pending transactions are enabled (default), when a pending transaction for a tracked change is detected, a new in memory copy of that chains database is created. This in memory database uses a shared cache so a pool of read only connections can also be opened to it. A session is used to track the changes to the in memory database as pending entries are applied to it. When the next EBlock is published, the inverse of the session's changeset is used to rollback all pending txs on the in memory db. A new session on the main database is used to generate a changeset for applying this EBlock. This session is kept open until another pending entry is available for that database, at which point this session's changeset is used to sync the in-memory database with the main database. One advantage to this approach is that is allows for full code reuse of the validation code. The downside is that a full copy of each chain database must be kept around in memory. The -disablepending flag has been added to allow resource constrained systems to not track pending transactions. re #14 #8
|
The "includepending" param can be used to request pending balances |
Have an API similar to factomd
multiple-fct-balancesthat would return the temporary balance of an address (acknowledged balance vs saved).
Motivation
This is very useful for the end user to have the temporary balance of an address before the block is saved. That allows all UIs to be "reactive" to transactions, otherwise having to wait up to 10 minutes to see what has happened is not a good user experience.
How it would work I think would be for fatd to poll the pending entries, filter any FAT transactions and apply those on top of the saved state.
The text was updated successfully, but these errors were encountered: