Added an isLegalIdentity function that allows the client to check if the Node represents the requested CordaX500Name without throwing an exception if it does not.
With (Contract JARs) rolling upgrades the downgrade rule cannot be effectively check as the platform can't tell the difference between a transaction that's downgrading because of an attack, vs a transaction that's downgrading because Alice has upgraded but Bob hasn't yet. During a rolling upgrade we would expect state versions to fluctuate up and down as data gets read/written by a mix of nodes. With the feature as implemented Alice will upgrade and start trading with Bob. Bob will be able to read and process the states Alice sent him, but the moment he tries to consume such a state he will fail. This will result in cascading flow deaths and a hung business network the moment an upgrade starts.
* Create a new custom migration for populating the state_party table and the relevancy_status column within the vault_states table when migrating from V3 to V4.
* Add a corresponding unit test suite.
* Small refactorings to expose data required by the migration: the isRelevant function in the NodeVaultService, and the node's legal name from the configuration.
- Delete information about hash->signature constraint migration. That
won't work for C4.0
- Rewrite parts of the api-contract-constraints.rst file to fix grammar
problems and reduce the weight of the page. Some detail isn't really
necessary at this point in the docs.
- Mention more things in the upgrade notes.
Previous implementation was in LedgerTransaction and focused only on contract classes,
but every package matters.
Also fixes some exception types and does misc refactorings.
Take out a useless parameter from a method that was added to the public
API, document it. Add some comments explaining more about why we are
looking up attachment versions in WireTransaction.toLedgerTransaction.
* CORDA-2547: WIP Migrate old notary schema correctly.
Modify liquibase scripts to rename the old committed state table instead of creating a new one.
* Rename liquibase change sets
* Change 3.3 baseline before Liquibase.
* Aligin with ENT, orginal node-notary.changelog-v1.xml moved to node-notary.changelog-v2.xml and it's compatible with ENT (which already has changes from v2).
* Aligin with ENT, orginal node-notary.changelog-v1.xml moved to node-notary.changelog-v2.xml and it's compatible with ENT (which already has changes from v2) - adding v2 to master file.
* Ensure setting up Liquibase on pre-existing pre-Liquibase database
