-
Notifications
You must be signed in to change notification settings - Fork 27
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
CORE-15552 Add findUnconsumedStatesByExactType
paging API
#4837
CORE-15552 Add findUnconsumedStatesByExactType
paging API
#4837
Conversation
API PR - corda/corda-api#1292 |
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 think the overall approach to re-using the existing custom query logic is a good idea, but I'm unconvinced about the need for a separate factory for this query.
Also, I'd like to see some new E2E test cases proving that the query works with the paging functionality. If we want to do this in the E2E test repo (rather than smoke tests in this PR) that's fine, but we should reference that PR from this one.
...nce/src/main/kotlin/net/corda/ledger/persistence/query/impl/DefaultVaultNamedQueryFactory.kt
Outdated
Show resolved
Hide resolved
...nce/src/main/kotlin/net/corda/ledger/persistence/query/impl/DefaultVaultNamedQueryFactory.kt
Outdated
Show resolved
Hide resolved
...otlin/net/corda/ledger/persistence/query/registration/impl/VaultNamedQueryFactoryProvider.kt
Outdated
Show resolved
Hide resolved
JOIN {h-schema}utxo_transaction_output AS tx_o | ||
ON tx_o.transaction_id = tc_output.transaction_id | ||
AND tx_o.leaf_idx = tc_output.leaf_idx | ||
JOIN {h-schema}utxo_transaction AS tx | ||
ON tx.transaction_id = tx_o.transaction_id | ||
WHERE tx_o.type = :type | ||
ON tx.id = tc_output.transaction_id | ||
WHERE vto.type = :type |
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'm not sure why this is appearing in the diff. Looks like it's part of @nkovacsx recent data model simplification changes, so if we've merged / rebased these then this shouldn't be a diff?
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.
It is a correction, there wasn't an E2E test around this so it failed when tested.
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.
This code is now deleted anyway.
de9a4d2
to
85df66f
Compare
Jenkins build for PR 4837 build 17 Build Successful: |
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.
It needs a sync, but otherwise, LGTM.
cd03e19
to
24bf58e
Compare
24bf58e
to
2669741
Compare
0a9d470
to
df46ed8
Compare
Reuse the vault named query logic to create a `findUnconsumedStatesByExactType` API that supports paging without too much extra work. `DefaultVaultNamedQueryFactoryImpl` registers a query for finding states by their exact type. This factory is then manually registered in `VaultNamedQueryFactoryProvider`. We could potentially add a better lookup mechanism in the future, but there is unlikely to be additional `VaultNamedQueryFactory`s that we register in the future.
2534fe8
to
26dd2a4
Compare
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.
LGTM
Add findUnconsumedStatesByExactType to UtxoLedgerService , allowing developers to retrieve states by type from the vault in pages. This dissuades developers from retrieving every state from the vault in one go and returning them to a flow.
Reuse the vault named query logic to create a
findUnconsumedStatesByExactType
API that supports paging without too much extra work.DefaultVaultNamedQueryFactoryImpl
registers a query for finding states by their exact type.This factory is then manually registered in
VaultNamedQueryFactoryProvider
.We could potentially add a better lookup mechanism in the future, but there is unlikely to be additional
VaultNamedQueryFactory
s that we register in the future.