Блог

API хранилища Corda содержит класс под названием CommonQueryCriteria, который реализован следующим образом:

 abstract class CommonQueryCriteria : QueryCriteria() {
    abstract val status: Vault.StateStatus
    open val relevancyStatus: Vault.RelevancyStatus = Vault.RelevancyStatus.ALL
    open val constraintTypes: Set<Vault.ConstraintInfo.Type> = emptySet()
    open val constraints: Set<Vault.ConstraintInfo> = emptySet()
    open val participants: List<AbstractParty>? = null
    abstract val contractStateTypes: Set<Class<out ContractState>>?
    open val externalIds: List<UUID> = emptyList()
    open val exactParticipants: List<AbstractParty>? = null
    override fun visit(parser: IQueryCriteriaParser): Collection<Predicate> {
    return parser.parseCriteria(this)
    }
}
 

Какова цель externalIds собственности?

Примечание: Это, конечно, не может быть предназначено для отображения UniqueIdentifier.externalId , потому что:

• Существует несоответствие типов ( UUID против String? ).
• LinearStateQueryCriteria существует для запроса состояний с помощью linearId или externalId .

Это было введено для поддержки запросов учетных записей еще в Corda 4.3: https://github.com/corda/accounts/blob/master/docs.md#querying-the-vault-by-account

В документации по запросу хранилища упоминается этот новый атрибут прямо внизу страницы при обсуждении владения ключами: https://docs.corda.net/docs/corda-os/4.8/api-vault-query.html#mapping-owning-keys-to-external-ids

По общему признанию, это не очень понятно и должно ссылаться CommonQueryCriteria (не VaultQueryCriteria ) и показывать пример.

Хотя, если мы посмотрим на поток createAccount, предоставляемый библиотекой учетных записей, AccountInfo UniqueIdentifier он создается с помощью только id :

 val newAccountInfo = AccountInfo(
         name = name,
         host = ourIdentity,
         identifier = UniqueIdentifier(id = identifier)
)
 

в то время как конструктор UniqueIdentifier имеет как externalId и id :

 data class UniqueIdentifier
   constructor(val externalId: String? = null, val id: UUID = UUID.randomUUID())
 

Таким образом, фактически, если верно, что externalId был введен для поддержки запросов с учетной записью, запросы хранилища фактически используют функцию UniqueIdentifier.id of AccountInfo , а не ее externalId (при условии, что никто не создает AccountInfo функцию, переопределяющую CreateAccount() функцию вручную, как я подозреваю).