-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
db extensions #646
base: main
Are you sure you want to change the base?
db extensions #646
Conversation
|
||
func (e *HTLCTokenDBExtension) GetSchema() string { | ||
return fmt.Sprintf(` | ||
-- Tokens |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess Tokens should be 'HTLC' or 'Interop' here. Or wait, do you actually mean the existing 'tokens' table here, or a new one that exists next to the 'tokens' table?
If it's the first, that could become an issue with versioning and updates (our code doesn't handle db migrations yet, but should in the near future and extending an existing table adds another dimension that makes it harder).
} | ||
|
||
type HTLCTokenDBExtension struct { | ||
table htlcTokenDBExtensionTables |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a dependency on the 'tables' struct here. We can make our lives much easier by removing the feature of the 'table prefixes' everywhere (which I think we should do anyway!). Then, every db just decides by itself in the code what its tables are called.
idx INT NOT NULL, | ||
sender_raw BYTEA NOT NULL, | ||
recipient_raw BYTEA NOT NULL, | ||
deadline TIMESTAMP NOT NULL, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of these fields are already very nice to have! Now after this, it would be amazing to have the following two fields as well:
- preimage (easy; after scanning the blockchain it can be just updated in the table)
- status (trickier; depends on heuristics of whether the deadline is past and the preimage is available...)
I'm not sure how the process of these should work, like when they would be updated and if the 'interop' package already has the right hooks to manage that. But let's consider it in the design; if there is a way, it would help with the transparency and integrity of htlc transactions.
In terms of use cases, I'll share some diagrams and code with you that I used to approach this state on the application level.
logger.Debug(query, | ||
tr.TxID, | ||
tr.Index, | ||
script.Sender, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sender and recipient are probably too large to debug?
389d99f
to
34995fe
Compare
Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>
Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>
Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>
Signed-off-by: Angelo De Caro <adc@zurich.ibm.com>
This PR introduces a mechanism to extend the TokenDB to store additional information about a token.
For example, when a token's owner field contains an HTLC (
service/interop/htlc
) script, it would be convenient to store script-related information for more targeted queries and data analysis.