Make Accounts Easier To Use

[opticyclic]

Discussion before adding a pull request:

In my test code I have a few extension functions to make using the accounts SDK easier. e.g. this:

val StateAndRef<AccountInfo>.uuid: UUID get() = state.data.linearId.id

fun VaultService.accountStates(accountId:UUID): List<StateAndRef<ContractState>> {
    return this.queryBy<ContractState>(QueryCriteria.VaultQueryCriteria(externalIds = listOf(accountId))).states
}

allows me to do this:

banks.services.vaultService.accountStates(bank1.uuid)

Instead of this:

banks.services.vaultService.queryBy<ContractState>(QueryCriteria.VaultQueryCriteria(externalIds = listOf(bank1.state.data.linearId.id))).states

However, calling kotlin extension functions from Java is tricky.

Would this and other similar helper functions be better in AccountService/KeyManagementBackedAccountService?

See also https://github.com/corda/accounts/issues/37

[roger-that-dev]

Seems like a good idea - thanks!

[dezzeus]

I'm questioning if we can also let the accountService.accountInfo(...) helpers just return the AccountInfo object instead of StateAndRef…

[roger-that-dev]

We can't change them as it would break backwards compatibility but we can add new methods that do what you describe.

[dezzeus]

Good point. It's not really needed, but promotes cleaner code (IMHO); maybe we can break that behaviour with v2.0 :P (and introduce new methods for those who may need the stateAndRef)

[roger-that-dev]

Yeah fair point. Reason for returning StateAndRef was that then you can then build transactions with it. With just the AccountInfo you can't use it as an input or reference in a transaction.

[dezzeus]

Makes sense to have such an helper, even thought I'm not sure about the direct use of AccountInfo in transactions (i.e. accounts are handled with flows, while states refers to AnonymousParty, not LinearPointer of AccountInfo)

[dezzeus]

Another idea for an helper: something to use in the SignTransactionFlow::checkTransaction that, given an AnonymousParty / PublicKey, throws an exception if:

• It's not associated to an account.
• The node is not the host of the associated account.
• Something else that I may haven't thinked about…

Again, it's not needed, but can by handy. :)