Skip to content
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

Track the index of a transaction within a block #91

Closed
wkoder opened this issue May 8, 2020 · 4 comments
Closed

Track the index of a transaction within a block #91

wkoder opened this issue May 8, 2020 · 4 comments

Comments

@wkoder
Copy link

wkoder commented May 8, 2020

Hi, the Atala Prism team has started integrating with cardano-db-sync and could not find a way to order transactions within a block. Can we plan on adding a column to track the transaction index?

Or, as a workaround or perhaps definite way, can we just sort by the sequential tx.id?

Thanks!

@erikd
Copy link
Contributor

erikd commented May 9, 2020

tx.id are generated by Postgres. They are not reliably monotonic.

I agree 100% that the index should be added.

@kevinhammond
Copy link
Contributor

OK. Let's add this. How urgent is it? What are you actually trying to do - ensure that transactions have been processed in the right order?

@erikd
Copy link
Contributor

erikd commented May 13, 2020

The tx index is part of the tx and it should be recorded in the DB. The fact that it is not is an oversight.
Eg, if one wants to build a transaction, they need to know the exact index in the tx output.

When I came back to this, I misread/misunderstood the question.

Yes, index of a transaction within a block would be easy to add and should be added.

erikd added a commit that referenced this issue May 17, 2020
This new field is the index of the transaction within a block. There
is no easy way to write a migration for this, so the database needs to
be dropped and recreated.

Closes: #91
erikd added a commit that referenced this issue May 18, 2020
This new field is the index of the transaction within a block. There
is no easy way to write a migration for this, so the database needs to
be dropped and recreated.

Closes: #91
@erikd erikd closed this as completed in b7b100a May 19, 2020
@wkoder
Copy link
Author

wkoder commented May 19, 2020

Thank you, @erikd !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants