From 6b6c51b8d4f3f36eab413c8c03ea024cabbf6cd4 Mon Sep 17 00:00:00 2001
From: Andras Slemmer <andras.slemmer@r3cev.com>
Date: Tue, 6 Sep 2016 11:09:18 +0100
Subject: [PATCH] client: Elaborate on why we need two IDs in
TransactionCreateStateModel
---
.../r3corda/client/model/TransactionCreateStateModel.kt | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/client/src/main/kotlin/com/r3corda/client/model/TransactionCreateStateModel.kt b/client/src/main/kotlin/com/r3corda/client/model/TransactionCreateStateModel.kt
index dd269bd91e..2be0737d6f 100644
--- a/client/src/main/kotlin/com/r3corda/client/model/TransactionCreateStateModel.kt
+++ b/client/src/main/kotlin/com/r3corda/client/model/TransactionCreateStateModel.kt
@@ -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
- * 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
* (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)