Remove assumption of ContractId == EventId
See original GitHub issueIn the realm of PostgresIndexer+PostgresIndex with a 3rd party ledger implementation, the absolute ContractIDs provided by the ledger cannot be reused as eventIds as we have done within the sandbox. This assumption is currently relied upon when populating the contract_creating_event_id
for exercised events: https://github.com/digital-asset/daml/blob/2d52406199e0bcc82ec1bbb5c25a175f138722f1/ledger/sandbox/src/main/scala/com/digitalasset/platform/sandbox/stores/ledger/TransactionConversion.scala#L162-L167
I see two ways out of this:
- we store additional data that allows us to reconstruct the event id on transmission
- we deprecate the field (breaking change) and at the same time add methods to lookup transactions by event id
1) Store additional data in the database
- create new schema migration version X
- X.0 add column
event_id varchar
tocontracts
table (similar to workflow_id, transaction_id) - X.1 add column
exercised_contract_ids varchar []
toledger_entries
table - X.2 create migration that reads all transactions
- for CreateEvents -> write event id into contracts#event_id
- for exercised events -> write contract_id into ledger_entries#exercised_contract_ids
- modify the query for loading a transaction to join the contracts table to load the contract_creating_event_ids for all exercising contracts
2) Deprecate ExercisedEvent#contract_creating_event_id and add TransactionService#getTransactionByContractId
The only thing a user really can do with the event id is to lookup a transaction. If instead we add methods to lookup a flat transaction and transaction trees by contract id, the user can achieve the same action. Additionally the notions of transaction id and contract id are much more relatable than event id. This is a breaking change. This needs a migration for extractor, which stores the contract creating event id into a separate database column.
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (6 by maintainers)
Top GitHub Comments
@gerolf-da My understanding is that we don’t do migrations, because you can always just extract the ledger again from scratch.
The 2nd part isn’t done yet, which is adding the getTransactionByContractId, but so far there hasn’t really been demand for it. I’m fine wihh closing the ticket.