ExternalVendorCode/corda
1
0
Fork 0
mirror of https://github.com/corda/corda.git synced 2025-06-01 23:20:54 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

client: Elaborate on why we need two IDs in TransactionCreateStateModel

Browse Source
This commit is contained in:
Andras Slemmer 2016-09-06 11:09:18 +01:00
parent d5c4202162
commit 6b6c51b8d4
1 changed files with 6 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
client/src/main/kotlin/com/r3corda/client/model/TransactionCreateStateModel.kt
View File

@ -54,7 +54,12 @@ class TransactionCreateStateModel {
/** /**
* Aggregation of updates to transactions. We use the observable list as the only container and do linear search for * Aggregation of updates to transactions. We use the observable list as the only container and do linear search for
* matching transactions because we have two keys(fiber ID and UUID) and this way it's easier to avoid syncing issues * matching transactions because we have two keys(fiber ID and UUID) and this way it's easier to avoid syncing issues.
*
* The Fiber ID is used to identify events that relate to the same transaction server-side, whereas the UUID is
* generated on the UI and is used to identify events with the UI action that triggered them. Currently a UUID is
* generated for each outgoing [ClientToServiceCommand].
*
* TODO: Make this more efficient by maintaining and syncing two maps (for the two keys) in the accumulator * TODO: Make this more efficient by maintaining and syncing two maps (for the two keys) in the accumulator
* (Note that a transaction may be mapped by one or both) * (Note that a transaction may be mapped by one or both)
* TODO: Expose a writable stream to combine [serviceToClient] with to allow recording of transactions made locally(UUID) * TODO: Expose a writable stream to combine [serviceToClient] with to allow recording of transactions made locally(UUID)