For future testing it would be nice, post serialisation, to have easy
access to the serialised objects schema so we can check how it was
serialised. Adding a helper function to return a data class that does
this in the same way we can for deserialize
Move default session ID into messaging service to clean up the API. This means it no longer shows up in a Java class (ServiceHubInternalKt) as its only member, and is instead scoped into the service that actually uses the value. This does result in a MessagingService.Companion object (as MessagingService is an interface), however this is probably the most sensible solution.
* Performance fix: prevent self joins on VaultStates table (was occurring when Sort specified).
* Enrichment and overriding of Common attributes (eg. Vault.StateStatus and Contract State Types) using composite query criteria.
Remove unnecessary QueryEditor implementation from NodeVaultService.
* Updated documentation and changelog.
* Misc fixes to broken documentation code snippets.
* Incorporating changes from PR review feedback.
Current implementation is such that if we find *a* constructor that
works for us we use that, this is of course rather non deterministic, it
also means we may not select the best constructor
for example
old versions had constructors that took
V1: A B
V2: A B C D
if current version, V3 is
V3: A B C D E
which provides secondary constructors for the above then there is a
chance we'd de-serialise objects that were serialised as V2 using the V1
constructor and thus throw away information we don't need to
Additional Changes:
Fixes following rebase onto master
If we attempt to deserialize a class and find that since it's
serialization the definition has changed we need to create a serializer
capable of evolving the serialised data and constructing an instance of
the new type
We currently cope with
* Removing members
* Adding nullable members
* Adding non nullable members if a constructor is provided that
allows us to set the old arguments and defaults the new (mandatory)
fields
* Reordering paramters
This can be useful if we decide to create a custom TeamCity configuration that will enable us to independently run *all* tests in AMQP mode to know where we stand.
Adapt CollectSignaturesFlow to handle anonymous transactions where the keys signing commands on a transaction are not necessarily the well known identity of the participating nodes. Also prepares for any potential move away from nodes having a single primary identity by requiring flows to specify the identities they're using for a transaction.