diff --git a/.editorconfig b/.editorconfig index fda65ad3f..3916710a6 100644 --- a/.editorconfig +++ b/.editorconfig @@ -279,6 +279,7 @@ dotnet_diagnostic.SA1611.severity = none # SA1611ElementParametersMustBeDocument dotnet_diagnostic.SA1618.severity = none # SA1618GenericTypeParametersMustBeDocumented dotnet_diagnostic.SA1602.severity = none # SA1602EnumerationItemsMustBeDocumented dotnet_diagnostic.SA1601.severity = none # SA1601PartialElementsMustBeDocumented +dotnet_diagnostic.SA1623.severity = none # SA1623PropertySummaryDocumentationMustMatchAccessors # Other dotnet_diagnostic.SA1200.severity = none # SA1200UsingDirectivesMustBePlacedCorrectly - Don't care about this now that there are flattened namespaces diff --git a/CHANGELOG.md b/CHANGELOG.md index 597f9571e..13c674a5a 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,3 +1,28 @@ +## 1.4.0 +Release Date: 08.02.2024 + +- Dropped internal `balance_changes` fallback mechanism. As of right now this information is ingested as part of regular transaction ingestion process. +- Reworked internal mechanism used to fetch network configuration. Is no longer stored in the underlying database and it is shared across all services. +- Reworked (partially) internal mechanism used to ingest ledger data by Data Aggregator to improve maintainability and simplify future extensions. +- Fixed `state_version`-based ledger state `at_ledger_state`/`from_ledger_state` constraints which could result in inaccurate lookups previously. Attempt to read from non-existent state version will result in HTTP 400 Bad Request. Previously the nearest state version would be used. + +### API Changes +- Return components effective role assignments only for assigned modules. +- Added new filters for the `/stream/transactions` endpoint: `accounts_with_manifest_owner_method_calls`, `accounts_without_manifest_owner_method_calls` and `manifest_class_filter`. +- Extended response models returned by `/transaction/committed-details` and `/stream/transactions` endpoints: + - added `manifest_instructions` optional property and a corresponding opt-in for returning original manifest of user transactions, + - added optional `manifest_classes` property: a collection of zero or more manifest classes ordered from the most specific class to the least specific one. +- Added `permanently_rejects_at_epoch` to `/transaction/status` response for pending transactions. +- Added new endpoint `/state/key-value-store/keys/` that allows iterating over `KeyValueStore` keys. + +### Database changes +- Created new `key_value_store_aggregate_history` table which will hold pointers to all key_value_store keys. +- Dropped `network_configuration` table. +- Fixed component's method royalty aggregation, added missing `component_method_royalty_aggregate_history` table. +- Changed `IX_validator_emission_statistics_validator_entity_id_epoch_num~` index to include `proposals_made` and `proposals_missed` columns in order to optimize `/statistics/validators/update` endpoint. + +### Deprecations +- Obsoleted incorrectly named `access_rules_package` in favor of `role_assignment_module_package` on `NetworkConfigurationResponse.well_known_addresses`. Obsoleted property will contain effective copy of the new one for backwards compability. ## 1.3.0 Release Date: 29.01.2024 diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md new file mode 100644 index 000000000..935425af4 --- /dev/null +++ b/CODE_OF_CONDUCT.md @@ -0,0 +1,76 @@ +# Radix DLT Code of Conduct + +## Our Pledge + +In the interest of fostering an open and welcoming environment, we as +contributors and maintainers pledge to making participation in our project and +our community a harassment-free experience for everyone, regardless of age, body +size, disability, ethnicity, sex characteristics, gender identity and expression, +level of experience, education, socio-economic status, nationality, personal +appearance, race, religion, or sexual identity and orientation. + +## Our Standards + +Examples of behavior that contributes to creating a positive environment +include: + +* Using welcoming and inclusive language +* Being respectful of differing viewpoints and experiences +* Gracefully accepting constructive criticism +* Focusing on what is best for the community +* Showing empathy towards other community members + +Examples of unacceptable behavior by participants include: + +* The use of sexualized language or imagery and unwelcome sexual attention or + advances +* Trolling, insulting/derogatory comments, and personal or political attacks +* Public or private harassment +* Publishing others' private information, such as a physical or electronic + address, without explicit permission +* Other conduct which could reasonably be considered inappropriate in a + professional setting + +## Our Responsibilities + +Project maintainers are responsible for clarifying the standards of acceptable +behavior and are expected to take appropriate and fair corrective action in +response to any instances of unacceptable behavior. + +Project maintainers have the right and responsibility to remove, edit, or +reject comments, commits, code, wiki edits, issues, and other contributions +that are not aligned to this Code of Conduct, or to ban temporarily or +permanently any contributor for other behaviors that they deem inappropriate, +threatening, offensive, or harmful. + +## Scope + +This Code of Conduct applies both within project spaces and in public spaces +when an individual is representing the project or its community. Examples of +representing a project or community include using an official project e-mail +address, posting via an official social media account, or acting as an appointed +representative at an online or offline event. Representation of a project may be +further defined and clarified by project maintainers. + +## Enforcement + +Instances of abusive, harassing, or otherwise unacceptable behavior may be +reported by contacting the project team at hello@radixdlt.com. All +complaints will be reviewed and investigated and will result in a response that +is deemed necessary and appropriate to the circumstances. The project team is +obligated to maintain confidentiality with regard to the reporter of an incident. +Further details of specific enforcement policies may be posted separately. + +Project maintainers who do not follow or enforce the Code of Conduct in good +faith may face temporary or permanent repercussions as determined by other +members of the project's leadership. + +## Attribution + +This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, +available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html + +[homepage]: https://www.contributor-covenant.org + +For answers to common questions about this code of conduct, see +https://www.contributor-covenant.org/faq diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000000000..958b561f4 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,154 @@ +# Contributing Guidelines + +Thank you for your interest in contributing to Babylon Network Gateway! + +## Clarification on GitHub Issue Usage and Feature Requests + +We want to clarify that Github Issues are primarily meant for the purpose of reporting problems or concerns, rather than functioning as an open bug tracker. This means that reported issues on Github may be closed and reported in our internal tracking system or added to our roadmap. + +If you are thinking of requesting a feature, make sure it’s not already part of our upcoming features outlined in the [Roadmap](https://docs.radixdlt.com/docs/roadmap). If you have a feature suggestion, we kindly ask that you share it through [Discord](http://discord.gg/radixdlt) or [Telegram](https://t.me/RadixDevelopers). + +Our primary focus is on the priorities outlined in our Roadmap. We appreciate your understanding that addressing reported issues may not always align with our immediate roadmap goals. + + +# Table of Contents +1. [Code of Conduct](#code-of-conduct) +2. [Reporting Issues](#reporting-issues) +3. [Contributing Code](#contributing-code) + - [Setting Up Your Development Environment](#setting-up-your-development-environment) + - [Making Changes](#making-changes) + - [Testing](#testing) + - [Submitting a Pull Request](#submitting-a-pull-request) +5. [Review Process](#review-process) +6. [Code Style](#code-style) +7. [License](#license) + +# Code of Conduct +This project adheres to the Contributor Covenant [code of conduct](CODE_OF_CONDUCT.md). +By participating, you are expected to uphold this code. +Please report unacceptable behavior to [hello@radixdlt.com](mailto:hello@radixdlt.com). + +# Reporting Issues +Ensure the bug was not already reported by searching on GitHub under [Issues](https://github.com/radixdlt/babylon-gateway/issues). + +If you encounter a bug or have a problem with the project, please open an issue on our [issue tracker](https://github.com/radixdlt/babylon-gateway/issues). Make sure to provide as much detail as possible, including: + +- A clear and descriptive title. +- Steps to reproduce the issue. +- Expected behavior and actual behavior. +- Your operating system, browser, or other relevant information. +- If possible, include screenshots or code snippets that illustrate the issue. + + +# Contributing Code + +Prior to commencing any work on a PR, we strongly advise initiating a discussion with the team via Discord, Telegram, or Github Issues (for bugs). + +Submitting a Pull Request does not guarantee the acceptance of your proposed changes. + +## Setting Up Your Development Environment + +Please check [documentation](https://github.com/radixdlt/babylon-gateway/blob/main/docs/development.md) on how to setup local environment. + +## Making Changes + +1. Write clear, concise, and well-documented code. +2. Commit your changes with a descriptive commit message. Please follow the PROJECT’s commit message format. + +## Testing + +1. Ensure that your changes do not break existing tests (`/tests` directory) +2. Write new tests for your code if applicable. +3. Run the test suite to make sure everything is passing (you can do that by using `dotnet test` command or any IDE of your choice) + +## Submitting a Pull Request + +1. Push your changes to your forked repository: +2. Open a pull request against the `develop` branch of the original repository. +3. Provide a clear and informative title and description for your pull request. +4. Be prepared to address any feedback or questions during the review process. + +# Review Process +Pull requests will be reviewed by project maintainers. Reviewers may provide feedback, request changes, or approve the pull request. We appreciate your patience during this process, and we aim to be responsive and constructive in our feedback. + + +# License +By contributing to Babylon Network Gateway, you agree that your contributions will be licensed under the Babylon Network Gateway license. + +The executable components of the Babylon Gateway Code are licensed under the [Radix Software EULA](http://www.radixdlt.com/terms/genericEULA). + +The Babylon Gateway Code is released under the [Radix License 1.0 (modified Apache 2.0)](LICENSE): + +``` +Copyright 2023 Radix Publishing Ltd incorporated in Jersey, Channel Islands. + +Licensed under the Radix License, Version 1.0 (the "License"); you may not use +this file except in compliance with the License. + +You may obtain a copy of the License at: +https://www.radixfoundation.org/licenses/license-v1 + +The Licensor hereby grants permission for the Canonical version of the Work to +be published, distributed and used under or by reference to the Licensor’s +trademark Radix® and use of any unregistered trade names, logos or get-up. + +The Licensor provides the Work (and each Contributor provides its Contributions) +on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either +express or implied, including, without limitation, any warranties or conditions +of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR +PURPOSE. + +Whilst the Work is capable of being deployed, used and adopted (instantiated) to +create a distributed ledger it is your responsibility to test and validate the +code, together with all logic and performance of that code under all foreseeable +scenarios. + +The Licensor does not make or purport to make and hereby excludes liability for +all and any representation, warranty or undertaking in any form whatsoever, +whether express or implied, to any entity or person, including any +representation, warranty or undertaking, as to the functionality security use, +value or other characteristics of any distributed ledger nor in respect the +functioning or value of any tokens which may be created stored or transferred +using the Work. + +The Licensor does not warrant that the Work or any use of the Work complies with +any law or regulation in any territory where it may be implemented or used or +that it will be appropriate for any specific purpose. + +Neither the licensor nor any current or former employees, officers, directors, +partners, trustees, representatives, agents, advisors, contractors, or +volunteers of the Licensor shall be liable for any direct or indirect, special, +incidental, consequential or other losses of any kind, in tort, contract or +otherwise (including but not limited to loss of revenue, income or profits, or +loss of use or data, or loss of reputation, or loss of any economic or other +opportunity of whatsoever nature or howsoever arising), arising out of or in +connection with (without limitation of any use, misuse, of any ledger system or +use made or its functionality or any performance or operation of any code or +protocol caused by bugs or programming or logic errors or otherwise); + +A. any offer, purchase, holding, use, sale, exchange or transmission of any +cryptographic keys, tokens or assets created, exchanged, stored or arising from +any interaction with the Work; + +B. any failure in a transmission or loss of any token or assets keys or other +digital artifacts due to errors in transmission; + +C. bugs, hacks, logic errors or faults in the Work or any communication; + +D. system software or apparatus including but not limited to losses caused by +errors in holding or transmitting tokens by any third-party; + +E. breaches or failure of security including hacker attacks, loss or disclosure +of password, loss of private key, unauthorised use or misuse of such passwords +or keys; + +F. any losses including loss of anticipated savings or other benefits resulting +from use of the Work or any changes to the Work (however implemented). + +You are solely responsible for; testing, validating and evaluation of all +operation logic, functionality, security and appropriateness of using the Work +for any commercial or non-commercial purpose and for any reproduction or +redistribution by You of the Work. You assume all risks associated with Your use +of the Work and the exercise of permissions under this Licence. +``` + diff --git a/Directory.Build.props b/Directory.Build.props index fe016103a..5a9fd1d36 100644 --- a/Directory.Build.props +++ b/Directory.Build.props @@ -13,7 +13,7 @@ - 1.3.0 + 1.4.0 develop diff --git a/Directory.Packages.props b/Directory.Packages.props index ac4c4dc08..37aca7db0 100644 --- a/Directory.Packages.props +++ b/Directory.Packages.props @@ -18,12 +18,13 @@ + - + @@ -34,4 +35,4 @@ - + \ No newline at end of file diff --git a/README.md b/README.md index 7dc939a3c..0d6f2abb7 100644 --- a/README.md +++ b/README.md @@ -7,8 +7,7 @@ This system is designed to be the Radix-run publicly exposed gateway into the Ba For documentation on the Gateway API, see the [Gateway API docs](https://docs-babylon.radixdlt.com/main/apis/api-specification.html). ## Community Involvement - -If you have questions, suggestions or bug reports, please come to the [Network Gateway channel](https://discord.com/channels/417762285172555786/1149370695206318151) on the [Radix DLT Discord server](http://discord.gg/radixdlt). +Please see [CONTRIBUTING.md](./CONTRIBUTING.md) ## Structure diff --git a/apps/DataAggregator/appsettings.Development.json b/apps/DataAggregator/appsettings.Development.json index f3fc0fbd4..b42774b96 100644 --- a/apps/DataAggregator/appsettings.Development.json +++ b/apps/DataAggregator/appsettings.Development.json @@ -19,13 +19,11 @@ { "Name": "node1", "CoreApiAddress": "http://localhost:3333", - "TrustWeighting": 1, "Enabled": true, }, { "Name": "node2", "CoreApiAddress": "http://localhost:3334", - "TrustWeighting": 1, "Enabled": false, }, ], diff --git a/apps/GatewayApi/Controllers/StateKeyValueStoreController.cs b/apps/GatewayApi/Controllers/StateKeyValueStoreController.cs index 1a0c8f26b..7e09a2201 100644 --- a/apps/GatewayApi/Controllers/StateKeyValueStoreController.cs +++ b/apps/GatewayApi/Controllers/StateKeyValueStoreController.cs @@ -81,6 +81,12 @@ public StateKeyValueStoreController(IKeyValueStoreHandler keyValueStoreHandler) _keyValueStoreHandler = keyValueStoreHandler; } + [HttpPost("keys")] + public async Task Items(GatewayModel.StateKeyValueStoreKeysRequest request, CancellationToken token) + { + return await _keyValueStoreHandler.Keys(request, token); + } + [HttpPost("data")] public async Task Data(GatewayModel.StateKeyValueStoreDataRequest request, CancellationToken token) { diff --git a/apps/GatewayApi/Controllers/StatusController.cs b/apps/GatewayApi/Controllers/StatusController.cs index d582428a4..02a231e2e 100644 --- a/apps/GatewayApi/Controllers/StatusController.cs +++ b/apps/GatewayApi/Controllers/StatusController.cs @@ -63,8 +63,8 @@ */ using Microsoft.AspNetCore.Mvc; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.GatewayApi.Handlers; -using RadixDlt.NetworkGateway.GatewayApi.Services; using System.Threading; using System.Threading.Tasks; using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; @@ -91,13 +91,14 @@ public StatusController(IStatusHandler statusHandler, INetworkConfigurationProvi } [HttpPost("network-configuration")] - public GatewayModel.NetworkConfigurationResponse NetworkConfiguration() + public async Task NetworkConfiguration(CancellationToken token) { - var wellKnownAddresses = _networkConfigurationProvider.GetWellKnownAddresses(); + var networkConfiguration = await _networkConfigurationProvider.GetNetworkConfiguration(token); + var wellKnownAddresses = networkConfiguration.WellKnownAddresses; return new GatewayModel.NetworkConfigurationResponse( - _networkConfigurationProvider.GetNetworkId(), - _networkConfigurationProvider.GetNetworkName(), + networkConfiguration.Id, + networkConfiguration.Name, new GatewayModel.NetworkConfigurationResponseWellKnownAddresses( xrd: wellKnownAddresses.Xrd, secp256k1SignatureVirtualBadge: wellKnownAddresses.Secp256k1SignatureVirtualBadge, @@ -118,7 +119,8 @@ public GatewayModel.NetworkConfigurationResponse NetworkConfiguration() transactionProcessorPackage: wellKnownAddresses.TransactionProcessorPackage, metadataModulePackage: wellKnownAddresses.MetadataModulePackage, royaltyModulePackage: wellKnownAddresses.RoyaltyModulePackage, - accessRulesPackage: wellKnownAddresses.AccessRulesPackage, + accessRulesPackage: wellKnownAddresses.RoleAssignmentModulePackage, + roleAssignmentModulePackage: wellKnownAddresses.RoleAssignmentModulePackage, genesisHelperPackage: wellKnownAddresses.GenesisHelperPackage, faucetPackage: wellKnownAddresses.FaucetPackage, consensusManager: wellKnownAddresses.ConsensusManager, diff --git a/apps/GatewayApi/OpenApiDocumentHandler.cs b/apps/GatewayApi/OpenApiDocumentHandler.cs index c17a079f0..5430ec03e 100644 --- a/apps/GatewayApi/OpenApiDocumentHandler.cs +++ b/apps/GatewayApi/OpenApiDocumentHandler.cs @@ -67,6 +67,7 @@ using Microsoft.OpenApi.Models; using Microsoft.OpenApi.Readers; using Microsoft.OpenApi.Writers; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.GatewayApi; using RadixDlt.NetworkGateway.GatewayApi.Handlers; using RadixDlt.NetworkGateway.GatewayApi.Services; @@ -171,14 +172,14 @@ private static async Task GetPlaceholderReplacements( CancellationToken token) { var placeholderReplacements = new PlaceholderReplacements(); + var networkConfiguration = await networkConfigurationProvider.GetNetworkConfiguration(token); try { - var wellKnownAddresses = networkConfigurationProvider.GetWellKnownAddresses(); - placeholderReplacements.ResourceAddress = wellKnownAddresses.Xrd; - placeholderReplacements.ComponentAddress = wellKnownAddresses.ConsensusManager; - placeholderReplacements.NetworkId = networkConfigurationProvider.GetNetworkId(); - placeholderReplacements.NetworkName = networkConfigurationProvider.GetNetworkName(); + placeholderReplacements.ResourceAddress = networkConfiguration.WellKnownAddresses.Xrd; + placeholderReplacements.ComponentAddress = networkConfiguration.WellKnownAddresses.ConsensusManager; + placeholderReplacements.NetworkId = networkConfiguration.Id; + placeholderReplacements.NetworkName = networkConfiguration.Name; } catch (Exception) { diff --git a/babylon-gateway.sln b/babylon-gateway.sln index 8f3759792..eb15cc446 100644 --- a/babylon-gateway.sln +++ b/babylon-gateway.sln @@ -21,6 +21,8 @@ Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = ".solution", ".solution", "{ .editorconfig = .editorconfig .gitignore = .gitignore CHANGELOG.md = CHANGELOG.md + CONTRIBUTING.md = CONTRIBUTING.md + CODE_OF_CONDUCT.md = CODE_OF_CONDUCT.md EndProjectSection EndProject Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "RadixDlt.NetworkGateway.DataAggregator", "src\RadixDlt.NetworkGateway.DataAggregator\RadixDlt.NetworkGateway.DataAggregator.csproj", "{6C516526-0AB0-41ED-8DA0-8CBC7751CBF7}" diff --git a/deployment/docker-compose.yml b/deployment/docker-compose.yml index b606121e5..29239d699 100644 --- a/deployment/docker-compose.yml +++ b/deployment/docker-compose.yml @@ -51,13 +51,13 @@ services: retries: 3 database_migrations: # This is the base -- the _image and _built containers are defined below - image: "radixdlt/babylon-ng-database-migrations:v1.3.0" + image: "radixdlt/babylon-ng-database-migrations:v1.4.0" profiles: ["NONE"] environment: ConnectionStrings__NetworkGatewayMigrations: "Host=postgres_db:5432;Database=${POSTGRES_DB_NAME};Username=${POSTGRES_SUPERUSER};Password=${POSTGRES_SUPERUSER_PASSWORD}" data_aggregator: # This is the base -- the _image and _built containers are defined below - image: "radixdlt/babylon-ng-data-aggregator:v1.3.0" + image: "radixdlt/babylon-ng-data-aggregator:v1.4.0" profiles: ["NONE"] deploy: restart_policy: @@ -76,33 +76,28 @@ services: DataAggregator__Network__CoreApiNodes__0__Name: "${NODE_0_NAME}" DataAggregator__Network__CoreApiNodes__0__CoreApiAddress: "${NODE_0_CORE_API_ADDRESS}" DataAggregator__Network__CoreApiNodes__0__CoreApiAuthorizationHeader: "${NODE_0_CORE_API_AUTHORIZATION_HEADER}" - DataAggregator__Network__CoreApiNodes__0__TrustWeighting: "1" DataAggregator__Network__CoreApiNodes__0__Enabled: "${NODE_0_ENABLED}" DataAggregator__Network__CoreApiNodes__1__Name: "${NODE_1_NAME}" DataAggregator__Network__CoreApiNodes__1__CoreApiAddress: "${NODE_1_CORE_API_ADDRESS}" DataAggregator__Network__CoreApiNodes__1__CoreApiAuthorizationHeader: "${NODE_1_CORE_API_AUTHORIZATION_HEADER}" - DataAggregator__Network__CoreApiNodes__1__TrustWeighting: "1" DataAggregator__Network__CoreApiNodes__1__Enabled: "${NODE_1_ENABLED}" DataAggregator__Network__CoreApiNodes__2__Name: "${NODE_2_NAME}" DataAggregator__Network__CoreApiNodes__2__CoreApiAddress: "${NODE_2_CORE_API_ADDRESS}" DataAggregator__Network__CoreApiNodes__2__CoreApiAuthorizationHeader: "${NODE_2_CORE_API_AUTHORIZATION_HEADER}" - DataAggregator__Network__CoreApiNodes__2__TrustWeighting: "1" DataAggregator__Network__CoreApiNodes__2__Enabled: "${NODE_2_ENABLED}" DataAggregator__Network__CoreApiNodes__3__Name: "${NODE_3_NAME}" DataAggregator__Network__CoreApiNodes__3__CoreApiAddress: "${NODE_3_CORE_API_ADDRESS}" DataAggregator__Network__CoreApiNodes__3__CoreApiAuthorizationHeader: "${NODE_3_CORE_API_AUTHORIZATION_HEADER}" - DataAggregator__Network__CoreApiNodes__3__TrustWeighting: "1" DataAggregator__Network__CoreApiNodes__3__Enabled: "${NODE_3_ENABLED}" DataAggregator__Network__CoreApiNodes__4__Name: "${NODE_4_NAME}" DataAggregator__Network__CoreApiNodes__4__CoreApiAddress: "${NODE_4_CORE_API_ADDRESS}" DataAggregator__Network__CoreApiNodes__4__CoreApiAuthorizationHeader: "${NODE_4_CORE_API_AUTHORIZATION_HEADER}" - DataAggregator__Network__CoreApiNodes__4__TrustWeighting: "1" DataAggregator__Network__CoreApiNodes__4__Enabled: "${NODE_4_ENABLED}" volumes: - ./data-aggregator-fixed-configuration.json:/home/radixdlt/network-gateway/config.json gateway_api: # This is the base -- the _image and _built containers are defined below - image: "radixdlt/babylon-ng-gateway-api:v1.3.0" + image: "radixdlt/babylon-ng-gateway-api:v1.4.0" profiles: ["NONE"] ports: - "127.0.0.1:5308:8080" # This allows you to connect to the API at http://localhost:5308 diff --git a/sdk/typescript/lib/generated/.openapi-generator/FILES b/sdk/typescript/lib/generated/.openapi-generator/FILES index eea31850b..a8d86617d 100644 --- a/sdk/typescript/lib/generated/.openapi-generator/FILES +++ b/sdk/typescript/lib/generated/.openapi-generator/FILES @@ -50,6 +50,7 @@ models/InvalidTransactionErrorAllOf.ts models/LedgerState.ts models/LedgerStateMixin.ts models/LedgerStateSelector.ts +models/ManifestClass.ts models/MetadataBoolArrayValue.ts models/MetadataBoolArrayValueAllOf.ts models/MetadataBoolValue.ts @@ -266,6 +267,12 @@ models/StateKeyValueStoreDataRequestKeyItem.ts models/StateKeyValueStoreDataResponse.ts models/StateKeyValueStoreDataResponseAllOf.ts models/StateKeyValueStoreDataResponseItem.ts +models/StateKeyValueStoreKeysCollection.ts +models/StateKeyValueStoreKeysCollectionAllOf.ts +models/StateKeyValueStoreKeysRequest.ts +models/StateKeyValueStoreKeysRequestAllOf.ts +models/StateKeyValueStoreKeysResponse.ts +models/StateKeyValueStoreKeysResponseItem.ts models/StateNonFungibleDataRequest.ts models/StateNonFungibleDataResponse.ts models/StateNonFungibleDataResponseAllOf.ts @@ -285,6 +292,7 @@ models/StateValidatorsListResponse.ts models/StateValidatorsListResponseAllOf.ts models/StreamTransactionsRequest.ts models/StreamTransactionsRequestAllOf.ts +models/StreamTransactionsRequestAllOfManifestClassFilter.ts models/StreamTransactionsRequestEventFilterItem.ts models/StreamTransactionsResponse.ts models/StreamTransactionsResponseAllOf.ts diff --git a/sdk/typescript/lib/generated/apis/StateApi.ts b/sdk/typescript/lib/generated/apis/StateApi.ts index 8bab0de46..b75054d50 100644 --- a/sdk/typescript/lib/generated/apis/StateApi.ts +++ b/sdk/typescript/lib/generated/apis/StateApi.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -32,6 +32,8 @@ import type { StateEntityNonFungiblesPageResponse, StateKeyValueStoreDataRequest, StateKeyValueStoreDataResponse, + StateKeyValueStoreKeysRequest, + StateKeyValueStoreKeysResponse, StateNonFungibleDataRequest, StateNonFungibleDataResponse, StateNonFungibleIdsRequest, @@ -76,6 +78,10 @@ import { StateKeyValueStoreDataRequestToJSON, StateKeyValueStoreDataResponseFromJSON, StateKeyValueStoreDataResponseToJSON, + StateKeyValueStoreKeysRequestFromJSON, + StateKeyValueStoreKeysRequestToJSON, + StateKeyValueStoreKeysResponseFromJSON, + StateKeyValueStoreKeysResponseToJSON, StateNonFungibleDataRequestFromJSON, StateNonFungibleDataRequestToJSON, StateNonFungibleDataResponseFromJSON, @@ -122,6 +128,10 @@ export interface KeyValueStoreDataRequest { stateKeyValueStoreDataRequest: StateKeyValueStoreDataRequest; } +export interface KeyValueStoreKeysRequest { + stateKeyValueStoreKeysRequest: StateKeyValueStoreKeysRequest; +} + export interface NonFungibleDataRequest { stateNonFungibleDataRequest: StateNonFungibleDataRequest; } @@ -392,6 +402,41 @@ export class StateApi extends runtime.BaseAPI { return await response.value(); } + /** + * Allows to iterate over key value store keys. + * Get KeyValueStore Keys + */ + async keyValueStoreKeysRaw(requestParameters: KeyValueStoreKeysRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise> { + if (requestParameters.stateKeyValueStoreKeysRequest === null || requestParameters.stateKeyValueStoreKeysRequest === undefined) { + throw new runtime.RequiredError('stateKeyValueStoreKeysRequest','Required parameter requestParameters.stateKeyValueStoreKeysRequest was null or undefined when calling keyValueStoreKeys.'); + } + + const queryParameters: any = {}; + + const headerParameters: runtime.HTTPHeaders = {}; + + headerParameters['Content-Type'] = 'application/json'; + + const response = await this.request({ + path: `/state/key-value-store/keys`, + method: 'POST', + headers: headerParameters, + query: queryParameters, + body: StateKeyValueStoreKeysRequestToJSON(requestParameters.stateKeyValueStoreKeysRequest), + }, initOverrides); + + return new runtime.JSONApiResponse(response, (jsonValue) => StateKeyValueStoreKeysResponseFromJSON(jsonValue)); + } + + /** + * Allows to iterate over key value store keys. + * Get KeyValueStore Keys + */ + async keyValueStoreKeys(requestParameters: KeyValueStoreKeysRequest, initOverrides?: RequestInit | runtime.InitOverrideFunction): Promise { + const response = await this.keyValueStoreKeysRaw(requestParameters, initOverrides); + return await response.value(); + } + /** * Returns data associated with a given non-fungible ID of a given non-fungible resource. * Get Non-Fungible Data diff --git a/sdk/typescript/lib/generated/apis/StatisticsApi.ts b/sdk/typescript/lib/generated/apis/StatisticsApi.ts index cb6f4effe..96454721d 100644 --- a/sdk/typescript/lib/generated/apis/StatisticsApi.ts +++ b/sdk/typescript/lib/generated/apis/StatisticsApi.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/apis/StatusApi.ts b/sdk/typescript/lib/generated/apis/StatusApi.ts index ca4a5f773..d6a1a8f78 100644 --- a/sdk/typescript/lib/generated/apis/StatusApi.ts +++ b/sdk/typescript/lib/generated/apis/StatusApi.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/apis/StreamApi.ts b/sdk/typescript/lib/generated/apis/StreamApi.ts index 840de27a1..690af8207 100644 --- a/sdk/typescript/lib/generated/apis/StreamApi.ts +++ b/sdk/typescript/lib/generated/apis/StreamApi.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/apis/TransactionApi.ts b/sdk/typescript/lib/generated/apis/TransactionApi.ts index 53dbfee87..5694dd559 100644 --- a/sdk/typescript/lib/generated/apis/TransactionApi.ts +++ b/sdk/typescript/lib/generated/apis/TransactionApi.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/AtLedgerStateMixin.ts b/sdk/typescript/lib/generated/models/AtLedgerStateMixin.ts index db3751f5c..8c33fdbe9 100644 --- a/sdk/typescript/lib/generated/models/AtLedgerStateMixin.ts +++ b/sdk/typescript/lib/generated/models/AtLedgerStateMixin.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/CommittedTransactionInfo.ts b/sdk/typescript/lib/generated/models/CommittedTransactionInfo.ts index 145415790..68b25dbf9 100644 --- a/sdk/typescript/lib/generated/models/CommittedTransactionInfo.ts +++ b/sdk/typescript/lib/generated/models/CommittedTransactionInfo.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -13,6 +13,12 @@ */ import { exists, mapValues } from '../runtime'; +import type { ManifestClass } from './ManifestClass'; +import { + ManifestClassFromJSON, + ManifestClassFromJSONTyped, + ManifestClassToJSON, +} from './ManifestClass'; import type { TransactionBalanceChanges } from './TransactionBalanceChanges'; import { TransactionBalanceChangesFromJSON, @@ -116,9 +122,26 @@ export interface CommittedTransactionInfo { * @memberof CommittedTransactionInfo */ receipt?: TransactionReceipt; + /** + * A text-representation of a transaction manifest. +This field will be present only for user transactions and when explicitly opted-in using `manifest_instructions` flag. + + * @type {string} + * @memberof CommittedTransactionInfo + */ + manifest_instructions?: string | null; + /** + * A collection of zero or more manifest classes ordered from the most specific class to the least specific one. +This field will be present only for user transactions. + + * @type {Array} + * @memberof CommittedTransactionInfo + */ + manifest_classes?: Array | null; /** * The optional transaction message. - * This type is defined in the Core API as `TransactionMessage`. See the Core API documentation for more details. +This type is defined in the Core API as `TransactionMessage`. See the Core API documentation for more details. + * @type {object} * @memberof CommittedTransactionInfo */ @@ -168,6 +191,8 @@ export function CommittedTransactionInfoFromJSONTyped(json: any, ignoreDiscrimin 'error_message': !exists(json, 'error_message') ? undefined : json['error_message'], 'raw_hex': !exists(json, 'raw_hex') ? undefined : json['raw_hex'], 'receipt': !exists(json, 'receipt') ? undefined : TransactionReceiptFromJSON(json['receipt']), + 'manifest_instructions': !exists(json, 'manifest_instructions') ? undefined : json['manifest_instructions'], + 'manifest_classes': !exists(json, 'manifest_classes') ? undefined : (json['manifest_classes'] === null ? null : (json['manifest_classes'] as Array).map(ManifestClassFromJSON)), 'message': !exists(json, 'message') ? undefined : json['message'], 'balance_changes': !exists(json, 'balance_changes') ? undefined : TransactionBalanceChangesFromJSON(json['balance_changes']), }; @@ -195,6 +220,8 @@ export function CommittedTransactionInfoToJSON(value?: CommittedTransactionInfo 'error_message': value.error_message, 'raw_hex': value.raw_hex, 'receipt': TransactionReceiptToJSON(value.receipt), + 'manifest_instructions': value.manifest_instructions, + 'manifest_classes': value.manifest_classes === undefined ? undefined : (value.manifest_classes === null ? null : (value.manifest_classes as Array).map(ManifestClassToJSON)), 'message': value.message, 'balance_changes': TransactionBalanceChangesToJSON(value.balance_changes), }; diff --git a/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignmentEntry.ts b/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignmentEntry.ts index e6424682e..d1ffca85d 100644 --- a/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignmentEntry.ts +++ b/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignmentEntry.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignmentEntryAssignment.ts b/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignmentEntryAssignment.ts index b501e4d4b..5ecc199e6 100644 --- a/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignmentEntryAssignment.ts +++ b/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignmentEntryAssignment.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -34,6 +34,7 @@ export interface ComponentEntityRoleAssignmentEntryAssignment { resolution: RoleAssignmentResolution; /** * This type is defined in the Core API as `AccessRule`. See the Core API documentation for more details. + * @type {object} * @memberof ComponentEntityRoleAssignmentEntryAssignment */ diff --git a/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignments.ts b/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignments.ts index 42b9e6306..5261d0aed 100644 --- a/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignments.ts +++ b/sdk/typescript/lib/generated/models/ComponentEntityRoleAssignments.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -28,6 +28,7 @@ import { export interface ComponentEntityRoleAssignments { /** * This type is defined in the Core API as `OwnerRole`. See the Core API documentation for more details. + * @type {object} * @memberof ComponentEntityRoleAssignments */ diff --git a/sdk/typescript/lib/generated/models/CursorLimitMixin.ts b/sdk/typescript/lib/generated/models/CursorLimitMixin.ts index c3bb8a6d4..077513628 100644 --- a/sdk/typescript/lib/generated/models/CursorLimitMixin.ts +++ b/sdk/typescript/lib/generated/models/CursorLimitMixin.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/EntityMetadataCollection.ts b/sdk/typescript/lib/generated/models/EntityMetadataCollection.ts index e5174913e..618d45066 100644 --- a/sdk/typescript/lib/generated/models/EntityMetadataCollection.ts +++ b/sdk/typescript/lib/generated/models/EntityMetadataCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/EntityMetadataCollectionAllOf.ts b/sdk/typescript/lib/generated/models/EntityMetadataCollectionAllOf.ts index a44ca11e5..09e7cc41f 100644 --- a/sdk/typescript/lib/generated/models/EntityMetadataCollectionAllOf.ts +++ b/sdk/typescript/lib/generated/models/EntityMetadataCollectionAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/EntityMetadataItem.ts b/sdk/typescript/lib/generated/models/EntityMetadataItem.ts index 5cd86a517..8275338df 100644 --- a/sdk/typescript/lib/generated/models/EntityMetadataItem.ts +++ b/sdk/typescript/lib/generated/models/EntityMetadataItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/EntityMetadataItemValue.ts b/sdk/typescript/lib/generated/models/EntityMetadataItemValue.ts index 57d4fd485..525268aac 100644 --- a/sdk/typescript/lib/generated/models/EntityMetadataItemValue.ts +++ b/sdk/typescript/lib/generated/models/EntityMetadataItemValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/EntityMetadataItemValueAllOf.ts b/sdk/typescript/lib/generated/models/EntityMetadataItemValueAllOf.ts index 9094088d3..83236bf1e 100644 --- a/sdk/typescript/lib/generated/models/EntityMetadataItemValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/EntityMetadataItemValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/EntityNotFoundError.ts b/sdk/typescript/lib/generated/models/EntityNotFoundError.ts index 24ad3d3c3..410c47b84 100644 --- a/sdk/typescript/lib/generated/models/EntityNotFoundError.ts +++ b/sdk/typescript/lib/generated/models/EntityNotFoundError.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/EntityNotFoundErrorAllOf.ts b/sdk/typescript/lib/generated/models/EntityNotFoundErrorAllOf.ts index 595386dce..f30a72411 100644 --- a/sdk/typescript/lib/generated/models/EntityNotFoundErrorAllOf.ts +++ b/sdk/typescript/lib/generated/models/EntityNotFoundErrorAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ErrorResponse.ts b/sdk/typescript/lib/generated/models/ErrorResponse.ts index 965e983df..6b13ae1a4 100644 --- a/sdk/typescript/lib/generated/models/ErrorResponse.ts +++ b/sdk/typescript/lib/generated/models/ErrorResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/EventsItem.ts b/sdk/typescript/lib/generated/models/EventsItem.ts index 893309fd8..836a78f80 100644 --- a/sdk/typescript/lib/generated/models/EventsItem.ts +++ b/sdk/typescript/lib/generated/models/EventsItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -34,6 +34,7 @@ export interface EventsItem { name: string; /** * This type is defined in the Core API as `EventEmitterIdentifier`. See the Core API documentation for more details. + * @type {object} * @memberof EventsItem */ diff --git a/sdk/typescript/lib/generated/models/FromLedgerStateMixin.ts b/sdk/typescript/lib/generated/models/FromLedgerStateMixin.ts index 73825032a..954fba6d2 100644 --- a/sdk/typescript/lib/generated/models/FromLedgerStateMixin.ts +++ b/sdk/typescript/lib/generated/models/FromLedgerStateMixin.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollection.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollection.ts index c7fce234e..810aa1d81 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollection.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionAllOf.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionAllOf.ts index 4d43f9ea9..6e94a32cd 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionAllOf.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItem.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItem.ts index 071a62c4f..1c404d18d 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItem.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemBase.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemBase.ts index ac53c67d2..1f0ff2400 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemBase.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemBase.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemGloballyAggregated.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemGloballyAggregated.ts index ab7bd709a..e27034a12 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemGloballyAggregated.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemGloballyAggregated.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemGloballyAggregatedAllOf.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemGloballyAggregatedAllOf.ts index 89633515b..8cc25d1e8 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemGloballyAggregatedAllOf.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemGloballyAggregatedAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregated.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregated.ts index e60d56f35..982ba3ab8 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregated.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregated.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedAllOf.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedAllOf.ts index f66b8bbd7..1f225f1ac 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedAllOf.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVault.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVault.ts index 75ac97dc0..ee8547d6a 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVault.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVault.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.ts index 81f9e2faa..fc277573c 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVaultItem.ts b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVaultItem.ts index b27b1adf2..59661f44d 100644 --- a/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVaultItem.ts +++ b/sdk/typescript/lib/generated/models/FungibleResourcesCollectionItemVaultAggregatedVaultItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/GatewayError.ts b/sdk/typescript/lib/generated/models/GatewayError.ts index dc702c78d..c55d7ddd9 100644 --- a/sdk/typescript/lib/generated/models/GatewayError.ts +++ b/sdk/typescript/lib/generated/models/GatewayError.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/GatewayErrorBase.ts b/sdk/typescript/lib/generated/models/GatewayErrorBase.ts index 618d1d98b..23721ad14 100644 --- a/sdk/typescript/lib/generated/models/GatewayErrorBase.ts +++ b/sdk/typescript/lib/generated/models/GatewayErrorBase.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/GatewayInfoResponseKnownTarget.ts b/sdk/typescript/lib/generated/models/GatewayInfoResponseKnownTarget.ts index 9cb7e590b..e3c6857f1 100644 --- a/sdk/typescript/lib/generated/models/GatewayInfoResponseKnownTarget.ts +++ b/sdk/typescript/lib/generated/models/GatewayInfoResponseKnownTarget.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -21,6 +21,7 @@ import { exists, mapValues } from '../runtime'; export interface GatewayInfoResponseKnownTarget { /** * The latest-seen state version of the tip of the network's ledger. If this is significantly ahead of the current ledger state version, the Network Gateway is possibly behind and may be reporting outdated information. + * @type {number} * @memberof GatewayInfoResponseKnownTarget */ diff --git a/sdk/typescript/lib/generated/models/GatewayInfoResponseReleaseInfo.ts b/sdk/typescript/lib/generated/models/GatewayInfoResponseReleaseInfo.ts index 9ab1c9da0..1df886019 100644 --- a/sdk/typescript/lib/generated/models/GatewayInfoResponseReleaseInfo.ts +++ b/sdk/typescript/lib/generated/models/GatewayInfoResponseReleaseInfo.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/GatewayStatusResponse.ts b/sdk/typescript/lib/generated/models/GatewayStatusResponse.ts index f1b142860..fce300070 100644 --- a/sdk/typescript/lib/generated/models/GatewayStatusResponse.ts +++ b/sdk/typescript/lib/generated/models/GatewayStatusResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/GatewayStatusResponseAllOf.ts b/sdk/typescript/lib/generated/models/GatewayStatusResponseAllOf.ts index 93d2c0585..6a31349c2 100644 --- a/sdk/typescript/lib/generated/models/GatewayStatusResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/GatewayStatusResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/InternalServerError.ts b/sdk/typescript/lib/generated/models/InternalServerError.ts index ed3af9287..821b13d9e 100644 --- a/sdk/typescript/lib/generated/models/InternalServerError.ts +++ b/sdk/typescript/lib/generated/models/InternalServerError.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/InternalServerErrorAllOf.ts b/sdk/typescript/lib/generated/models/InternalServerErrorAllOf.ts index 42d321a4b..d7693078c 100644 --- a/sdk/typescript/lib/generated/models/InternalServerErrorAllOf.ts +++ b/sdk/typescript/lib/generated/models/InternalServerErrorAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/InvalidEntityError.ts b/sdk/typescript/lib/generated/models/InvalidEntityError.ts index 6b2f7d55d..e11ac39fa 100644 --- a/sdk/typescript/lib/generated/models/InvalidEntityError.ts +++ b/sdk/typescript/lib/generated/models/InvalidEntityError.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/InvalidEntityErrorAllOf.ts b/sdk/typescript/lib/generated/models/InvalidEntityErrorAllOf.ts index 40c379698..cc5a993ea 100644 --- a/sdk/typescript/lib/generated/models/InvalidEntityErrorAllOf.ts +++ b/sdk/typescript/lib/generated/models/InvalidEntityErrorAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/InvalidRequestError.ts b/sdk/typescript/lib/generated/models/InvalidRequestError.ts index 4390d84dd..bdb7f07ff 100644 --- a/sdk/typescript/lib/generated/models/InvalidRequestError.ts +++ b/sdk/typescript/lib/generated/models/InvalidRequestError.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/InvalidRequestErrorAllOf.ts b/sdk/typescript/lib/generated/models/InvalidRequestErrorAllOf.ts index 192f4c7a3..1e6ffc45a 100644 --- a/sdk/typescript/lib/generated/models/InvalidRequestErrorAllOf.ts +++ b/sdk/typescript/lib/generated/models/InvalidRequestErrorAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/InvalidTransactionError.ts b/sdk/typescript/lib/generated/models/InvalidTransactionError.ts index 992dce601..4127cff5b 100644 --- a/sdk/typescript/lib/generated/models/InvalidTransactionError.ts +++ b/sdk/typescript/lib/generated/models/InvalidTransactionError.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/InvalidTransactionErrorAllOf.ts b/sdk/typescript/lib/generated/models/InvalidTransactionErrorAllOf.ts index 4a48c2c9a..91008675d 100644 --- a/sdk/typescript/lib/generated/models/InvalidTransactionErrorAllOf.ts +++ b/sdk/typescript/lib/generated/models/InvalidTransactionErrorAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/LedgerState.ts b/sdk/typescript/lib/generated/models/LedgerState.ts index 625582622..1f3486a9f 100644 --- a/sdk/typescript/lib/generated/models/LedgerState.ts +++ b/sdk/typescript/lib/generated/models/LedgerState.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -15,7 +15,8 @@ import { exists, mapValues } from '../runtime'; /** * The ledger state against which the response was generated. - * Can be used to detect if the Network Gateway is returning up-to-date information. +Can be used to detect if the Network Gateway is returning up-to-date information. + * @export * @interface LedgerState */ @@ -34,9 +35,10 @@ export interface LedgerState { state_version: number; /** * The proposer round timestamp of the consensus round when this transaction was committed to ledger. - * This is not guaranteed to be strictly increasing, as it is computed as an average across the validator set. - * If this is significantly behind the current timestamp, the Network Gateway is likely reporting out-dated - * information, or the network has stalled. +This is not guaranteed to be strictly increasing, as it is computed as an average across the validator set. +If this is significantly behind the current timestamp, the Network Gateway is likely reporting out-dated +information, or the network has stalled. + * @type {string} * @memberof LedgerState */ diff --git a/sdk/typescript/lib/generated/models/LedgerStateMixin.ts b/sdk/typescript/lib/generated/models/LedgerStateMixin.ts index b0fcb6032..301458950 100644 --- a/sdk/typescript/lib/generated/models/LedgerStateMixin.ts +++ b/sdk/typescript/lib/generated/models/LedgerStateMixin.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/LedgerStateSelector.ts b/sdk/typescript/lib/generated/models/LedgerStateSelector.ts index db8e98a51..96f7d5333 100644 --- a/sdk/typescript/lib/generated/models/LedgerStateSelector.ts +++ b/sdk/typescript/lib/generated/models/LedgerStateSelector.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -15,8 +15,9 @@ import { exists, mapValues } from '../runtime'; /** * Optional. This allows for a request to be made against a historic state. - * If a constraint is specified, the Gateway will resolve the request against the ledger state at that time. - * If not specified, requests will be made with respect to the top of the committed ledger. +If a constraint is specified, the Gateway will resolve the request against the ledger state at that time. +If not specified, requests will be made with respect to the top of the committed ledger. + * @export * @interface LedgerStateSelector */ diff --git a/sdk/typescript/lib/generated/models/ManifestClass.ts b/sdk/typescript/lib/generated/models/ManifestClass.ts new file mode 100644 index 000000000..14d38235d --- /dev/null +++ b/sdk/typescript/lib/generated/models/ManifestClass.ts @@ -0,0 +1,53 @@ +/* tslint:disable */ +/* eslint-disable */ +/** + * Radix Gateway API - Babylon + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ + + +/** + * High-level manifest class type: + * `General`: A general manifest that involves any amount of arbitrary components and packages where nothing more concrete can be said about the manifest and its nature. + * `Transfer`: A manifest of a 1-to-1 transfer to a one-to-many transfer of resources. + * `PoolContribution`: A manifest that contributed some amount of resources to a liquidity pool that can be a one-resource pool, two-resource pool, or a multi-resource pool. + * `PoolRedemption`: A manifest that redeemed resources from a liquidity pool. Similar to contributions, this can be any of the three pool blueprints available in the pool package. + * `ValidatorStake`: A manifest where XRD is staked to one or more validators. + * `ValidatorUnstake`: A manifest where XRD is unstaked from one or more validators. + * `ValidatorClaim`: A manifest where XRD is claimed from one or more validators. + * `AccountDepositSettingsUpdate`: A manifest that updated the deposit settings of the account. + + * @export + */ +export const ManifestClass = { + General: 'General', + Transfer: 'Transfer', + PoolContribution: 'PoolContribution', + PoolRedemption: 'PoolRedemption', + ValidatorStake: 'ValidatorStake', + ValidatorUnstake: 'ValidatorUnstake', + ValidatorClaim: 'ValidatorClaim', + AccountDepositSettingsUpdate: 'AccountDepositSettingsUpdate' +} as const; +export type ManifestClass = typeof ManifestClass[keyof typeof ManifestClass]; + + +export function ManifestClassFromJSON(json: any): ManifestClass { + return ManifestClassFromJSONTyped(json, false); +} + +export function ManifestClassFromJSONTyped(json: any, ignoreDiscriminator: boolean): ManifestClass { + return json as ManifestClass; +} + +export function ManifestClassToJSON(value?: ManifestClass | null): any { + return value as any; +} + diff --git a/sdk/typescript/lib/generated/models/MetadataBoolArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataBoolArrayValue.ts index 24a39deab..a939b8009 100644 --- a/sdk/typescript/lib/generated/models/MetadataBoolArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataBoolArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataBoolArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataBoolArrayValueAllOf.ts index 33a5c56a4..4bb3328d3 100644 --- a/sdk/typescript/lib/generated/models/MetadataBoolArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataBoolArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataBoolValue.ts b/sdk/typescript/lib/generated/models/MetadataBoolValue.ts index 9cd362bd9..a9e2530d3 100644 --- a/sdk/typescript/lib/generated/models/MetadataBoolValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataBoolValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataBoolValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataBoolValueAllOf.ts index b1c09d40a..85402d89d 100644 --- a/sdk/typescript/lib/generated/models/MetadataBoolValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataBoolValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataDecimalArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataDecimalArrayValue.ts index 145a4439b..ddd4a1869 100644 --- a/sdk/typescript/lib/generated/models/MetadataDecimalArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataDecimalArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataDecimalArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataDecimalArrayValueAllOf.ts index 66045d8e7..c85a89e1d 100644 --- a/sdk/typescript/lib/generated/models/MetadataDecimalArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataDecimalArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataDecimalValue.ts b/sdk/typescript/lib/generated/models/MetadataDecimalValue.ts index 7a303201e..ec22d7920 100644 --- a/sdk/typescript/lib/generated/models/MetadataDecimalValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataDecimalValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataDecimalValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataDecimalValueAllOf.ts index 97a96777b..7ccdcd175 100644 --- a/sdk/typescript/lib/generated/models/MetadataDecimalValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataDecimalValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataGlobalAddressArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataGlobalAddressArrayValue.ts index 73508690b..0912a808e 100644 --- a/sdk/typescript/lib/generated/models/MetadataGlobalAddressArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataGlobalAddressArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataGlobalAddressArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataGlobalAddressArrayValueAllOf.ts index 1cc996c94..0b8fa3214 100644 --- a/sdk/typescript/lib/generated/models/MetadataGlobalAddressArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataGlobalAddressArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataGlobalAddressValue.ts b/sdk/typescript/lib/generated/models/MetadataGlobalAddressValue.ts index cf7e9ae54..550ffa273 100644 --- a/sdk/typescript/lib/generated/models/MetadataGlobalAddressValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataGlobalAddressValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataGlobalAddressValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataGlobalAddressValueAllOf.ts index 286caa41c..fa51fbc8c 100644 --- a/sdk/typescript/lib/generated/models/MetadataGlobalAddressValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataGlobalAddressValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataI32ArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataI32ArrayValue.ts index 10ffc7c5a..edf6a050e 100644 --- a/sdk/typescript/lib/generated/models/MetadataI32ArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataI32ArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataI32ArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataI32ArrayValueAllOf.ts index cf9976a1a..89da864f5 100644 --- a/sdk/typescript/lib/generated/models/MetadataI32ArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataI32ArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataI32Value.ts b/sdk/typescript/lib/generated/models/MetadataI32Value.ts index c6175cc0f..eaf77da98 100644 --- a/sdk/typescript/lib/generated/models/MetadataI32Value.ts +++ b/sdk/typescript/lib/generated/models/MetadataI32Value.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataI32ValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataI32ValueAllOf.ts index 72e90fb53..f55e18e26 100644 --- a/sdk/typescript/lib/generated/models/MetadataI32ValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataI32ValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataI64ArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataI64ArrayValue.ts index 816d08ef4..4f8781c97 100644 --- a/sdk/typescript/lib/generated/models/MetadataI64ArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataI64ArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataI64ArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataI64ArrayValueAllOf.ts index 3f576e1b5..9b065c076 100644 --- a/sdk/typescript/lib/generated/models/MetadataI64ArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataI64ArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataI64Value.ts b/sdk/typescript/lib/generated/models/MetadataI64Value.ts index daa039587..9ba8af9f2 100644 --- a/sdk/typescript/lib/generated/models/MetadataI64Value.ts +++ b/sdk/typescript/lib/generated/models/MetadataI64Value.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataI64ValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataI64ValueAllOf.ts index c7c35c1e6..5bd669975 100644 --- a/sdk/typescript/lib/generated/models/MetadataI64ValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataI64ValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataInstantArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataInstantArrayValue.ts index ff656786b..f80a1f74a 100644 --- a/sdk/typescript/lib/generated/models/MetadataInstantArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataInstantArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataInstantArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataInstantArrayValueAllOf.ts index 3bfe893af..ff3d1f44a 100644 --- a/sdk/typescript/lib/generated/models/MetadataInstantArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataInstantArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataInstantValue.ts b/sdk/typescript/lib/generated/models/MetadataInstantValue.ts index 7d7d6a6c2..d65c990ee 100644 --- a/sdk/typescript/lib/generated/models/MetadataInstantValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataInstantValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataInstantValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataInstantValueAllOf.ts index 8b7f507e6..c16acbdfe 100644 --- a/sdk/typescript/lib/generated/models/MetadataInstantValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataInstantValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValue.ts index a7acabd88..f743f9891 100644 --- a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValueAllOf.ts index 4121462ec..a2d4e74e5 100644 --- a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValueAllOfValues.ts b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValueAllOfValues.ts index 4b9964cdb..4f50956f3 100644 --- a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValueAllOfValues.ts +++ b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdArrayValueAllOfValues.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdValue.ts b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdValue.ts index a1994a141..e50225e02 100644 --- a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdValueAllOf.ts index f85c662f1..bd9ab255a 100644 --- a/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataNonFungibleGlobalIdValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdArrayValue.ts index ba5378949..8adb9fb73 100644 --- a/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdArrayValueAllOf.ts index cf24ff375..ab26d4dc0 100644 --- a/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdValue.ts b/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdValue.ts index 697a6c5e6..e3337c2a5 100644 --- a/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdValueAllOf.ts index 14cc0b30e..8e5dc77be 100644 --- a/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataNonFungibleLocalIdValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataOriginArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataOriginArrayValue.ts index 44d6188e3..74d012c34 100644 --- a/sdk/typescript/lib/generated/models/MetadataOriginArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataOriginArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataOriginArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataOriginArrayValueAllOf.ts index 9fd5794fe..c05823b0c 100644 --- a/sdk/typescript/lib/generated/models/MetadataOriginArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataOriginArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataOriginValue.ts b/sdk/typescript/lib/generated/models/MetadataOriginValue.ts index 88b6c72fa..6792c8b45 100644 --- a/sdk/typescript/lib/generated/models/MetadataOriginValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataOriginValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataOriginValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataOriginValueAllOf.ts index efe66c8b7..2c87644f1 100644 --- a/sdk/typescript/lib/generated/models/MetadataOriginValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataOriginValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataPublicKeyArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataPublicKeyArrayValue.ts index 149f3f291..6948eda53 100644 --- a/sdk/typescript/lib/generated/models/MetadataPublicKeyArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataPublicKeyArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataPublicKeyArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataPublicKeyArrayValueAllOf.ts index 186dbd933..986c42029 100644 --- a/sdk/typescript/lib/generated/models/MetadataPublicKeyArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataPublicKeyArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataPublicKeyHashArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataPublicKeyHashArrayValue.ts index c933d761b..8dba1fb7f 100644 --- a/sdk/typescript/lib/generated/models/MetadataPublicKeyHashArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataPublicKeyHashArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataPublicKeyHashArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataPublicKeyHashArrayValueAllOf.ts index 19fd3ca84..d26509581 100644 --- a/sdk/typescript/lib/generated/models/MetadataPublicKeyHashArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataPublicKeyHashArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataPublicKeyHashValue.ts b/sdk/typescript/lib/generated/models/MetadataPublicKeyHashValue.ts index db1659fc8..0a60b656a 100644 --- a/sdk/typescript/lib/generated/models/MetadataPublicKeyHashValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataPublicKeyHashValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataPublicKeyHashValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataPublicKeyHashValueAllOf.ts index 1c7aaa966..a6e978de6 100644 --- a/sdk/typescript/lib/generated/models/MetadataPublicKeyHashValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataPublicKeyHashValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataPublicKeyValue.ts b/sdk/typescript/lib/generated/models/MetadataPublicKeyValue.ts index 790f668ea..264948c8d 100644 --- a/sdk/typescript/lib/generated/models/MetadataPublicKeyValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataPublicKeyValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataPublicKeyValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataPublicKeyValueAllOf.ts index 3aacef572..6c619c27e 100644 --- a/sdk/typescript/lib/generated/models/MetadataPublicKeyValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataPublicKeyValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataStringArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataStringArrayValue.ts index c6ee7d440..edba98bc9 100644 --- a/sdk/typescript/lib/generated/models/MetadataStringArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataStringArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataStringArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataStringArrayValueAllOf.ts index 5de5aa196..b139e282e 100644 --- a/sdk/typescript/lib/generated/models/MetadataStringArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataStringArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataStringValue.ts b/sdk/typescript/lib/generated/models/MetadataStringValue.ts index b4d676fc8..5134b3fa8 100644 --- a/sdk/typescript/lib/generated/models/MetadataStringValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataStringValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataStringValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataStringValueAllOf.ts index 8b61034cb..066518ff6 100644 --- a/sdk/typescript/lib/generated/models/MetadataStringValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataStringValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataTypedValue.ts b/sdk/typescript/lib/generated/models/MetadataTypedValue.ts index a38e0f464..aa4d08fb8 100644 --- a/sdk/typescript/lib/generated/models/MetadataTypedValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataTypedValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataTypedValueBase.ts b/sdk/typescript/lib/generated/models/MetadataTypedValueBase.ts index 95d4a9175..6b3634946 100644 --- a/sdk/typescript/lib/generated/models/MetadataTypedValueBase.ts +++ b/sdk/typescript/lib/generated/models/MetadataTypedValueBase.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU32ArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataU32ArrayValue.ts index daad698fb..dcefea0fc 100644 --- a/sdk/typescript/lib/generated/models/MetadataU32ArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataU32ArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU32ArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataU32ArrayValueAllOf.ts index 1cee2cd9c..cd48a0142 100644 --- a/sdk/typescript/lib/generated/models/MetadataU32ArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataU32ArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU32Value.ts b/sdk/typescript/lib/generated/models/MetadataU32Value.ts index 7bb4cb8f3..421609aec 100644 --- a/sdk/typescript/lib/generated/models/MetadataU32Value.ts +++ b/sdk/typescript/lib/generated/models/MetadataU32Value.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU32ValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataU32ValueAllOf.ts index dcf46f9de..e223166ea 100644 --- a/sdk/typescript/lib/generated/models/MetadataU32ValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataU32ValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU64ArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataU64ArrayValue.ts index 9535ecbb7..ff2ce9e6b 100644 --- a/sdk/typescript/lib/generated/models/MetadataU64ArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataU64ArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU64ArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataU64ArrayValueAllOf.ts index 8bbb54f4d..225b75833 100644 --- a/sdk/typescript/lib/generated/models/MetadataU64ArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataU64ArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU64Value.ts b/sdk/typescript/lib/generated/models/MetadataU64Value.ts index dfc2e459d..359e96500 100644 --- a/sdk/typescript/lib/generated/models/MetadataU64Value.ts +++ b/sdk/typescript/lib/generated/models/MetadataU64Value.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU64ValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataU64ValueAllOf.ts index 04c91dac3..0f8d15c85 100644 --- a/sdk/typescript/lib/generated/models/MetadataU64ValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataU64ValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU8ArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataU8ArrayValue.ts index 68c2272d1..58da9ab3d 100644 --- a/sdk/typescript/lib/generated/models/MetadataU8ArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataU8ArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU8ArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataU8ArrayValueAllOf.ts index 804fc5fc7..dc23c6bef 100644 --- a/sdk/typescript/lib/generated/models/MetadataU8ArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataU8ArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU8Value.ts b/sdk/typescript/lib/generated/models/MetadataU8Value.ts index 52b14c626..99724e366 100644 --- a/sdk/typescript/lib/generated/models/MetadataU8Value.ts +++ b/sdk/typescript/lib/generated/models/MetadataU8Value.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataU8ValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataU8ValueAllOf.ts index 8eb24743d..49f0dde1c 100644 --- a/sdk/typescript/lib/generated/models/MetadataU8ValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataU8ValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataUrlArrayValue.ts b/sdk/typescript/lib/generated/models/MetadataUrlArrayValue.ts index 7ecc9d409..d8979a31a 100644 --- a/sdk/typescript/lib/generated/models/MetadataUrlArrayValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataUrlArrayValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataUrlArrayValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataUrlArrayValueAllOf.ts index a7e674c55..2e22b65c5 100644 --- a/sdk/typescript/lib/generated/models/MetadataUrlArrayValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataUrlArrayValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataUrlValue.ts b/sdk/typescript/lib/generated/models/MetadataUrlValue.ts index 375053b73..ba44fead9 100644 --- a/sdk/typescript/lib/generated/models/MetadataUrlValue.ts +++ b/sdk/typescript/lib/generated/models/MetadataUrlValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataUrlValueAllOf.ts b/sdk/typescript/lib/generated/models/MetadataUrlValueAllOf.ts index 528d61c07..ec0ca06a8 100644 --- a/sdk/typescript/lib/generated/models/MetadataUrlValueAllOf.ts +++ b/sdk/typescript/lib/generated/models/MetadataUrlValueAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/MetadataValueType.ts b/sdk/typescript/lib/generated/models/MetadataValueType.ts index 04b70e48f..5eabc0737 100644 --- a/sdk/typescript/lib/generated/models/MetadataValueType.ts +++ b/sdk/typescript/lib/generated/models/MetadataValueType.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NetworkConfigurationResponse.ts b/sdk/typescript/lib/generated/models/NetworkConfigurationResponse.ts index 4d8e1862b..44cbd01ed 100644 --- a/sdk/typescript/lib/generated/models/NetworkConfigurationResponse.ts +++ b/sdk/typescript/lib/generated/models/NetworkConfigurationResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NetworkConfigurationResponseWellKnownAddresses.ts b/sdk/typescript/lib/generated/models/NetworkConfigurationResponseWellKnownAddresses.ts index f7ce3c2d3..3c9fcb464 100644 --- a/sdk/typescript/lib/generated/models/NetworkConfigurationResponseWellKnownAddresses.ts +++ b/sdk/typescript/lib/generated/models/NetworkConfigurationResponseWellKnownAddresses.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -139,6 +139,12 @@ export interface NetworkConfigurationResponseWellKnownAddresses { * @memberof NetworkConfigurationResponseWellKnownAddresses */ access_rules_package: string; + /** + * Bech32m-encoded human readable version of the address. + * @type {string} + * @memberof NetworkConfigurationResponseWellKnownAddresses + */ + role_assignment_module_package: string; /** * Bech32m-encoded human readable version of the address. * @type {string} @@ -208,6 +214,7 @@ export function instanceOfNetworkConfigurationResponseWellKnownAddresses(value: isInstance = isInstance && "metadata_module_package" in value; isInstance = isInstance && "royalty_module_package" in value; isInstance = isInstance && "access_rules_package" in value; + isInstance = isInstance && "role_assignment_module_package" in value; isInstance = isInstance && "genesis_helper_package" in value; isInstance = isInstance && "faucet_package" in value; isInstance = isInstance && "consensus_manager" in value; @@ -249,6 +256,7 @@ export function NetworkConfigurationResponseWellKnownAddressesFromJSONTyped(json 'metadata_module_package': json['metadata_module_package'], 'royalty_module_package': json['royalty_module_package'], 'access_rules_package': json['access_rules_package'], + 'role_assignment_module_package': json['role_assignment_module_package'], 'genesis_helper_package': json['genesis_helper_package'], 'faucet_package': json['faucet_package'], 'consensus_manager': json['consensus_manager'], @@ -288,6 +296,7 @@ export function NetworkConfigurationResponseWellKnownAddressesToJSON(value?: Net 'metadata_module_package': value.metadata_module_package, 'royalty_module_package': value.royalty_module_package, 'access_rules_package': value.access_rules_package, + 'role_assignment_module_package': value.role_assignment_module_package, 'genesis_helper_package': value.genesis_helper_package, 'faucet_package': value.faucet_package, 'consensus_manager': value.consensus_manager, diff --git a/sdk/typescript/lib/generated/models/NonFungibleIdType.ts b/sdk/typescript/lib/generated/models/NonFungibleIdType.ts index 3aca28cc5..5e91e1b3a 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleIdType.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleIdType.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleIdsCollection.ts b/sdk/typescript/lib/generated/models/NonFungibleIdsCollection.ts index bac45ecb3..852cf5ccf 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleIdsCollection.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleIdsCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleIdsCollectionAllOf.ts b/sdk/typescript/lib/generated/models/NonFungibleIdsCollectionAllOf.ts index b99f878e1..84c5b1528 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleIdsCollectionAllOf.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleIdsCollectionAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollection.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollection.ts index e8f5786c9..90981967c 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollection.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionAllOf.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionAllOf.ts index afc76b999..7aca4de7f 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionAllOf.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItem.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItem.ts index e3daffd93..6aa75ee43 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItem.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemBase.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemBase.ts index 856cdf734..899ee4d7b 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemBase.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemBase.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemGloballyAggregated.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemGloballyAggregated.ts index 50fbdefa8..a7307c27a 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemGloballyAggregated.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemGloballyAggregated.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.ts index c06f9d04b..7fe84973f 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregated.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregated.ts index 57cdf8f38..cb0e45908 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregated.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregated.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.ts index ecd0408e0..16dd3654f 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVault.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVault.ts index 1a718f911..0e4968996 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVault.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVault.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.ts index 0d76e7806..a27053271 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.ts index 38d3815b9..6cf58e2d5 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.ts b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.ts index bd7e8f94b..f94718e51 100644 --- a/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.ts +++ b/sdk/typescript/lib/generated/models/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NotSyncedUpError.ts b/sdk/typescript/lib/generated/models/NotSyncedUpError.ts index 0aaa92bf2..d16fae9ae 100644 --- a/sdk/typescript/lib/generated/models/NotSyncedUpError.ts +++ b/sdk/typescript/lib/generated/models/NotSyncedUpError.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/NotSyncedUpErrorAllOf.ts b/sdk/typescript/lib/generated/models/NotSyncedUpErrorAllOf.ts index ef20369e6..16a5642fd 100644 --- a/sdk/typescript/lib/generated/models/NotSyncedUpErrorAllOf.ts +++ b/sdk/typescript/lib/generated/models/NotSyncedUpErrorAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ObjectModuleId.ts b/sdk/typescript/lib/generated/models/ObjectModuleId.ts index e53b6093b..68ca7e581 100644 --- a/sdk/typescript/lib/generated/models/ObjectModuleId.ts +++ b/sdk/typescript/lib/generated/models/ObjectModuleId.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/OptionalNonFungibleIdsCollection.ts b/sdk/typescript/lib/generated/models/OptionalNonFungibleIdsCollection.ts index fa2967ac4..e1768edb0 100644 --- a/sdk/typescript/lib/generated/models/OptionalNonFungibleIdsCollection.ts +++ b/sdk/typescript/lib/generated/models/OptionalNonFungibleIdsCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/OptionalNonFungibleIdsCollectionAllOf.ts b/sdk/typescript/lib/generated/models/OptionalNonFungibleIdsCollectionAllOf.ts index 4e198b044..389bbac9c 100644 --- a/sdk/typescript/lib/generated/models/OptionalNonFungibleIdsCollectionAllOf.ts +++ b/sdk/typescript/lib/generated/models/OptionalNonFungibleIdsCollectionAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PackageCodeCollectionItem.ts b/sdk/typescript/lib/generated/models/PackageCodeCollectionItem.ts index db794323c..d02566366 100644 --- a/sdk/typescript/lib/generated/models/PackageCodeCollectionItem.ts +++ b/sdk/typescript/lib/generated/models/PackageCodeCollectionItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PackageVmType.ts b/sdk/typescript/lib/generated/models/PackageVmType.ts index 3f0288d17..7a4a6ff3d 100644 --- a/sdk/typescript/lib/generated/models/PackageVmType.ts +++ b/sdk/typescript/lib/generated/models/PackageVmType.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValue.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValue.ts index 7f60b2aa2..c60b9de60 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValue.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueArray.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueArray.ts index bbb7e67ae..acdbd3990 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueArray.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueArray.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueArrayAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueArrayAllOf.ts index 6a71c2ac0..9f6a08062 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueArrayAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueArrayAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBase.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBase.ts index 2034b3815..f5d5b38f3 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBase.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBase.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -22,36 +22,37 @@ import { /** * Arbitrary SBOR value represented as programmatic JSON with optional property name annotations. - * - * All scalar types (`Bool`, `I*`, `U*`, `String`, `Reference`, `Own`, `Decimal`, `PreciseDecimal`, `NonFungibleLocalId`) - * convey their value via `value` string property with notable exception of `Bool` type that uses regular JSON boolean type. - * Numeric values as string-encoded to preserve accuracy and simplify implementation on platforms with no native support - * for 64-bit long numerical values. - * - * Common properties represented as nullable strings: - * * `type_name` is only output when a schema is present and the type has a name, - * * `field_name` is only output when the value is a child of a `Tuple` or `Enum`, which has a type with named fields, - * * `variant_name` is only output when a schema is present and the type is an `Enum`. - * - * The following is a non-normative example annotated `Tuple` value with `String` and `U32` fields: - * ``` - * { - * "kind": "Tuple", - * "type_name": "CustomStructure", - * "fields": [ - * { - * "kind": "String", - * "field_name": "favorite_color", - * "value": "Blue" - * }, - * { - * "kind": "U32", - * "field_name": "usage_counter", - * "value": "462231" - * } - * ] - * } - * ``` + +All scalar types (`Bool`, `I*`, `U*`, `String`, `Reference`, `Own`, `Decimal`, `PreciseDecimal`, `NonFungibleLocalId`) +convey their value via `value` string property with notable exception of `Bool` type that uses regular JSON boolean type. +Numeric values as string-encoded to preserve accuracy and simplify implementation on platforms with no native support +for 64-bit long numerical values. + +Common properties represented as nullable strings: + * `type_name` is only output when a schema is present and the type has a name, + * `field_name` is only output when the value is a child of a `Tuple` or `Enum`, which has a type with named fields, + * `variant_name` is only output when a schema is present and the type is an `Enum`. + +The following is a non-normative example annotated `Tuple` value with `String` and `U32` fields: +``` +{ + "kind": "Tuple", + "type_name": "CustomStructure", + "fields": [ + { + "kind": "String", + "field_name": "favorite_color", + "value": "Blue" + }, + { + "kind": "U32", + "field_name": "usage_counter", + "value": "462231" + } + ] +} +``` + * @export * @interface ProgrammaticScryptoSborValueBase */ diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBool.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBool.ts index 0fa09bae3..d34184f3f 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBool.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBool.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBoolAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBoolAllOf.ts index f6152553e..33600228c 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBoolAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBoolAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBytes.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBytes.ts index 90bf0f43e..b68b184cd 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBytes.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBytes.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBytesAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBytesAllOf.ts index 29e307413..9adbc7c50 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBytesAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueBytesAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueDecimal.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueDecimal.ts index adb415cf9..56756743a 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueDecimal.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueDecimal.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueDecimalAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueDecimalAllOf.ts index ca9d9a5b4..403edbf2c 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueDecimalAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueDecimalAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueEnum.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueEnum.ts index 899320bd3..1bf33028a 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueEnum.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueEnum.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueEnumAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueEnumAllOf.ts index 875ab721e..079559531 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueEnumAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueEnumAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI128.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI128.ts index 80a3a756f..876e78481 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI128.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI128.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI128AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI128AllOf.ts index 63554afdc..a7cc2b841 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI128AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI128AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI16.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI16.ts index 8ff600327..297138a1d 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI16.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI16.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI16AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI16AllOf.ts index c1c9997e2..7250fe3ec 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI16AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI16AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI32.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI32.ts index 6244796b1..f13c7d8cb 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI32.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI32.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI32AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI32AllOf.ts index 69ffa8a0d..ed4ecacc7 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI32AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI32AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI64.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI64.ts index 04cd88c4f..5743096ca 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI64.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI64.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI64AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI64AllOf.ts index 06f6c9193..815e07334 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI64AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI64AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI8.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI8.ts index cded8e47c..f9ae24910 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI8.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI8.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI8AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI8AllOf.ts index e9b0bf958..1a45a11c6 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI8AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueI8AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueKind.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueKind.ts index 009a06feb..35c7079a4 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueKind.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueKind.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -15,6 +15,7 @@ /** * These are the Scrypto SBOR `ValueKind`s, but with `Bytes` added as an alias for `Vec`, to display such values as hex-encoded strings. + * @export */ export const ProgrammaticScryptoSborValueKind = { diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMap.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMap.ts index d0b313486..bb97037c0 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMap.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMap.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMapAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMapAllOf.ts index 0feb37ce4..e94676fc7 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMapAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMapAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMapEntry.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMapEntry.ts index 6b20b168a..1f856f249 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMapEntry.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueMapEntry.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueNonFungibleLocalId.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueNonFungibleLocalId.ts index 274e9b079..afeb751f3 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueNonFungibleLocalId.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueNonFungibleLocalId.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueNonFungibleLocalIdAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueNonFungibleLocalIdAllOf.ts index e4bac3518..31d464f58 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueNonFungibleLocalIdAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueNonFungibleLocalIdAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueOwn.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueOwn.ts index 8d8798b56..f4d91122d 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueOwn.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueOwn.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueOwnAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueOwnAllOf.ts index 1742078d5..ceeb49dc4 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueOwnAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueOwnAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValuePreciseDecimal.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValuePreciseDecimal.ts index 3d82a9091..f5d3d43e0 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValuePreciseDecimal.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValuePreciseDecimal.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValuePreciseDecimalAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValuePreciseDecimalAllOf.ts index f380addb4..4cd7b460d 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValuePreciseDecimalAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValuePreciseDecimalAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueReference.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueReference.ts index 9641ab20e..8398209d9 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueReference.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueReference.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueReferenceAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueReferenceAllOf.ts index 5c5419f20..eafccb8c5 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueReferenceAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueReferenceAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueString.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueString.ts index bb08ccc4b..2882766cc 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueString.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueString.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueStringAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueStringAllOf.ts index b97caf0d8..47c2a2e11 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueStringAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueStringAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueTuple.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueTuple.ts index b0edf71ac..7704173cd 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueTuple.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueTuple.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueTupleAllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueTupleAllOf.ts index 59eea9aef..9bb9386d0 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueTupleAllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueTupleAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU128.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU128.ts index 40d5f6ffc..172bc4e88 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU128.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU128.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU128AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU128AllOf.ts index 01dc6bf51..76cd91574 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU128AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU128AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU16.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU16.ts index 2fe62c4bf..0d9537dc8 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU16.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU16.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU16AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU16AllOf.ts index fd1a57150..1174cc573 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU16AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU16AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU32.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU32.ts index 1544bc9d4..79ec1a1e2 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU32.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU32.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU32AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU32AllOf.ts index 06b80c65e..b0fcad169 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU32AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU32AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU64.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU64.ts index 74438b4f4..3050d4879 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU64.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU64.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU64AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU64AllOf.ts index 3d7bbd1a4..44b6133bd 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU64AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU64AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU8.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU8.ts index 3b36bc35d..ae4b91409 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU8.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU8.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU8AllOf.ts b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU8AllOf.ts index 3460f5277..b54ee5435 100644 --- a/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU8AllOf.ts +++ b/sdk/typescript/lib/generated/models/ProgrammaticScryptoSborValueU8AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKey.ts b/sdk/typescript/lib/generated/models/PublicKey.ts index 12d392885..39997e946 100644 --- a/sdk/typescript/lib/generated/models/PublicKey.ts +++ b/sdk/typescript/lib/generated/models/PublicKey.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyBase.ts b/sdk/typescript/lib/generated/models/PublicKeyBase.ts index aa7ec59fb..efad23563 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyBase.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyBase.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyEcdsaSecp256k1.ts b/sdk/typescript/lib/generated/models/PublicKeyEcdsaSecp256k1.ts index eb50d280e..2b0342bbf 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyEcdsaSecp256k1.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyEcdsaSecp256k1.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyEcdsaSecp256k1AllOf.ts b/sdk/typescript/lib/generated/models/PublicKeyEcdsaSecp256k1AllOf.ts index 85d2315b4..8900cf5c7 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyEcdsaSecp256k1AllOf.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyEcdsaSecp256k1AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyEddsaEd25519.ts b/sdk/typescript/lib/generated/models/PublicKeyEddsaEd25519.ts index 477be47b0..52809d40d 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyEddsaEd25519.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyEddsaEd25519.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyEddsaEd25519AllOf.ts b/sdk/typescript/lib/generated/models/PublicKeyEddsaEd25519AllOf.ts index 01a00d871..08db13be8 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyEddsaEd25519AllOf.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyEddsaEd25519AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyHash.ts b/sdk/typescript/lib/generated/models/PublicKeyHash.ts index 6141ff353..7a50a5188 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyHash.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyHash.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyHashBase.ts b/sdk/typescript/lib/generated/models/PublicKeyHashBase.ts index 123e7b4b3..1bb301bf4 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyHashBase.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyHashBase.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyHashEcdsaSecp256k1.ts b/sdk/typescript/lib/generated/models/PublicKeyHashEcdsaSecp256k1.ts index d231d6b05..1caa923e6 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyHashEcdsaSecp256k1.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyHashEcdsaSecp256k1.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyHashEcdsaSecp256k1AllOf.ts b/sdk/typescript/lib/generated/models/PublicKeyHashEcdsaSecp256k1AllOf.ts index 8d59fa943..9f24f6969 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyHashEcdsaSecp256k1AllOf.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyHashEcdsaSecp256k1AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyHashEddsaEd25519.ts b/sdk/typescript/lib/generated/models/PublicKeyHashEddsaEd25519.ts index 5082d6469..0713fadad 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyHashEddsaEd25519.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyHashEddsaEd25519.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyHashEddsaEd25519AllOf.ts b/sdk/typescript/lib/generated/models/PublicKeyHashEddsaEd25519AllOf.ts index f171159da..753b556c4 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyHashEddsaEd25519AllOf.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyHashEddsaEd25519AllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyHashType.ts b/sdk/typescript/lib/generated/models/PublicKeyHashType.ts index 66c24f5f0..9005e1e37 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyHashType.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyHashType.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/PublicKeyType.ts b/sdk/typescript/lib/generated/models/PublicKeyType.ts index 15d1429bb..07284d435 100644 --- a/sdk/typescript/lib/generated/models/PublicKeyType.ts +++ b/sdk/typescript/lib/generated/models/PublicKeyType.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ResourceAggregationLevel.ts b/sdk/typescript/lib/generated/models/ResourceAggregationLevel.ts index 04a585ea2..8313fa149 100644 --- a/sdk/typescript/lib/generated/models/ResourceAggregationLevel.ts +++ b/sdk/typescript/lib/generated/models/ResourceAggregationLevel.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ResultSetCursorMixin.ts b/sdk/typescript/lib/generated/models/ResultSetCursorMixin.ts index 1310f9a63..9ad59a356 100644 --- a/sdk/typescript/lib/generated/models/ResultSetCursorMixin.ts +++ b/sdk/typescript/lib/generated/models/ResultSetCursorMixin.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/RoleAssignmentResolution.ts b/sdk/typescript/lib/generated/models/RoleAssignmentResolution.ts index db1a540a6..7a61be679 100644 --- a/sdk/typescript/lib/generated/models/RoleAssignmentResolution.ts +++ b/sdk/typescript/lib/generated/models/RoleAssignmentResolution.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/RoleKey.ts b/sdk/typescript/lib/generated/models/RoleKey.ts index 53a43c8fe..d0ab1d1b7 100644 --- a/sdk/typescript/lib/generated/models/RoleKey.ts +++ b/sdk/typescript/lib/generated/models/RoleKey.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ScryptoSborValue.ts b/sdk/typescript/lib/generated/models/ScryptoSborValue.ts index cd01edf0b..1092afc6b 100644 --- a/sdk/typescript/lib/generated/models/ScryptoSborValue.ts +++ b/sdk/typescript/lib/generated/models/ScryptoSborValue.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsOptIns.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsOptIns.ts index 673296424..36e6b808c 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsOptIns.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsOptIns.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsRequest.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsRequest.ts index 1f451fbe5..5df0ceaf0 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsRequest.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsRequestAllOf.ts index 2a4f958d2..d8b97ed0c 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponse.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponse.ts index 94f92beec..d2a19d588 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponse.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseAllOf.ts index 9d370d9a0..bb8715e3c 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseComponentDetails.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseComponentDetails.ts index b6a6a9e27..b2c3d8cc9 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseComponentDetails.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseComponentDetails.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -52,9 +52,10 @@ export interface StateEntityDetailsResponseComponentDetails { blueprint_version: string; /** * A representation of a component's inner state. If this entity is a `GenericComponent`, this field will be in a programmatic JSON - * structure (you can deserialize it as a `ProgrammaticScryptoSborValue`). Otherwise, for "native" components such as `Account`, - * `Validator`, `AccessController`, `OneResourcePool`, `TwoResourcePool`, and `MultiResourcePool`, this field will be a - * custom JSON model defined in the Core API schema. +structure (you can deserialize it as a `ProgrammaticScryptoSborValue`). Otherwise, for "native" components such as `Account`, +`Validator`, `AccessController`, `OneResourcePool`, `TwoResourcePool`, and `MultiResourcePool`, this field will be a +custom JSON model defined in the Core API schema. + * @type {object} * @memberof StateEntityDetailsResponseComponentDetails */ diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseComponentDetailsAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseComponentDetailsAllOf.ts index f0fcd971f..43fda12b7 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseComponentDetailsAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseComponentDetailsAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -46,9 +46,10 @@ export interface StateEntityDetailsResponseComponentDetailsAllOf { blueprint_version: string; /** * A representation of a component's inner state. If this entity is a `GenericComponent`, this field will be in a programmatic JSON - * structure (you can deserialize it as a `ProgrammaticScryptoSborValue`). Otherwise, for "native" components such as `Account`, - * `Validator`, `AccessController`, `OneResourcePool`, `TwoResourcePool`, and `MultiResourcePool`, this field will be a - * custom JSON model defined in the Core API schema. +structure (you can deserialize it as a `ProgrammaticScryptoSborValue`). Otherwise, for "native" components such as `Account`, +`Validator`, `AccessController`, `OneResourcePool`, `TwoResourcePool`, and `MultiResourcePool`, this field will be a +custom JSON model defined in the Core API schema. + * @type {object} * @memberof StateEntityDetailsResponseComponentDetailsAllOf */ diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleResourceDetails.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleResourceDetails.ts index 70e59ef4c..65ba0ee0a 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleResourceDetails.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleResourceDetails.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleResourceDetailsAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleResourceDetailsAllOf.ts index f19524b75..16743ec06 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleResourceDetailsAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleResourceDetailsAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleVaultDetails.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleVaultDetails.ts index c465718c7..842b2ed7e 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleVaultDetails.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleVaultDetails.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleVaultDetailsAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleVaultDetailsAllOf.ts index 846daab9f..d008061f6 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleVaultDetailsAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseFungibleVaultDetailsAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItem.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItem.ts index f73d8eebd..88a3187b0 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItem.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemAncestorIdentities.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemAncestorIdentities.ts index e966b164e..b4a42c1d0 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemAncestorIdentities.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemAncestorIdentities.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetails.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetails.ts index 74bd31523..b88d9f672 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetails.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetails.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetailsBase.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetailsBase.ts index 112997db0..7153bdf49 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetailsBase.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetailsBase.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetailsType.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetailsType.ts index fe593bf03..d489d130f 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetailsType.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseItemDetailsType.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleResourceDetails.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleResourceDetails.ts index b231a64b5..2cbfb3ac2 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleResourceDetails.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleResourceDetails.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.ts index e5b5af425..dc583c0ed 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleVaultDetails.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleVaultDetails.ts index 2f6aa16fe..46784c0ab 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleVaultDetails.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleVaultDetails.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.ts index b83b4c8f6..8c7e32abc 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetails.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetails.ts index 46bf2d2c2..3ef125206 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetails.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetails.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsAllOf.ts index ca0b449ee..c5e8a1b83 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintCollection.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintCollection.ts index 02d6c320e..209d261b5 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintCollection.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintCollectionAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintCollectionAllOf.ts index 9784a3765..621a4420f 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintCollectionAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintCollectionAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintItem.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintItem.ts index 3a967a64b..cf4208c62 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintItem.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsBlueprintItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -33,6 +33,7 @@ export interface StateEntityDetailsResponsePackageDetailsBlueprintItem { version: string; /** * This type is defined in the Core API as `BlueprintDefinition`. See the Core API documentation for more details. + * @type {object} * @memberof StateEntityDetailsResponsePackageDetailsBlueprintItem */ @@ -45,6 +46,7 @@ export interface StateEntityDetailsResponsePackageDetailsBlueprintItem { dependant_entities?: Array; /** * This type is defined in the Core API as `AuthConfig`. See the Core API documentation for more details. + * @type {object} * @memberof StateEntityDetailsResponsePackageDetailsBlueprintItem */ @@ -57,6 +59,7 @@ export interface StateEntityDetailsResponsePackageDetailsBlueprintItem { auth_template_is_locked?: boolean | null; /** * This type is defined in the Core API as `BlueprintRoyaltyConfig`. See the Core API documentation for more details. + * @type {object} * @memberof StateEntityDetailsResponsePackageDetailsBlueprintItem */ diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsCodeCollection.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsCodeCollection.ts index 3e361f1cb..fce4cbbe4 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsCodeCollection.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsCodeCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsCodeCollectionAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsCodeCollectionAllOf.ts index 03ccc6427..819bb6774 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsCodeCollectionAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsCodeCollectionAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaCollection.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaCollection.ts index 067d44f87..86985468f 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaCollection.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaCollectionAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaCollectionAllOf.ts index 2e9cb019a..eb1aff38b 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaCollectionAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaCollectionAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaItem.ts b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaItem.ts index 00cab86b0..d20241629 100644 --- a/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaItem.ts +++ b/sdk/typescript/lib/generated/models/StateEntityDetailsResponsePackageDetailsSchemaItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageRequest.ts b/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageRequest.ts index 2aff09202..4e2ab985d 100644 --- a/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageRequest.ts +++ b/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageRequestAllOf.ts index 3a91a90b9..c53967097 100644 --- a/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageResponse.ts b/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageResponse.ts index 31d3a36dc..bbd25296a 100644 --- a/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageResponse.ts +++ b/sdk/typescript/lib/generated/models/StateEntityFungibleResourceVaultsPageResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequest.ts b/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequest.ts index a1abbdc2f..4caf973e6 100644 --- a/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequest.ts +++ b/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequestAllOf.ts index 7215002a2..e2daf698b 100644 --- a/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequestOptIns.ts b/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequestOptIns.ts index a9c4f3b5d..51bb61b4c 100644 --- a/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequestOptIns.ts +++ b/sdk/typescript/lib/generated/models/StateEntityFungiblesPageRequestOptIns.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityFungiblesPageResponse.ts b/sdk/typescript/lib/generated/models/StateEntityFungiblesPageResponse.ts index 475c2cf1e..83ce4a52b 100644 --- a/sdk/typescript/lib/generated/models/StateEntityFungiblesPageResponse.ts +++ b/sdk/typescript/lib/generated/models/StateEntityFungiblesPageResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityMetadataPageRequest.ts b/sdk/typescript/lib/generated/models/StateEntityMetadataPageRequest.ts index c359cff14..ae46822e8 100644 --- a/sdk/typescript/lib/generated/models/StateEntityMetadataPageRequest.ts +++ b/sdk/typescript/lib/generated/models/StateEntityMetadataPageRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityMetadataPageRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityMetadataPageRequestAllOf.ts index a743cd183..545b70db2 100644 --- a/sdk/typescript/lib/generated/models/StateEntityMetadataPageRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityMetadataPageRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityMetadataPageResponse.ts b/sdk/typescript/lib/generated/models/StateEntityMetadataPageResponse.ts index 00d063606..affedd185 100644 --- a/sdk/typescript/lib/generated/models/StateEntityMetadataPageResponse.ts +++ b/sdk/typescript/lib/generated/models/StateEntityMetadataPageResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageRequest.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageRequest.ts index c353907c6..6a01c2cdb 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageRequest.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageRequestAllOf.ts index 883ac80db..69d4b6e03 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageResponse.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageResponse.ts index ff63e0aec..dc004a602 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageResponse.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungibleIdsPageResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageOptIns.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageOptIns.ts index b606f0015..1a366536b 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageOptIns.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageOptIns.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageRequest.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageRequest.ts index 521218245..bf9de344e 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageRequest.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageRequestAllOf.ts index 1b2e3679d..93ddd8802 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageResponse.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageResponse.ts index 77c56a884..4b109b5c1 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageResponse.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungibleResourceVaultsPageResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequest.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequest.ts index ca61e9366..4c84cd738 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequest.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequestAllOf.ts index e5782f0b0..6a762a611 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequestOptIns.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequestOptIns.ts index 4357d5c4c..564e68773 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequestOptIns.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageRequestOptIns.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageResponse.ts b/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageResponse.ts index 39cc8a4dc..741118250 100644 --- a/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageResponse.ts +++ b/sdk/typescript/lib/generated/models/StateEntityNonFungiblesPageResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequest.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequest.ts index f7fd364ba..abe925c7f 100644 --- a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequest.ts +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequestAllOf.ts index c6ecf5c1b..94e35ee36 100644 --- a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequestKeyItem.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequestKeyItem.ts index ddaeeefa7..332137ec1 100644 --- a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequestKeyItem.ts +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataRequestKeyItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponse.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponse.ts index b7c00eeb7..4f7e99946 100644 --- a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponse.ts +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponseAllOf.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponseAllOf.ts index 9014dad60..20fff6159 100644 --- a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponseItem.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponseItem.ts index 1b38898e9..abb74ef60 100644 --- a/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponseItem.ts +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreDataResponseItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysCollection.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysCollection.ts new file mode 100644 index 000000000..52cc9236f --- /dev/null +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysCollection.ts @@ -0,0 +1,89 @@ +/* tslint:disable */ +/* eslint-disable */ +/** + * Radix Gateway API - Babylon + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ + +import { exists, mapValues } from '../runtime'; +import type { StateKeyValueStoreKeysResponseItem } from './StateKeyValueStoreKeysResponseItem'; +import { + StateKeyValueStoreKeysResponseItemFromJSON, + StateKeyValueStoreKeysResponseItemFromJSONTyped, + StateKeyValueStoreKeysResponseItemToJSON, +} from './StateKeyValueStoreKeysResponseItem'; + +/** + * Key value store items collection. + * @export + * @interface StateKeyValueStoreKeysCollection + */ +export interface StateKeyValueStoreKeysCollection { + /** + * Total number of items in underlying collection, fragment of which is available in `items` collection. + * @type {number} + * @memberof StateKeyValueStoreKeysCollection + */ + total_count?: number | null; + /** + * If specified, contains a cursor to query next page of the `items` collection. + * @type {string} + * @memberof StateKeyValueStoreKeysCollection + */ + next_cursor?: string | null; + /** + * + * @type {Array} + * @memberof StateKeyValueStoreKeysCollection + */ + items: Array; +} + +/** + * Check if a given object implements the StateKeyValueStoreKeysCollection interface. + */ +export function instanceOfStateKeyValueStoreKeysCollection(value: object): boolean { + let isInstance = true; + isInstance = isInstance && "items" in value; + + return isInstance; +} + +export function StateKeyValueStoreKeysCollectionFromJSON(json: any): StateKeyValueStoreKeysCollection { + return StateKeyValueStoreKeysCollectionFromJSONTyped(json, false); +} + +export function StateKeyValueStoreKeysCollectionFromJSONTyped(json: any, ignoreDiscriminator: boolean): StateKeyValueStoreKeysCollection { + if ((json === undefined) || (json === null)) { + return json; + } + return { + + 'total_count': !exists(json, 'total_count') ? undefined : json['total_count'], + 'next_cursor': !exists(json, 'next_cursor') ? undefined : json['next_cursor'], + 'items': ((json['items'] as Array).map(StateKeyValueStoreKeysResponseItemFromJSON)), + }; +} + +export function StateKeyValueStoreKeysCollectionToJSON(value?: StateKeyValueStoreKeysCollection | null): any { + if (value === undefined) { + return undefined; + } + if (value === null) { + return null; + } + return { + + 'total_count': value.total_count, + 'next_cursor': value.next_cursor, + 'items': ((value.items as Array).map(StateKeyValueStoreKeysResponseItemToJSON)), + }; +} + diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysCollectionAllOf.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysCollectionAllOf.ts new file mode 100644 index 000000000..8507331ec --- /dev/null +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysCollectionAllOf.ts @@ -0,0 +1,73 @@ +/* tslint:disable */ +/* eslint-disable */ +/** + * Radix Gateway API - Babylon + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ + +import { exists, mapValues } from '../runtime'; +import type { StateKeyValueStoreKeysResponseItem } from './StateKeyValueStoreKeysResponseItem'; +import { + StateKeyValueStoreKeysResponseItemFromJSON, + StateKeyValueStoreKeysResponseItemFromJSONTyped, + StateKeyValueStoreKeysResponseItemToJSON, +} from './StateKeyValueStoreKeysResponseItem'; + +/** + * + * @export + * @interface StateKeyValueStoreKeysCollectionAllOf + */ +export interface StateKeyValueStoreKeysCollectionAllOf { + /** + * + * @type {Array} + * @memberof StateKeyValueStoreKeysCollectionAllOf + */ + items: Array; +} + +/** + * Check if a given object implements the StateKeyValueStoreKeysCollectionAllOf interface. + */ +export function instanceOfStateKeyValueStoreKeysCollectionAllOf(value: object): boolean { + let isInstance = true; + isInstance = isInstance && "items" in value; + + return isInstance; +} + +export function StateKeyValueStoreKeysCollectionAllOfFromJSON(json: any): StateKeyValueStoreKeysCollectionAllOf { + return StateKeyValueStoreKeysCollectionAllOfFromJSONTyped(json, false); +} + +export function StateKeyValueStoreKeysCollectionAllOfFromJSONTyped(json: any, ignoreDiscriminator: boolean): StateKeyValueStoreKeysCollectionAllOf { + if ((json === undefined) || (json === null)) { + return json; + } + return { + + 'items': ((json['items'] as Array).map(StateKeyValueStoreKeysResponseItemFromJSON)), + }; +} + +export function StateKeyValueStoreKeysCollectionAllOfToJSON(value?: StateKeyValueStoreKeysCollectionAllOf | null): any { + if (value === undefined) { + return undefined; + } + if (value === null) { + return null; + } + return { + + 'items': ((value.items as Array).map(StateKeyValueStoreKeysResponseItemToJSON)), + }; +} + diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysRequest.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysRequest.ts new file mode 100644 index 000000000..fb6acdc5d --- /dev/null +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysRequest.ts @@ -0,0 +1,97 @@ +/* tslint:disable */ +/* eslint-disable */ +/** + * Radix Gateway API - Babylon + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ + +import { exists, mapValues } from '../runtime'; +import type { LedgerStateSelector } from './LedgerStateSelector'; +import { + LedgerStateSelectorFromJSON, + LedgerStateSelectorFromJSONTyped, + LedgerStateSelectorToJSON, +} from './LedgerStateSelector'; + +/** + * + * @export + * @interface StateKeyValueStoreKeysRequest + */ +export interface StateKeyValueStoreKeysRequest { + /** + * + * @type {LedgerStateSelector} + * @memberof StateKeyValueStoreKeysRequest + */ + at_ledger_state?: LedgerStateSelector | null; + /** + * This cursor allows forward pagination, by providing the cursor from the previous request. + * @type {string} + * @memberof StateKeyValueStoreKeysRequest + */ + cursor?: string | null; + /** + * The page size requested. + * @type {number} + * @memberof StateKeyValueStoreKeysRequest + */ + limit_per_page?: number | null; + /** + * Bech32m-encoded human readable version of the address. + * @type {string} + * @memberof StateKeyValueStoreKeysRequest + */ + key_value_store_address: string; +} + +/** + * Check if a given object implements the StateKeyValueStoreKeysRequest interface. + */ +export function instanceOfStateKeyValueStoreKeysRequest(value: object): boolean { + let isInstance = true; + isInstance = isInstance && "key_value_store_address" in value; + + return isInstance; +} + +export function StateKeyValueStoreKeysRequestFromJSON(json: any): StateKeyValueStoreKeysRequest { + return StateKeyValueStoreKeysRequestFromJSONTyped(json, false); +} + +export function StateKeyValueStoreKeysRequestFromJSONTyped(json: any, ignoreDiscriminator: boolean): StateKeyValueStoreKeysRequest { + if ((json === undefined) || (json === null)) { + return json; + } + return { + + 'at_ledger_state': !exists(json, 'at_ledger_state') ? undefined : LedgerStateSelectorFromJSON(json['at_ledger_state']), + 'cursor': !exists(json, 'cursor') ? undefined : json['cursor'], + 'limit_per_page': !exists(json, 'limit_per_page') ? undefined : json['limit_per_page'], + 'key_value_store_address': json['key_value_store_address'], + }; +} + +export function StateKeyValueStoreKeysRequestToJSON(value?: StateKeyValueStoreKeysRequest | null): any { + if (value === undefined) { + return undefined; + } + if (value === null) { + return null; + } + return { + + 'at_ledger_state': LedgerStateSelectorToJSON(value.at_ledger_state), + 'cursor': value.cursor, + 'limit_per_page': value.limit_per_page, + 'key_value_store_address': value.key_value_store_address, + }; +} + diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysRequestAllOf.ts new file mode 100644 index 000000000..7ff18ec63 --- /dev/null +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysRequestAllOf.ts @@ -0,0 +1,66 @@ +/* tslint:disable */ +/* eslint-disable */ +/** + * Radix Gateway API - Babylon + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ + +import { exists, mapValues } from '../runtime'; +/** + * + * @export + * @interface StateKeyValueStoreKeysRequestAllOf + */ +export interface StateKeyValueStoreKeysRequestAllOf { + /** + * Bech32m-encoded human readable version of the address. + * @type {string} + * @memberof StateKeyValueStoreKeysRequestAllOf + */ + key_value_store_address: string; +} + +/** + * Check if a given object implements the StateKeyValueStoreKeysRequestAllOf interface. + */ +export function instanceOfStateKeyValueStoreKeysRequestAllOf(value: object): boolean { + let isInstance = true; + isInstance = isInstance && "key_value_store_address" in value; + + return isInstance; +} + +export function StateKeyValueStoreKeysRequestAllOfFromJSON(json: any): StateKeyValueStoreKeysRequestAllOf { + return StateKeyValueStoreKeysRequestAllOfFromJSONTyped(json, false); +} + +export function StateKeyValueStoreKeysRequestAllOfFromJSONTyped(json: any, ignoreDiscriminator: boolean): StateKeyValueStoreKeysRequestAllOf { + if ((json === undefined) || (json === null)) { + return json; + } + return { + + 'key_value_store_address': json['key_value_store_address'], + }; +} + +export function StateKeyValueStoreKeysRequestAllOfToJSON(value?: StateKeyValueStoreKeysRequestAllOf | null): any { + if (value === undefined) { + return undefined; + } + if (value === null) { + return null; + } + return { + + 'key_value_store_address': value.key_value_store_address, + }; +} + diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysResponse.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysResponse.ts new file mode 100644 index 000000000..91ef45f0f --- /dev/null +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysResponse.ts @@ -0,0 +1,113 @@ +/* tslint:disable */ +/* eslint-disable */ +/** + * Radix Gateway API - Babylon + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ + +import { exists, mapValues } from '../runtime'; +import type { LedgerState } from './LedgerState'; +import { + LedgerStateFromJSON, + LedgerStateFromJSONTyped, + LedgerStateToJSON, +} from './LedgerState'; +import type { StateKeyValueStoreKeysResponseItem } from './StateKeyValueStoreKeysResponseItem'; +import { + StateKeyValueStoreKeysResponseItemFromJSON, + StateKeyValueStoreKeysResponseItemFromJSONTyped, + StateKeyValueStoreKeysResponseItemToJSON, +} from './StateKeyValueStoreKeysResponseItem'; + +/** + * + * @export + * @interface StateKeyValueStoreKeysResponse + */ +export interface StateKeyValueStoreKeysResponse { + /** + * + * @type {LedgerState} + * @memberof StateKeyValueStoreKeysResponse + */ + ledger_state: LedgerState; + /** + * Total number of items in underlying collection, fragment of which is available in `items` collection. + * @type {number} + * @memberof StateKeyValueStoreKeysResponse + */ + total_count?: number | null; + /** + * If specified, contains a cursor to query next page of the `items` collection. + * @type {string} + * @memberof StateKeyValueStoreKeysResponse + */ + next_cursor?: string | null; + /** + * + * @type {Array} + * @memberof StateKeyValueStoreKeysResponse + */ + items: Array; + /** + * Bech32m-encoded human readable version of the address. + * @type {string} + * @memberof StateKeyValueStoreKeysResponse + */ + key_value_store_address: string; +} + +/** + * Check if a given object implements the StateKeyValueStoreKeysResponse interface. + */ +export function instanceOfStateKeyValueStoreKeysResponse(value: object): boolean { + let isInstance = true; + isInstance = isInstance && "ledger_state" in value; + isInstance = isInstance && "items" in value; + isInstance = isInstance && "key_value_store_address" in value; + + return isInstance; +} + +export function StateKeyValueStoreKeysResponseFromJSON(json: any): StateKeyValueStoreKeysResponse { + return StateKeyValueStoreKeysResponseFromJSONTyped(json, false); +} + +export function StateKeyValueStoreKeysResponseFromJSONTyped(json: any, ignoreDiscriminator: boolean): StateKeyValueStoreKeysResponse { + if ((json === undefined) || (json === null)) { + return json; + } + return { + + 'ledger_state': LedgerStateFromJSON(json['ledger_state']), + 'total_count': !exists(json, 'total_count') ? undefined : json['total_count'], + 'next_cursor': !exists(json, 'next_cursor') ? undefined : json['next_cursor'], + 'items': ((json['items'] as Array).map(StateKeyValueStoreKeysResponseItemFromJSON)), + 'key_value_store_address': json['key_value_store_address'], + }; +} + +export function StateKeyValueStoreKeysResponseToJSON(value?: StateKeyValueStoreKeysResponse | null): any { + if (value === undefined) { + return undefined; + } + if (value === null) { + return null; + } + return { + + 'ledger_state': LedgerStateToJSON(value.ledger_state), + 'total_count': value.total_count, + 'next_cursor': value.next_cursor, + 'items': ((value.items as Array).map(StateKeyValueStoreKeysResponseItemToJSON)), + 'key_value_store_address': value.key_value_store_address, + }; +} + diff --git a/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysResponseItem.ts b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysResponseItem.ts new file mode 100644 index 000000000..5b52e6c85 --- /dev/null +++ b/sdk/typescript/lib/generated/models/StateKeyValueStoreKeysResponseItem.ts @@ -0,0 +1,82 @@ +/* tslint:disable */ +/* eslint-disable */ +/** + * Radix Gateway API - Babylon + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ + +import { exists, mapValues } from '../runtime'; +import type { ScryptoSborValue } from './ScryptoSborValue'; +import { + ScryptoSborValueFromJSON, + ScryptoSborValueFromJSONTyped, + ScryptoSborValueToJSON, +} from './ScryptoSborValue'; + +/** + * + * @export + * @interface StateKeyValueStoreKeysResponseItem + */ +export interface StateKeyValueStoreKeysResponseItem { + /** + * + * @type {ScryptoSborValue} + * @memberof StateKeyValueStoreKeysResponseItem + */ + key: ScryptoSborValue; + /** + * The most recent state version underlying object was modified at. + * @type {number} + * @memberof StateKeyValueStoreKeysResponseItem + */ + last_updated_at_state_version: number; +} + +/** + * Check if a given object implements the StateKeyValueStoreKeysResponseItem interface. + */ +export function instanceOfStateKeyValueStoreKeysResponseItem(value: object): boolean { + let isInstance = true; + isInstance = isInstance && "key" in value; + isInstance = isInstance && "last_updated_at_state_version" in value; + + return isInstance; +} + +export function StateKeyValueStoreKeysResponseItemFromJSON(json: any): StateKeyValueStoreKeysResponseItem { + return StateKeyValueStoreKeysResponseItemFromJSONTyped(json, false); +} + +export function StateKeyValueStoreKeysResponseItemFromJSONTyped(json: any, ignoreDiscriminator: boolean): StateKeyValueStoreKeysResponseItem { + if ((json === undefined) || (json === null)) { + return json; + } + return { + + 'key': ScryptoSborValueFromJSON(json['key']), + 'last_updated_at_state_version': json['last_updated_at_state_version'], + }; +} + +export function StateKeyValueStoreKeysResponseItemToJSON(value?: StateKeyValueStoreKeysResponseItem | null): any { + if (value === undefined) { + return undefined; + } + if (value === null) { + return null; + } + return { + + 'key': ScryptoSborValueToJSON(value.key), + 'last_updated_at_state_version': value.last_updated_at_state_version, + }; +} + diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleDataRequest.ts b/sdk/typescript/lib/generated/models/StateNonFungibleDataRequest.ts index e5c689541..b9f525ed0 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleDataRequest.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleDataRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleDataResponse.ts b/sdk/typescript/lib/generated/models/StateNonFungibleDataResponse.ts index ef45d6ce8..ccecc1b47 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleDataResponse.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleDataResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleDataResponseAllOf.ts b/sdk/typescript/lib/generated/models/StateNonFungibleDataResponseAllOf.ts index c1faec397..79a540db9 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleDataResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleDataResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleDetailsResponseItem.ts b/sdk/typescript/lib/generated/models/StateNonFungibleDetailsResponseItem.ts index fc4fa9b0b..ef7d55e53 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleDetailsResponseItem.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleDetailsResponseItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleIdsRequest.ts b/sdk/typescript/lib/generated/models/StateNonFungibleIdsRequest.ts index e8511956c..ffcba807e 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleIdsRequest.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleIdsRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleIdsRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateNonFungibleIdsRequestAllOf.ts index 64461d0d0..8a6fa0ed5 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleIdsRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleIdsRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleIdsResponse.ts b/sdk/typescript/lib/generated/models/StateNonFungibleIdsResponse.ts index bdedd4826..c57c4a4f8 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleIdsResponse.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleIdsResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleIdsResponseAllOf.ts b/sdk/typescript/lib/generated/models/StateNonFungibleIdsResponseAllOf.ts index f120495b9..868bd96b0 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleIdsResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleIdsResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleLocationRequest.ts b/sdk/typescript/lib/generated/models/StateNonFungibleLocationRequest.ts index 77aa78e25..8cc9cf088 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleLocationRequest.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleLocationRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleLocationRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateNonFungibleLocationRequestAllOf.ts index 133d01d2d..843cc713e 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleLocationRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleLocationRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponse.ts b/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponse.ts index bba299f13..4fc23735b 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponse.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponseAllOf.ts b/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponseAllOf.ts index 46ba148b6..89ced8ff6 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponseItem.ts b/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponseItem.ts index 032b2d4e8..264872a53 100644 --- a/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponseItem.ts +++ b/sdk/typescript/lib/generated/models/StateNonFungibleLocationResponseItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateValidatorsListRequest.ts b/sdk/typescript/lib/generated/models/StateValidatorsListRequest.ts index 95b7e1c0c..20a652775 100644 --- a/sdk/typescript/lib/generated/models/StateValidatorsListRequest.ts +++ b/sdk/typescript/lib/generated/models/StateValidatorsListRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateValidatorsListRequestAllOf.ts b/sdk/typescript/lib/generated/models/StateValidatorsListRequestAllOf.ts index dd4fb509e..d3ea113e7 100644 --- a/sdk/typescript/lib/generated/models/StateValidatorsListRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateValidatorsListRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateValidatorsListResponse.ts b/sdk/typescript/lib/generated/models/StateValidatorsListResponse.ts index d8301d5ca..dee4a9f4c 100644 --- a/sdk/typescript/lib/generated/models/StateValidatorsListResponse.ts +++ b/sdk/typescript/lib/generated/models/StateValidatorsListResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StateValidatorsListResponseAllOf.ts b/sdk/typescript/lib/generated/models/StateValidatorsListResponseAllOf.ts index 574ded7d5..098760542 100644 --- a/sdk/typescript/lib/generated/models/StateValidatorsListResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/StateValidatorsListResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StreamTransactionsRequest.ts b/sdk/typescript/lib/generated/models/StreamTransactionsRequest.ts index 6353f6f50..d55cdcb60 100644 --- a/sdk/typescript/lib/generated/models/StreamTransactionsRequest.ts +++ b/sdk/typescript/lib/generated/models/StreamTransactionsRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -19,6 +19,12 @@ import { LedgerStateSelectorFromJSONTyped, LedgerStateSelectorToJSON, } from './LedgerStateSelector'; +import type { StreamTransactionsRequestAllOfManifestClassFilter } from './StreamTransactionsRequestAllOfManifestClassFilter'; +import { + StreamTransactionsRequestAllOfManifestClassFilterFromJSON, + StreamTransactionsRequestAllOfManifestClassFilterFromJSONTyped, + StreamTransactionsRequestAllOfManifestClassFilterToJSON, +} from './StreamTransactionsRequestAllOfManifestClassFilter'; import type { StreamTransactionsRequestEventFilterItem } from './StreamTransactionsRequestEventFilterItem'; import { StreamTransactionsRequestEventFilterItemFromJSON, @@ -98,6 +104,24 @@ export interface StreamTransactionsRequest { * @memberof StreamTransactionsRequest */ events_filter?: Array; + /** + * + * @type {Array} + * @memberof StreamTransactionsRequest + */ + accounts_with_manifest_owner_method_calls?: Array; + /** + * + * @type {Array} + * @memberof StreamTransactionsRequest + */ + accounts_without_manifest_owner_method_calls?: Array; + /** + * + * @type {StreamTransactionsRequestAllOfManifestClassFilter} + * @memberof StreamTransactionsRequest + */ + manifest_class_filter?: StreamTransactionsRequestAllOfManifestClassFilter; /** * Configures the order of returned result set. Defaults to `desc`. * @type {string} @@ -162,6 +186,9 @@ export function StreamTransactionsRequestFromJSONTyped(json: any, ignoreDiscrimi 'manifest_resources_filter': !exists(json, 'manifest_resources_filter') ? undefined : json['manifest_resources_filter'], 'affected_global_entities_filter': !exists(json, 'affected_global_entities_filter') ? undefined : json['affected_global_entities_filter'], 'events_filter': !exists(json, 'events_filter') ? undefined : ((json['events_filter'] as Array).map(StreamTransactionsRequestEventFilterItemFromJSON)), + 'accounts_with_manifest_owner_method_calls': !exists(json, 'accounts_with_manifest_owner_method_calls') ? undefined : json['accounts_with_manifest_owner_method_calls'], + 'accounts_without_manifest_owner_method_calls': !exists(json, 'accounts_without_manifest_owner_method_calls') ? undefined : json['accounts_without_manifest_owner_method_calls'], + 'manifest_class_filter': !exists(json, 'manifest_class_filter') ? undefined : StreamTransactionsRequestAllOfManifestClassFilterFromJSON(json['manifest_class_filter']), 'order': !exists(json, 'order') ? undefined : json['order'], 'opt_ins': !exists(json, 'opt_ins') ? undefined : TransactionDetailsOptInsFromJSON(json['opt_ins']), }; @@ -186,6 +213,9 @@ export function StreamTransactionsRequestToJSON(value?: StreamTransactionsReques 'manifest_resources_filter': value.manifest_resources_filter, 'affected_global_entities_filter': value.affected_global_entities_filter, 'events_filter': value.events_filter === undefined ? undefined : ((value.events_filter as Array).map(StreamTransactionsRequestEventFilterItemToJSON)), + 'accounts_with_manifest_owner_method_calls': value.accounts_with_manifest_owner_method_calls, + 'accounts_without_manifest_owner_method_calls': value.accounts_without_manifest_owner_method_calls, + 'manifest_class_filter': StreamTransactionsRequestAllOfManifestClassFilterToJSON(value.manifest_class_filter), 'order': value.order, 'opt_ins': TransactionDetailsOptInsToJSON(value.opt_ins), }; diff --git a/sdk/typescript/lib/generated/models/StreamTransactionsRequestAllOf.ts b/sdk/typescript/lib/generated/models/StreamTransactionsRequestAllOf.ts index c3fce916e..bfb77d903 100644 --- a/sdk/typescript/lib/generated/models/StreamTransactionsRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/StreamTransactionsRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -13,6 +13,12 @@ */ import { exists, mapValues } from '../runtime'; +import type { StreamTransactionsRequestAllOfManifestClassFilter } from './StreamTransactionsRequestAllOfManifestClassFilter'; +import { + StreamTransactionsRequestAllOfManifestClassFilterFromJSON, + StreamTransactionsRequestAllOfManifestClassFilterFromJSONTyped, + StreamTransactionsRequestAllOfManifestClassFilterToJSON, +} from './StreamTransactionsRequestAllOfManifestClassFilter'; import type { StreamTransactionsRequestEventFilterItem } from './StreamTransactionsRequestEventFilterItem'; import { StreamTransactionsRequestEventFilterItemFromJSON, @@ -68,6 +74,24 @@ export interface StreamTransactionsRequestAllOf { * @memberof StreamTransactionsRequestAllOf */ events_filter?: Array; + /** + * + * @type {Array} + * @memberof StreamTransactionsRequestAllOf + */ + accounts_with_manifest_owner_method_calls?: Array; + /** + * + * @type {Array} + * @memberof StreamTransactionsRequestAllOf + */ + accounts_without_manifest_owner_method_calls?: Array; + /** + * + * @type {StreamTransactionsRequestAllOfManifestClassFilter} + * @memberof StreamTransactionsRequestAllOf + */ + manifest_class_filter?: StreamTransactionsRequestAllOfManifestClassFilter; /** * Configures the order of returned result set. Defaults to `desc`. * @type {string} @@ -128,6 +152,9 @@ export function StreamTransactionsRequestAllOfFromJSONTyped(json: any, ignoreDis 'manifest_resources_filter': !exists(json, 'manifest_resources_filter') ? undefined : json['manifest_resources_filter'], 'affected_global_entities_filter': !exists(json, 'affected_global_entities_filter') ? undefined : json['affected_global_entities_filter'], 'events_filter': !exists(json, 'events_filter') ? undefined : ((json['events_filter'] as Array).map(StreamTransactionsRequestEventFilterItemFromJSON)), + 'accounts_with_manifest_owner_method_calls': !exists(json, 'accounts_with_manifest_owner_method_calls') ? undefined : json['accounts_with_manifest_owner_method_calls'], + 'accounts_without_manifest_owner_method_calls': !exists(json, 'accounts_without_manifest_owner_method_calls') ? undefined : json['accounts_without_manifest_owner_method_calls'], + 'manifest_class_filter': !exists(json, 'manifest_class_filter') ? undefined : StreamTransactionsRequestAllOfManifestClassFilterFromJSON(json['manifest_class_filter']), 'order': !exists(json, 'order') ? undefined : json['order'], 'opt_ins': !exists(json, 'opt_ins') ? undefined : TransactionDetailsOptInsFromJSON(json['opt_ins']), }; @@ -148,6 +175,9 @@ export function StreamTransactionsRequestAllOfToJSON(value?: StreamTransactionsR 'manifest_resources_filter': value.manifest_resources_filter, 'affected_global_entities_filter': value.affected_global_entities_filter, 'events_filter': value.events_filter === undefined ? undefined : ((value.events_filter as Array).map(StreamTransactionsRequestEventFilterItemToJSON)), + 'accounts_with_manifest_owner_method_calls': value.accounts_with_manifest_owner_method_calls, + 'accounts_without_manifest_owner_method_calls': value.accounts_without_manifest_owner_method_calls, + 'manifest_class_filter': StreamTransactionsRequestAllOfManifestClassFilterToJSON(value.manifest_class_filter), 'order': value.order, 'opt_ins': TransactionDetailsOptInsToJSON(value.opt_ins), }; diff --git a/sdk/typescript/lib/generated/models/StreamTransactionsRequestAllOfManifestClassFilter.ts b/sdk/typescript/lib/generated/models/StreamTransactionsRequestAllOfManifestClassFilter.ts new file mode 100644 index 000000000..2332c73d2 --- /dev/null +++ b/sdk/typescript/lib/generated/models/StreamTransactionsRequestAllOfManifestClassFilter.ts @@ -0,0 +1,81 @@ +/* tslint:disable */ +/* eslint-disable */ +/** + * Radix Gateway API - Babylon + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * + * + * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). + * https://openapi-generator.tech + * Do not edit the class manually. + */ + +import { exists, mapValues } from '../runtime'; +import type { ManifestClass } from './ManifestClass'; +import { + ManifestClassFromJSON, + ManifestClassFromJSONTyped, + ManifestClassToJSON, +} from './ManifestClass'; + +/** + * + * @export + * @interface StreamTransactionsRequestAllOfManifestClassFilter + */ +export interface StreamTransactionsRequestAllOfManifestClassFilter { + /** + * + * @type {ManifestClass} + * @memberof StreamTransactionsRequestAllOfManifestClassFilter + */ + _class: ManifestClass; + /** + * + * @type {boolean} + * @memberof StreamTransactionsRequestAllOfManifestClassFilter + */ + match_only_most_specific?: boolean; +} + +/** + * Check if a given object implements the StreamTransactionsRequestAllOfManifestClassFilter interface. + */ +export function instanceOfStreamTransactionsRequestAllOfManifestClassFilter(value: object): boolean { + let isInstance = true; + isInstance = isInstance && "_class" in value; + + return isInstance; +} + +export function StreamTransactionsRequestAllOfManifestClassFilterFromJSON(json: any): StreamTransactionsRequestAllOfManifestClassFilter { + return StreamTransactionsRequestAllOfManifestClassFilterFromJSONTyped(json, false); +} + +export function StreamTransactionsRequestAllOfManifestClassFilterFromJSONTyped(json: any, ignoreDiscriminator: boolean): StreamTransactionsRequestAllOfManifestClassFilter { + if ((json === undefined) || (json === null)) { + return json; + } + return { + + '_class': ManifestClassFromJSON(json['class']), + 'match_only_most_specific': !exists(json, 'match_only_most_specific') ? undefined : json['match_only_most_specific'], + }; +} + +export function StreamTransactionsRequestAllOfManifestClassFilterToJSON(value?: StreamTransactionsRequestAllOfManifestClassFilter | null): any { + if (value === undefined) { + return undefined; + } + if (value === null) { + return null; + } + return { + + 'class': ManifestClassToJSON(value._class), + 'match_only_most_specific': value.match_only_most_specific, + }; +} + diff --git a/sdk/typescript/lib/generated/models/StreamTransactionsRequestEventFilterItem.ts b/sdk/typescript/lib/generated/models/StreamTransactionsRequestEventFilterItem.ts index 837476a81..40ef0aa40 100644 --- a/sdk/typescript/lib/generated/models/StreamTransactionsRequestEventFilterItem.ts +++ b/sdk/typescript/lib/generated/models/StreamTransactionsRequestEventFilterItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StreamTransactionsResponse.ts b/sdk/typescript/lib/generated/models/StreamTransactionsResponse.ts index e4bad3872..0afcfe26b 100644 --- a/sdk/typescript/lib/generated/models/StreamTransactionsResponse.ts +++ b/sdk/typescript/lib/generated/models/StreamTransactionsResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/StreamTransactionsResponseAllOf.ts b/sdk/typescript/lib/generated/models/StreamTransactionsResponseAllOf.ts index 365f85c14..290d65373 100644 --- a/sdk/typescript/lib/generated/models/StreamTransactionsResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/StreamTransactionsResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionBalanceChanges.ts b/sdk/typescript/lib/generated/models/TransactionBalanceChanges.ts index e089e8516..24ecac86f 100644 --- a/sdk/typescript/lib/generated/models/TransactionBalanceChanges.ts +++ b/sdk/typescript/lib/generated/models/TransactionBalanceChanges.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -40,18 +40,21 @@ import { export interface TransactionBalanceChanges { /** * A list of all fee-related fungible balance changes per entity and resource. + * @type {Array} * @memberof TransactionBalanceChanges */ fungible_fee_balance_changes: Array; /** * A list of all non-fee-related fungible balance changes per entity and resource. + * @type {Array} * @memberof TransactionBalanceChanges */ fungible_balance_changes: Array; /** * A list of all non-fungible changes per entity and resource. + * @type {Array} * @memberof TransactionBalanceChanges */ diff --git a/sdk/typescript/lib/generated/models/TransactionCommittedDetailsRequest.ts b/sdk/typescript/lib/generated/models/TransactionCommittedDetailsRequest.ts index 3d9e11d9c..a29f3294d 100644 --- a/sdk/typescript/lib/generated/models/TransactionCommittedDetailsRequest.ts +++ b/sdk/typescript/lib/generated/models/TransactionCommittedDetailsRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionCommittedDetailsRequestAllOf.ts b/sdk/typescript/lib/generated/models/TransactionCommittedDetailsRequestAllOf.ts index 9cd01ce7c..04655d00f 100644 --- a/sdk/typescript/lib/generated/models/TransactionCommittedDetailsRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/TransactionCommittedDetailsRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionCommittedDetailsResponse.ts b/sdk/typescript/lib/generated/models/TransactionCommittedDetailsResponse.ts index 3d216d013..49a3727ad 100644 --- a/sdk/typescript/lib/generated/models/TransactionCommittedDetailsResponse.ts +++ b/sdk/typescript/lib/generated/models/TransactionCommittedDetailsResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionCommittedDetailsResponseAllOf.ts b/sdk/typescript/lib/generated/models/TransactionCommittedDetailsResponseAllOf.ts index a496834a9..9fcc1c0ca 100644 --- a/sdk/typescript/lib/generated/models/TransactionCommittedDetailsResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/TransactionCommittedDetailsResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionConstructionResponse.ts b/sdk/typescript/lib/generated/models/TransactionConstructionResponse.ts index 576cc4b9f..b6ddacf51 100644 --- a/sdk/typescript/lib/generated/models/TransactionConstructionResponse.ts +++ b/sdk/typescript/lib/generated/models/TransactionConstructionResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionDetailsOptIns.ts b/sdk/typescript/lib/generated/models/TransactionDetailsOptIns.ts index aba25e69d..bf5a5c0e9 100644 --- a/sdk/typescript/lib/generated/models/TransactionDetailsOptIns.ts +++ b/sdk/typescript/lib/generated/models/TransactionDetailsOptIns.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -73,10 +73,17 @@ export interface TransactionDetailsOptIns { * @memberof TransactionDetailsOptIns */ affected_global_entities?: boolean; + /** + * if set to `true`, manifest instructions for user transactions are returned. + * @type {boolean} + * @memberof TransactionDetailsOptIns + */ + manifest_instructions?: boolean; /** * if set to `true`, returns the fungible and non-fungible balance changes. - * - * **Warning!** This opt-in might be missing for recently committed transactions, in that case a `null` value will be returned. Retry the request until non-null value is returned. + +**Warning!** This opt-in might be missing for recently committed transactions, in that case a `null` value will be returned. Retry the request until non-null value is returned. + * @type {boolean} * @memberof TransactionDetailsOptIns */ @@ -111,6 +118,7 @@ export function TransactionDetailsOptInsFromJSONTyped(json: any, ignoreDiscrimin 'receipt_events': !exists(json, 'receipt_events') ? undefined : json['receipt_events'], 'receipt_output': !exists(json, 'receipt_output') ? undefined : json['receipt_output'], 'affected_global_entities': !exists(json, 'affected_global_entities') ? undefined : json['affected_global_entities'], + 'manifest_instructions': !exists(json, 'manifest_instructions') ? undefined : json['manifest_instructions'], 'balance_changes': !exists(json, 'balance_changes') ? undefined : json['balance_changes'], }; } @@ -133,6 +141,7 @@ export function TransactionDetailsOptInsToJSON(value?: TransactionDetailsOptIns 'receipt_events': value.receipt_events, 'receipt_output': value.receipt_output, 'affected_global_entities': value.affected_global_entities, + 'manifest_instructions': value.manifest_instructions, 'balance_changes': value.balance_changes, }; } diff --git a/sdk/typescript/lib/generated/models/TransactionFungibleBalanceChanges.ts b/sdk/typescript/lib/generated/models/TransactionFungibleBalanceChanges.ts index 3fbaf70d5..bd97963e6 100644 --- a/sdk/typescript/lib/generated/models/TransactionFungibleBalanceChanges.ts +++ b/sdk/typescript/lib/generated/models/TransactionFungibleBalanceChanges.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -33,6 +33,7 @@ export interface TransactionFungibleBalanceChanges { resource_address: string; /** * The string-encoded decimal representing the amount of change for the fungible resource. + * @type {string} * @memberof TransactionFungibleBalanceChanges */ diff --git a/sdk/typescript/lib/generated/models/TransactionFungibleFeeBalanceChangeType.ts b/sdk/typescript/lib/generated/models/TransactionFungibleFeeBalanceChangeType.ts index cd75022ba..c8262bac9 100644 --- a/sdk/typescript/lib/generated/models/TransactionFungibleFeeBalanceChangeType.ts +++ b/sdk/typescript/lib/generated/models/TransactionFungibleFeeBalanceChangeType.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -15,12 +15,13 @@ /** * Indicates fee-related balance changes, for example: - * - * - payment of the fee including tip and royalty, - * - distribution of royalties, - * - distribution of the fee and tip to the consensus-manager, for distributing to the relevant validator/s at end of epoch. - * - * See https://www.radixdlt.com/blog/how-fees-work-in-babylon for further information on how fee payment works at Babylon. + +- payment of the fee including tip and royalty, +- distribution of royalties, +- distribution of the fee and tip to the consensus-manager, for distributing to the relevant validator/s at end of epoch. + +See https://www.radixdlt.com/blog/how-fees-work-in-babylon for further information on how fee payment works at Babylon. + * @export */ export const TransactionFungibleFeeBalanceChangeType = { diff --git a/sdk/typescript/lib/generated/models/TransactionFungibleFeeBalanceChanges.ts b/sdk/typescript/lib/generated/models/TransactionFungibleFeeBalanceChanges.ts index ba1508d0b..ce986a020 100644 --- a/sdk/typescript/lib/generated/models/TransactionFungibleFeeBalanceChanges.ts +++ b/sdk/typescript/lib/generated/models/TransactionFungibleFeeBalanceChanges.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -46,6 +46,7 @@ export interface TransactionFungibleFeeBalanceChanges { resource_address: string; /** * The string-encoded decimal representing the amount of change for the fungible resource. + * @type {string} * @memberof TransactionFungibleFeeBalanceChanges */ diff --git a/sdk/typescript/lib/generated/models/TransactionIntentStatus.ts b/sdk/typescript/lib/generated/models/TransactionIntentStatus.ts index d8005ef63..6ae8513b6 100644 --- a/sdk/typescript/lib/generated/models/TransactionIntentStatus.ts +++ b/sdk/typescript/lib/generated/models/TransactionIntentStatus.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -15,7 +15,8 @@ /** * A more specific intent status. See the description field for further information. - * Note that `CommitPendingOutcomeUnknown` can either result in `CommittedSuccess` or `CommittedFailure`. +Note that `CommitPendingOutcomeUnknown` can either result in `CommittedSuccess` or `CommittedFailure`. + * @export */ export const TransactionIntentStatus = { diff --git a/sdk/typescript/lib/generated/models/TransactionNonFungibleBalanceChanges.ts b/sdk/typescript/lib/generated/models/TransactionNonFungibleBalanceChanges.ts index 298b42a6c..46a5ee0ff 100644 --- a/sdk/typescript/lib/generated/models/TransactionNonFungibleBalanceChanges.ts +++ b/sdk/typescript/lib/generated/models/TransactionNonFungibleBalanceChanges.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionNotFoundError.ts b/sdk/typescript/lib/generated/models/TransactionNotFoundError.ts index d7be2474f..05c641ce9 100644 --- a/sdk/typescript/lib/generated/models/TransactionNotFoundError.ts +++ b/sdk/typescript/lib/generated/models/TransactionNotFoundError.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionNotFoundErrorAllOf.ts b/sdk/typescript/lib/generated/models/TransactionNotFoundErrorAllOf.ts index a976e1529..98c3b42dc 100644 --- a/sdk/typescript/lib/generated/models/TransactionNotFoundErrorAllOf.ts +++ b/sdk/typescript/lib/generated/models/TransactionNotFoundErrorAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionPayloadGatewayHandlingStatus.ts b/sdk/typescript/lib/generated/models/TransactionPayloadGatewayHandlingStatus.ts index f879e55a2..242f97712 100644 --- a/sdk/typescript/lib/generated/models/TransactionPayloadGatewayHandlingStatus.ts +++ b/sdk/typescript/lib/generated/models/TransactionPayloadGatewayHandlingStatus.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -15,6 +15,7 @@ /** * A status concerning the Gateway's handling status of this pending transaction. + * @export */ export const TransactionPayloadGatewayHandlingStatus = { diff --git a/sdk/typescript/lib/generated/models/TransactionPayloadStatus.ts b/sdk/typescript/lib/generated/models/TransactionPayloadStatus.ts index 42a90a184..3e2a59241 100644 --- a/sdk/typescript/lib/generated/models/TransactionPayloadStatus.ts +++ b/sdk/typescript/lib/generated/models/TransactionPayloadStatus.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -15,6 +15,7 @@ /** * A more specific payload status. See the description field for further information. + * @export */ export const TransactionPayloadStatus = { diff --git a/sdk/typescript/lib/generated/models/TransactionPreviewRequest.ts b/sdk/typescript/lib/generated/models/TransactionPreviewRequest.ts index 44390e8ac..17ddee4c9 100644 --- a/sdk/typescript/lib/generated/models/TransactionPreviewRequest.ts +++ b/sdk/typescript/lib/generated/models/TransactionPreviewRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionPreviewRequestFlags.ts b/sdk/typescript/lib/generated/models/TransactionPreviewRequestFlags.ts index c8a947450..e37421a3f 100644 --- a/sdk/typescript/lib/generated/models/TransactionPreviewRequestFlags.ts +++ b/sdk/typescript/lib/generated/models/TransactionPreviewRequestFlags.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionPreviewResponse.ts b/sdk/typescript/lib/generated/models/TransactionPreviewResponse.ts index 119128bf7..20370fbfd 100644 --- a/sdk/typescript/lib/generated/models/TransactionPreviewResponse.ts +++ b/sdk/typescript/lib/generated/models/TransactionPreviewResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -34,6 +34,7 @@ export interface TransactionPreviewResponse { encoded_receipt: string; /** * This type is defined in the Core API as `TransactionReceipt`. See the Core API documentation for more details. + * @type {object} * @memberof TransactionPreviewResponse */ diff --git a/sdk/typescript/lib/generated/models/TransactionPreviewResponseLogsInner.ts b/sdk/typescript/lib/generated/models/TransactionPreviewResponseLogsInner.ts index 9e9347230..3f2d3f268 100644 --- a/sdk/typescript/lib/generated/models/TransactionPreviewResponseLogsInner.ts +++ b/sdk/typescript/lib/generated/models/TransactionPreviewResponseLogsInner.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionReceipt.ts b/sdk/typescript/lib/generated/models/TransactionReceipt.ts index 7c323fec4..eb4c0229f 100644 --- a/sdk/typescript/lib/generated/models/TransactionReceipt.ts +++ b/sdk/typescript/lib/generated/models/TransactionReceipt.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -40,6 +40,7 @@ export interface TransactionReceipt { status?: TransactionStatus; /** * This type is defined in the Core API as `FeeSummary`. See the Core API documentation for more details. + * @type {object} * @memberof TransactionReceipt */ @@ -52,32 +53,37 @@ export interface TransactionReceipt { costing_parameters?: object; /** * This type is defined in the Core API as `FeeDestination`. See the Core API documentation for more details. + * @type {object} * @memberof TransactionReceipt */ fee_destination?: object; /** * This type is defined in the Core API as `FeeSource`. See the Core API documentation for more details. + * @type {object} * @memberof TransactionReceipt */ fee_source?: object; /** * This type is defined in the Core API as `StateUpdates`. See the Core API documentation for more details. + * @type {object} * @memberof TransactionReceipt */ state_updates?: object; /** * Information (number and active validator list) about new epoch if occured. - * This type is defined in the Core API as `NextEpoch`. See the Core API documentation for more details. +This type is defined in the Core API as `NextEpoch`. See the Core API documentation for more details. + * @type {object} * @memberof TransactionReceipt */ next_epoch?: object; /** * The manifest line-by-line engine return data (only present if `status` is `CommittedSuccess`). - * This type is defined in the Core API as `SborData`. See the Core API documentation for more details. +This type is defined in the Core API as `SborData`. See the Core API documentation for more details. + * @type {object} * @memberof TransactionReceipt */ diff --git a/sdk/typescript/lib/generated/models/TransactionStatus.ts b/sdk/typescript/lib/generated/models/TransactionStatus.ts index 291c3a5f6..5dd754aa0 100644 --- a/sdk/typescript/lib/generated/models/TransactionStatus.ts +++ b/sdk/typescript/lib/generated/models/TransactionStatus.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -15,7 +15,8 @@ /** * A top-level intent status, left in for backwards compatibility. - * It doesn't give much information. Rejected means PermanentRejection. +It doesn't give much information. Rejected means PermanentRejection. + * @export */ export const TransactionStatus = { diff --git a/sdk/typescript/lib/generated/models/TransactionStatusRequest.ts b/sdk/typescript/lib/generated/models/TransactionStatusRequest.ts index 3e8448710..eba641ef3 100644 --- a/sdk/typescript/lib/generated/models/TransactionStatusRequest.ts +++ b/sdk/typescript/lib/generated/models/TransactionStatusRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionStatusRequestAllOf.ts b/sdk/typescript/lib/generated/models/TransactionStatusRequestAllOf.ts index 83785a8d0..91c8d74b4 100644 --- a/sdk/typescript/lib/generated/models/TransactionStatusRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/TransactionStatusRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionStatusResponse.ts b/sdk/typescript/lib/generated/models/TransactionStatusResponse.ts index c035a0476..33f7dc06d 100644 --- a/sdk/typescript/lib/generated/models/TransactionStatusResponse.ts +++ b/sdk/typescript/lib/generated/models/TransactionStatusResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -64,6 +64,7 @@ export interface TransactionStatusResponse { intent_status: TransactionIntentStatus; /** * An additional description to clarify the intent status. + * @type {string} * @memberof TransactionStatusResponse */ @@ -76,15 +77,23 @@ export interface TransactionStatusResponse { known_payloads: Array; /** * If the intent was committed, this gives the state version when this intent was committed. + * @type {number} * @memberof TransactionStatusResponse */ committed_state_version?: number | null; + /** + * The epoch number at which the transaction is guaranteed to get permanently rejected by the Network due to exceeded epoch range defined when submitting transaction. + * @type {number} + * @memberof TransactionStatusResponse + */ + permanently_rejects_at_epoch?: number | null; /** * The most relevant error message received, due to a rejection or commit as failure. - * Please note that presence of an error message doesn't imply that the intent - * will definitely reject or fail. This could represent a temporary error (such as out - * of fees), or an error with a payload which doesn't end up being committed. +Please note that presence of an error message doesn't imply that the intent +will definitely reject or fail. This could represent a temporary error (such as out +of fees), or an error with a payload which doesn't end up being committed. + * @type {string} * @memberof TransactionStatusResponse */ @@ -121,6 +130,7 @@ export function TransactionStatusResponseFromJSONTyped(json: any, ignoreDiscrimi 'intent_status_description': json['intent_status_description'], 'known_payloads': ((json['known_payloads'] as Array).map(TransactionStatusResponseKnownPayloadItemFromJSON)), 'committed_state_version': !exists(json, 'committed_state_version') ? undefined : json['committed_state_version'], + 'permanently_rejects_at_epoch': !exists(json, 'permanently_rejects_at_epoch') ? undefined : json['permanently_rejects_at_epoch'], 'error_message': !exists(json, 'error_message') ? undefined : json['error_message'], }; } @@ -140,6 +150,7 @@ export function TransactionStatusResponseToJSON(value?: TransactionStatusRespons 'intent_status_description': value.intent_status_description, 'known_payloads': ((value.known_payloads as Array).map(TransactionStatusResponseKnownPayloadItemToJSON)), 'committed_state_version': value.committed_state_version, + 'permanently_rejects_at_epoch': value.permanently_rejects_at_epoch, 'error_message': value.error_message, }; } diff --git a/sdk/typescript/lib/generated/models/TransactionStatusResponseAllOf.ts b/sdk/typescript/lib/generated/models/TransactionStatusResponseAllOf.ts index 130c2fcfc..2d2679e36 100644 --- a/sdk/typescript/lib/generated/models/TransactionStatusResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/TransactionStatusResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -52,6 +52,7 @@ export interface TransactionStatusResponseAllOf { intent_status: TransactionIntentStatus; /** * An additional description to clarify the intent status. + * @type {string} * @memberof TransactionStatusResponseAllOf */ @@ -64,15 +65,23 @@ export interface TransactionStatusResponseAllOf { known_payloads: Array; /** * If the intent was committed, this gives the state version when this intent was committed. + * @type {number} * @memberof TransactionStatusResponseAllOf */ committed_state_version?: number | null; + /** + * The epoch number at which the transaction is guaranteed to get permanently rejected by the Network due to exceeded epoch range defined when submitting transaction. + * @type {number} + * @memberof TransactionStatusResponseAllOf + */ + permanently_rejects_at_epoch?: number | null; /** * The most relevant error message received, due to a rejection or commit as failure. - * Please note that presence of an error message doesn't imply that the intent - * will definitely reject or fail. This could represent a temporary error (such as out - * of fees), or an error with a payload which doesn't end up being committed. +Please note that presence of an error message doesn't imply that the intent +will definitely reject or fail. This could represent a temporary error (such as out +of fees), or an error with a payload which doesn't end up being committed. + * @type {string} * @memberof TransactionStatusResponseAllOf */ @@ -107,6 +116,7 @@ export function TransactionStatusResponseAllOfFromJSONTyped(json: any, ignoreDis 'intent_status_description': json['intent_status_description'], 'known_payloads': ((json['known_payloads'] as Array).map(TransactionStatusResponseKnownPayloadItemFromJSON)), 'committed_state_version': !exists(json, 'committed_state_version') ? undefined : json['committed_state_version'], + 'permanently_rejects_at_epoch': !exists(json, 'permanently_rejects_at_epoch') ? undefined : json['permanently_rejects_at_epoch'], 'error_message': !exists(json, 'error_message') ? undefined : json['error_message'], }; } @@ -125,6 +135,7 @@ export function TransactionStatusResponseAllOfToJSON(value?: TransactionStatusRe 'intent_status_description': value.intent_status_description, 'known_payloads': ((value.known_payloads as Array).map(TransactionStatusResponseKnownPayloadItemToJSON)), 'committed_state_version': value.committed_state_version, + 'permanently_rejects_at_epoch': value.permanently_rejects_at_epoch, 'error_message': value.error_message, }; } diff --git a/sdk/typescript/lib/generated/models/TransactionStatusResponseKnownPayloadItem.ts b/sdk/typescript/lib/generated/models/TransactionStatusResponseKnownPayloadItem.ts index 654397ad1..923a46d22 100644 --- a/sdk/typescript/lib/generated/models/TransactionStatusResponseKnownPayloadItem.ts +++ b/sdk/typescript/lib/generated/models/TransactionStatusResponseKnownPayloadItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -58,30 +58,33 @@ export interface TransactionStatusResponseKnownPayloadItem { payload_status?: TransactionPayloadStatus; /** * An additional description to clarify the payload status. + * @type {string} * @memberof TransactionStatusResponseKnownPayloadItem */ payload_status_description?: string; /** * The initial error message received for a rejection or failure during transaction execution. - * This will typically be the useful error message, explaining the root cause of the issue. - * Please note that presence of an error message doesn't imply that this payload - * will definitely reject or fail. This could represent an error during a temporary - * rejection (such as out of fees) which then gets resolved (e.g. by depositing money - * to pay the fee), allowing the transaction to be committed. +This will typically be the useful error message, explaining the root cause of the issue. +Please note that presence of an error message doesn't imply that this payload +will definitely reject or fail. This could represent an error during a temporary +rejection (such as out of fees) which then gets resolved (e.g. by depositing money +to pay the fee), allowing the transaction to be committed. + * @type {string} * @memberof TransactionStatusResponseKnownPayloadItem */ error_message?: string | null; /** * The latest error message received for a rejection or failure during transaction execution, - * this is only returned if it is different from the initial error message. - * This is more current than the initial error message, but may be less useful, as it could - * be a message regarding the expiry of the transaction at the end of its epoch validity window. - * Please note that presence of an error message doesn't imply that this payload - * will definitely reject or fail. This could represent an error during a temporary - * rejection (such as out of fees) which then gets resolved (e.g. by depositing money - * to pay the fee), allowing the transaction to be committed. +this is only returned if it is different from the initial error message. +This is more current than the initial error message, but may be less useful, as it could +be a message regarding the expiry of the transaction at the end of its epoch validity window. +Please note that presence of an error message doesn't imply that this payload +will definitely reject or fail. This could represent an error during a temporary +rejection (such as out of fees) which then gets resolved (e.g. by depositing money +to pay the fee), allowing the transaction to be committed. + * @type {string} * @memberof TransactionStatusResponseKnownPayloadItem */ @@ -94,14 +97,16 @@ export interface TransactionStatusResponseKnownPayloadItem { handling_status?: TransactionPayloadGatewayHandlingStatus; /** * Additional reason for why the Gateway has its current handling status. + * @type {string} * @memberof TransactionStatusResponseKnownPayloadItem */ handling_status_reason?: string | null; /** * The most recent error message received when submitting this transaction to the network. - * Please note that the presence of an error message doesn't imply that this transaction - * payload will definitely reject or fail. This could be a transient error. +Please note that the presence of an error message doesn't imply that this transaction +payload will definitely reject or fail. This could be a transient error. + * @type {string} * @memberof TransactionStatusResponseKnownPayloadItem */ diff --git a/sdk/typescript/lib/generated/models/TransactionSubmitRequest.ts b/sdk/typescript/lib/generated/models/TransactionSubmitRequest.ts index b39dcbe5a..ac5a14e82 100644 --- a/sdk/typescript/lib/generated/models/TransactionSubmitRequest.ts +++ b/sdk/typescript/lib/generated/models/TransactionSubmitRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/TransactionSubmitResponse.ts b/sdk/typescript/lib/generated/models/TransactionSubmitResponse.ts index a477d16fa..b0b29dc68 100644 --- a/sdk/typescript/lib/generated/models/TransactionSubmitResponse.ts +++ b/sdk/typescript/lib/generated/models/TransactionSubmitResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidationErrorsAtPath.ts b/sdk/typescript/lib/generated/models/ValidationErrorsAtPath.ts index 304f42a24..08c40c806 100644 --- a/sdk/typescript/lib/generated/models/ValidationErrorsAtPath.ts +++ b/sdk/typescript/lib/generated/models/ValidationErrorsAtPath.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorCollection.ts b/sdk/typescript/lib/generated/models/ValidatorCollection.ts index 65867288d..a337632df 100644 --- a/sdk/typescript/lib/generated/models/ValidatorCollection.ts +++ b/sdk/typescript/lib/generated/models/ValidatorCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorCollectionAllOf.ts b/sdk/typescript/lib/generated/models/ValidatorCollectionAllOf.ts index bb2d70587..3c7d1fbad 100644 --- a/sdk/typescript/lib/generated/models/ValidatorCollectionAllOf.ts +++ b/sdk/typescript/lib/generated/models/ValidatorCollectionAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorCollectionItem.ts b/sdk/typescript/lib/generated/models/ValidatorCollectionItem.ts index 2f759a968..bd2e69252 100644 --- a/sdk/typescript/lib/generated/models/ValidatorCollectionItem.ts +++ b/sdk/typescript/lib/generated/models/ValidatorCollectionItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -76,7 +76,8 @@ export interface ValidatorCollectionItem { pending_owner_stake_unit_unlock_vault: ValidatorVaultItem; /** * Validator inner state representation. - * This type is defined in the Core API as `ValidatorFieldStateValue`. See the Core API documentation for more details. +This type is defined in the Core API as `ValidatorFieldStateValue`. See the Core API documentation for more details. + * @type {object} * @memberof ValidatorCollectionItem */ diff --git a/sdk/typescript/lib/generated/models/ValidatorCollectionItemActiveInEpoch.ts b/sdk/typescript/lib/generated/models/ValidatorCollectionItemActiveInEpoch.ts index 06be01edc..b1cd9f198 100644 --- a/sdk/typescript/lib/generated/models/ValidatorCollectionItemActiveInEpoch.ts +++ b/sdk/typescript/lib/generated/models/ValidatorCollectionItemActiveInEpoch.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactor.ts b/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactor.ts index f0549fe19..819149d72 100644 --- a/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactor.ts +++ b/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactor.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactorCurrent.ts b/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactorCurrent.ts index be8a801f5..dd3b8ff27 100644 --- a/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactorCurrent.ts +++ b/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactorCurrent.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactorPending.ts b/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactorPending.ts index cc9fd5d42..9969a9a9c 100644 --- a/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactorPending.ts +++ b/sdk/typescript/lib/generated/models/ValidatorCollectionItemEffectiveFeeFactorPending.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorUptimeCollection.ts b/sdk/typescript/lib/generated/models/ValidatorUptimeCollection.ts index e37640507..2a32ebf79 100644 --- a/sdk/typescript/lib/generated/models/ValidatorUptimeCollection.ts +++ b/sdk/typescript/lib/generated/models/ValidatorUptimeCollection.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorUptimeCollectionItem.ts b/sdk/typescript/lib/generated/models/ValidatorUptimeCollectionItem.ts index 7aa97efb3..6b731d000 100644 --- a/sdk/typescript/lib/generated/models/ValidatorUptimeCollectionItem.ts +++ b/sdk/typescript/lib/generated/models/ValidatorUptimeCollectionItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorVaultItem.ts b/sdk/typescript/lib/generated/models/ValidatorVaultItem.ts index b23177d11..79ab4de55 100644 --- a/sdk/typescript/lib/generated/models/ValidatorVaultItem.ts +++ b/sdk/typescript/lib/generated/models/ValidatorVaultItem.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorsUptimeRequest.ts b/sdk/typescript/lib/generated/models/ValidatorsUptimeRequest.ts index 5ed64d690..ec349a7a3 100644 --- a/sdk/typescript/lib/generated/models/ValidatorsUptimeRequest.ts +++ b/sdk/typescript/lib/generated/models/ValidatorsUptimeRequest.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). @@ -22,7 +22,8 @@ import { /** * For `at_ledger_state` and `from_ledger_state` you can use one of `state_version`, `epoch`, `epoch` and `round`, or `timestamp`, but then ongoing epoch will be selected and used for querying data. - * i.e for request with `{ "from_state_version" = { "state_version" = 100 }, "at_state_version" = { "state_version" = 300} }` gateway api will check in which epoch transactions with state version 100 and 300 were and then use that as inclusive boundary for request. +i.e for request with `{ "from_state_version" = { "state_version" = 100 }, "at_state_version" = { "state_version" = 300} }` gateway api will check in which epoch transactions with state version 100 and 300 were and then use that as inclusive boundary for request. + * @export * @interface ValidatorsUptimeRequest */ diff --git a/sdk/typescript/lib/generated/models/ValidatorsUptimeRequestAllOf.ts b/sdk/typescript/lib/generated/models/ValidatorsUptimeRequestAllOf.ts index f12225df7..b1b44a7de 100644 --- a/sdk/typescript/lib/generated/models/ValidatorsUptimeRequestAllOf.ts +++ b/sdk/typescript/lib/generated/models/ValidatorsUptimeRequestAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorsUptimeResponse.ts b/sdk/typescript/lib/generated/models/ValidatorsUptimeResponse.ts index 11febef42..d75069b2d 100644 --- a/sdk/typescript/lib/generated/models/ValidatorsUptimeResponse.ts +++ b/sdk/typescript/lib/generated/models/ValidatorsUptimeResponse.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/ValidatorsUptimeResponseAllOf.ts b/sdk/typescript/lib/generated/models/ValidatorsUptimeResponseAllOf.ts index 42ce2da15..1cb4d88f7 100644 --- a/sdk/typescript/lib/generated/models/ValidatorsUptimeResponseAllOf.ts +++ b/sdk/typescript/lib/generated/models/ValidatorsUptimeResponseAllOf.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/sdk/typescript/lib/generated/models/index.ts b/sdk/typescript/lib/generated/models/index.ts index f57b2ab81..c21eff787 100644 --- a/sdk/typescript/lib/generated/models/index.ts +++ b/sdk/typescript/lib/generated/models/index.ts @@ -44,6 +44,7 @@ export * from './InvalidTransactionErrorAllOf'; export * from './LedgerState'; export * from './LedgerStateMixin'; export * from './LedgerStateSelector'; +export * from './ManifestClass'; export * from './MetadataBoolArrayValue'; export * from './MetadataBoolArrayValueAllOf'; export * from './MetadataBoolValue'; @@ -260,6 +261,12 @@ export * from './StateKeyValueStoreDataRequestKeyItem'; export * from './StateKeyValueStoreDataResponse'; export * from './StateKeyValueStoreDataResponseAllOf'; export * from './StateKeyValueStoreDataResponseItem'; +export * from './StateKeyValueStoreKeysCollection'; +export * from './StateKeyValueStoreKeysCollectionAllOf'; +export * from './StateKeyValueStoreKeysRequest'; +export * from './StateKeyValueStoreKeysRequestAllOf'; +export * from './StateKeyValueStoreKeysResponse'; +export * from './StateKeyValueStoreKeysResponseItem'; export * from './StateNonFungibleDataRequest'; export * from './StateNonFungibleDataResponse'; export * from './StateNonFungibleDataResponseAllOf'; @@ -279,6 +286,7 @@ export * from './StateValidatorsListResponse'; export * from './StateValidatorsListResponseAllOf'; export * from './StreamTransactionsRequest'; export * from './StreamTransactionsRequestAllOf'; +export * from './StreamTransactionsRequestAllOfManifestClassFilter'; export * from './StreamTransactionsRequestEventFilterItem'; export * from './StreamTransactionsResponse'; export * from './StreamTransactionsResponseAllOf'; diff --git a/sdk/typescript/lib/generated/runtime.ts b/sdk/typescript/lib/generated/runtime.ts index d55cbea42..abcca86ce 100644 --- a/sdk/typescript/lib/generated/runtime.ts +++ b/sdk/typescript/lib/generated/runtime.ts @@ -4,7 +4,7 @@ * Radix Gateway API - Babylon * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * * * NOTE: This class is auto generated by OpenAPI Generator (https://openapi-generator.tech). diff --git a/src/RadixDlt.CoreApiSdk/generated/Model/CommittedTransactionBalanceChanges.cs b/src/RadixDlt.CoreApiSdk/generated/Model/CommittedTransactionBalanceChanges.cs index 6d9f28253..5b709d478 100644 --- a/src/RadixDlt.CoreApiSdk/generated/Model/CommittedTransactionBalanceChanges.cs +++ b/src/RadixDlt.CoreApiSdk/generated/Model/CommittedTransactionBalanceChanges.cs @@ -90,7 +90,7 @@ namespace RadixDlt.CoreApiSdk.Model { /// - /// CommittedTransactionBalanceChanges + /// The fee-related and non-fee-related balance changes of a transaction, aggregated by resource and global entity within which the change occurred. /// [DataContract(Name = "CommittedTransactionBalanceChanges")] public partial class CommittedTransactionBalanceChanges : IEquatable diff --git a/src/RadixDlt.NetworkGateway.Abstractions/Configuration/Extensions.cs b/src/RadixDlt.NetworkGateway.Abstractions/Configuration/Extensions.cs index 34c49ad31..3df908079 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/Configuration/Extensions.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Configuration/Extensions.cs @@ -64,11 +64,44 @@ using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Options; +using RadixDlt.NetworkGateway.Abstractions.Exceptions; +using RadixDlt.NetworkGateway.Abstractions.Extensions; +using System.Collections.Generic; +using System.Linq; namespace RadixDlt.NetworkGateway.Abstractions.Configuration; public static class Extensions { + public static List GetEnabledNodes(this ICollection nodes) + { + var availableNodes = nodes.Where(n => n.Enabled).ToList(); + + if (!availableNodes.Any()) + { + throw new InvalidConfigurationException("No Core API Nodes have been defined as enabled."); + } + + return availableNodes; + } + + public static CoreApiNode GetRandomEnabledNode(this ICollection nodes) + { + return GetEnabledNodes(nodes).GetRandomBy(x => (double)x.RequestWeighting); + } + + public static CoreApiNode GetRandomEnabledNodeForConstruction(this ICollection nodes) + { + var availableNodes = GetEnabledNodes(nodes).Where(n => !n.DisabledForConstruction).ToArray(); + + if (!availableNodes.Any()) + { + throw new InvalidConfigurationException("No Core API Nodes have been enabled for construction."); + } + + return availableNodes.GetRandomBy(x => (double)x.RequestWeighting); + } + public static IServiceCollection AddValidatableOptionsAtSection(this IServiceCollection services, string configSectionPath) where TOptions : class where TValidator : AbstractOptionsValidator diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Configuration/NetworkOptions.cs b/src/RadixDlt.NetworkGateway.Abstractions/Configuration/NetworkOptions.cs similarity index 83% rename from src/RadixDlt.NetworkGateway.DataAggregator/Configuration/NetworkOptions.cs rename to src/RadixDlt.NetworkGateway.Abstractions/Configuration/NetworkOptions.cs index f5c89b4c8..b8d537be6 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Configuration/NetworkOptions.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Configuration/NetworkOptions.cs @@ -64,10 +64,10 @@ using FluentValidation; using Microsoft.Extensions.Configuration; -using RadixDlt.NetworkGateway.Abstractions.Configuration; using System.Collections.Generic; +using System.Linq; -namespace RadixDlt.NetworkGateway.DataAggregator.Configuration; +namespace RadixDlt.NetworkGateway.Abstractions.Configuration; public sealed class NetworkOptions { @@ -82,6 +82,12 @@ public sealed class NetworkOptions [ConfigurationKeyName("CoreApiHttpProxyAddress")] public string? CoreApiHttpProxyAddress { get; set; } + + [ConfigurationKeyName("MaxAllowedStateVersionLagToBeConsideredSynced")] + public long MaxAllowedStateVersionLagToBeConsideredSynced { get; set; } = 100; + + [ConfigurationKeyName("IgnoreNonSyncedNodes")] + public bool IgnoreNonSyncedNodes { get; set; } = true; } public sealed record CoreApiNode @@ -110,12 +116,6 @@ public sealed record CoreApiNode [ConfigurationKeyName("CoreApiAuthorizationHeader")] public string? CoreApiAuthorizationHeader { get; set; } - /// - /// Relative weighting of the node. - /// - [ConfigurationKeyName("TrustWeighting")] - public decimal TrustWeighting { get; set; } = 1; - /// /// Relative weighting of the node. /// @@ -125,37 +125,40 @@ public sealed record CoreApiNode [ConfigurationKeyName("DisabledForTransactionIndexing")] public bool DisabledForTransactionIndexing { get; set; } - [ConfigurationKeyName("DisabledForTopOfTransactionReadingIfNotFullySynced")] - public bool DisabledForTopOfTransactionReadingIfNotFullySynced { get; set; } - - [ConfigurationKeyName("DisabledForMempool")] - public bool DisabledForMempool { get; set; } - - [ConfigurationKeyName("DisabledForMempoolUnknownTransactionFetching")] - public bool DisabledForMempoolUnknownTransactionFetching { get; set; } - [ConfigurationKeyName("DisabledForConstruction")] public bool DisabledForConstruction { get; set; } } -internal class NetworkOptionsValidator : AbstractOptionsValidator +public sealed class NetworkOptionsValidator : AbstractOptionsValidator { public NetworkOptionsValidator() { - RuleFor(x => x.NetworkName).NotNull(); - RuleFor(x => x.CoreApiNodes).NotNull(); - RuleForEach(x => x.CoreApiNodes).SetValidator(new CoreApiNodeOptionsValidator()); + RuleFor(x => x.NetworkName) + .NotEmpty(); + + RuleFor(x => x.CoreApiNodes) + .NotEmpty() + .Must(x => x.Any(n => n.Enabled)).WithMessage("At least one Core API Node must be enabled"); + + RuleForEach(x => x.CoreApiNodes) + .SetValidator(new CoreApiNodeOptionsValidator()); + + RuleFor(x => x.MaxAllowedStateVersionLagToBeConsideredSynced) + .GreaterThan(0); } } -internal class CoreApiNodeOptionsValidator : AbstractOptionsValidator +public sealed class CoreApiNodeOptionsValidator : AbstractOptionsValidator { public CoreApiNodeOptionsValidator() { When(x => x.Enabled, () => { - RuleFor(x => x.Name).NotNull(); - RuleFor(x => x.CoreApiAddress).NotNull(); + RuleFor(x => x.Name) + .NotEmpty(); + + RuleFor(x => x.CoreApiAddress) + .NotEmpty(); }); } } diff --git a/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/CoreApiNodeProvider.cs b/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/CoreApiNodeProvider.cs new file mode 100644 index 000000000..a42142ebf --- /dev/null +++ b/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/CoreApiNodeProvider.cs @@ -0,0 +1,89 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using RadixDlt.NetworkGateway.Abstractions.Configuration; +using RadixDlt.NetworkGateway.Abstractions.Exceptions; + +namespace RadixDlt.NetworkGateway.Abstractions.CoreCommunications; + +public interface ICoreApiNodeProvider +{ + public CoreApiNode CoreApiNode { get; } +} + +public interface ICoreApiNodeConfigurator +{ + public CoreApiNode CoreApiNode { set; } +} + +public class CoreApiNodeProvider : ICoreApiNodeProvider, ICoreApiNodeConfigurator +{ + private CoreApiNode? _node; + + public CoreApiNode CoreApiNode + { + get => _node ?? throw new InvalidNodeStateException("CoreApiNode in CoreApiNodeProvider should be set at init time"); + set => _node = value; + } +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/CoreCommunications/CoreApiProvider.cs b/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/CoreApiProvider.cs similarity index 89% rename from src/RadixDlt.NetworkGateway.GatewayApi/CoreCommunications/CoreApiProvider.cs rename to src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/CoreApiProvider.cs index c8fe3ca5b..186d48e7a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/CoreCommunications/CoreApiProvider.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/CoreApiProvider.cs @@ -62,36 +62,36 @@ * permissions under this License. */ -using RadixDlt.NetworkGateway.GatewayApi.Configuration; +using RadixDlt.NetworkGateway.Abstractions.Configuration; using System.Net.Http; using System.Net.Http.Headers; using CoreApi = RadixDlt.CoreApiSdk.Api; -namespace RadixDlt.NetworkGateway.GatewayApi.CoreCommunications; +namespace RadixDlt.NetworkGateway.Abstractions.CoreCommunications; -public interface ICoreApiProvider +public interface ICoreApiProvider : ICoreApiNodeProvider { - public CoreApiNode CoreApiNode { get; } - public CoreApi.StatusApi StatusApi { get; } - public CoreApi.TransactionApi TransactionApi { get; } + public CoreApi.StreamApi StreamApi { get; } - public CoreApi.LTSApi LtsApi { get; } + public CoreApi.TransactionApi TransactionApi { get; } } -internal class CoreApiProvider : ICoreApiProvider +public sealed class CoreApiProvider : ICoreApiProvider { public CoreApiNode CoreApiNode { get; } public CoreApi.StatusApi StatusApi { get; } - public CoreApi.TransactionApi TransactionApi { get; } + public CoreApi.StreamApi StreamApi { get; } - public CoreApi.LTSApi LtsApi { get; } + public CoreApi.TransactionApi TransactionApi { get; } - public CoreApiProvider(CoreApiNode coreApiNode, HttpClient httpClient) + public CoreApiProvider(ICoreApiNodeProvider coreApiNodeProvider, HttpClient httpClient) { + var coreApiNode = coreApiNodeProvider.CoreApiNode; + if (!string.IsNullOrWhiteSpace(coreApiNode.CoreApiAuthorizationHeader)) { httpClient.DefaultRequestHeaders.Authorization = AuthenticationHeaderValue.Parse(coreApiNode.CoreApiAuthorizationHeader); @@ -99,7 +99,7 @@ public CoreApiProvider(CoreApiNode coreApiNode, HttpClient httpClient) CoreApiNode = coreApiNode; StatusApi = new CoreApi.StatusApi(httpClient, coreApiNode.CoreApiAddress); + StreamApi = new CoreApi.StreamApi(httpClient, coreApiNode.CoreApiAddress); TransactionApi = new CoreApi.TransactionApi(httpClient, coreApiNode.CoreApiAddress); - LtsApi = new CoreApi.LTSApi(httpClient, coreApiNode.CoreApiAddress); } } diff --git a/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/TransactionSubmitter.cs b/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/TransactionSubmitter.cs index bb740e9c9..c5ba2d4da 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/TransactionSubmitter.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/TransactionSubmitter.cs @@ -73,7 +73,7 @@ namespace RadixDlt.NetworkGateway.Abstractions.CoreCommunications; -public class TransactionSubmitter +public sealed class TransactionSubmitter { public static async Task Submit( SubmitContext submitContext, diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/InvalidNodeStateException.cs b/src/RadixDlt.NetworkGateway.Abstractions/Exceptions/InvalidNodeStateException.cs similarity index 98% rename from src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/InvalidNodeStateException.cs rename to src/RadixDlt.NetworkGateway.Abstractions/Exceptions/InvalidNodeStateException.cs index 01bffe201..9223d6350 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/InvalidNodeStateException.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Exceptions/InvalidNodeStateException.cs @@ -64,7 +64,7 @@ using System; -namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices; +namespace RadixDlt.NetworkGateway.Abstractions.Exceptions; [Serializable] public sealed class InvalidNodeStateException : Exception diff --git a/src/RadixDlt.NetworkGateway.Abstractions/Extensions/EnumerableExtensions.cs b/src/RadixDlt.NetworkGateway.Abstractions/Extensions/EnumerableExtensions.cs index d69b576e8..8206b2520 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/Extensions/EnumerableExtensions.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Extensions/EnumerableExtensions.cs @@ -86,20 +86,6 @@ public static IEnumerable SelectNonNull( } } - public static IEnumerable ExceptInSet( - this IEnumerable source, - IReadOnlySet set - ) - { - foreach (var item in source) - { - if (!set.Contains(item)) - { - yield return item; - } - } - } - public static TItem GetRandomBy(this IEnumerable items, Func weightingSelector) { var allItems = items.ToList(); @@ -124,17 +110,6 @@ public static TItem GetRandomBy(this IEnumerable items, Func(TItem Item, double Result); - - public static List GetWeightedRandomOrdering(this IEnumerable items, Func weightingSelector) - { - return items - .Select(item => new ItemWithResult(item, Random.Shared.NextDouble() * weightingSelector(item))) - .OrderByDescending(x => x.Result) - .Select(x => x.Item) - .ToList(); - } - public static void ForEach(this IEnumerable source, Action callback) { ArgumentNullException.ThrowIfNull(source); diff --git a/src/RadixDlt.NetworkGateway.Abstractions/Model/LedgerTransactionManifestClass.cs b/src/RadixDlt.NetworkGateway.Abstractions/Model/LedgerTransactionManifestClass.cs new file mode 100644 index 000000000..c351d6b50 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.Abstractions/Model/LedgerTransactionManifestClass.cs @@ -0,0 +1,77 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +namespace RadixDlt.NetworkGateway.Abstractions.Model; + +public enum LedgerTransactionManifestClass +{ + General, + Transfer, + ValidatorStake, + ValidatorUnstake, + ValidatorClaim, + AccountDepositSettingsUpdate, + PoolContribution, + PoolRedemption, +} diff --git a/src/RadixDlt.NetworkGateway.Abstractions/Model/LedgerTransactionMarkerType.cs b/src/RadixDlt.NetworkGateway.Abstractions/Model/LedgerTransactionMarkerType.cs index bf3fb6f60..66ea14fca 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/Model/LedgerTransactionMarkerType.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Model/LedgerTransactionMarkerType.cs @@ -70,4 +70,5 @@ public enum LedgerTransactionMarkerType Event, ManifestAddress, AffectedGlobalEntity, + ManifestClass, } diff --git a/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/INetworkAddressConfigProvider.cs b/src/RadixDlt.NetworkGateway.Abstractions/Model/ManifestClassFilter.cs similarity index 91% rename from src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/INetworkAddressConfigProvider.cs rename to src/RadixDlt.NetworkGateway.Abstractions/Model/ManifestClassFilter.cs index 2d6f9f238..22363c968 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/CoreCommunications/INetworkAddressConfigProvider.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Model/ManifestClassFilter.cs @@ -62,17 +62,11 @@ * permissions under this License. */ -using RadixDlt.NetworkGateway.Abstractions.Addressing; +namespace RadixDlt.NetworkGateway.Abstractions.Model; -namespace RadixDlt.NetworkGateway.Abstractions.CoreCommunications; - -public interface INetworkAddressConfigProvider +public class ManifestClassFilter { - string GetNetworkHrpSuffix(); - - HrpDefinition GetHrpDefinition(); - - WellKnownAddresses GetWellKnownAddresses(); + public LedgerTransactionManifestClass Class { get; set; } - AddressTypeDefinition GetAddressTypeDefinition(AddressEntityType entityType); + public bool MatchOnlyMostSpecificType { get; set; } } diff --git a/src/RadixDlt.NetworkGateway.Abstractions/Addressing/AddressException.cs b/src/RadixDlt.NetworkGateway.Abstractions/Network/AddressException.cs similarity index 98% rename from src/RadixDlt.NetworkGateway.Abstractions/Addressing/AddressException.cs rename to src/RadixDlt.NetworkGateway.Abstractions/Network/AddressException.cs index 677256c31..8ae173c7d 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/Addressing/AddressException.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Network/AddressException.cs @@ -64,7 +64,7 @@ using System; -namespace RadixDlt.NetworkGateway.Abstractions.Addressing; +namespace RadixDlt.NetworkGateway.Abstractions.Network; /// /// An Exception thrown when parsing addresses. diff --git a/src/RadixDlt.NetworkGateway.Abstractions/Addressing/Bech32Codec.cs b/src/RadixDlt.NetworkGateway.Abstractions/Network/Bech32Codec.cs similarity index 99% rename from src/RadixDlt.NetworkGateway.Abstractions/Addressing/Bech32Codec.cs rename to src/RadixDlt.NetworkGateway.Abstractions/Network/Bech32Codec.cs index c61229a37..2d1a5afe2 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/Addressing/Bech32Codec.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Network/Bech32Codec.cs @@ -72,7 +72,7 @@ using System.Diagnostics.CodeAnalysis; using System.Text; -namespace RadixDlt.NetworkGateway.Abstractions.Addressing; +namespace RadixDlt.NetworkGateway.Abstractions.Network; /// /// A class for encoding and decoding Bech32 (and Bech32M) strings. diff --git a/src/RadixDlt.NetworkGateway.Abstractions/Network/INetworkConfigurationProvider.cs b/src/RadixDlt.NetworkGateway.Abstractions/Network/INetworkConfigurationProvider.cs new file mode 100644 index 000000000..e64f73966 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.Abstractions/Network/INetworkConfigurationProvider.cs @@ -0,0 +1,197 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using Microsoft.Extensions.DependencyInjection; +using Microsoft.Extensions.Options; +using Nito.AsyncEx; +using RadixDlt.NetworkGateway.Abstractions.Configuration; +using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; +using RadixDlt.NetworkGateway.Abstractions.Extensions; +using System; +using System.Collections.Generic; +using System.Linq; +using System.Threading; +using System.Threading.Tasks; +using CoreModel = RadixDlt.CoreApiSdk.Model; + +namespace RadixDlt.NetworkGateway.Abstractions.Network; + +public interface INetworkConfigurationProvider +{ + public Task GetNetworkConfiguration(CancellationToken token = default); +} + +public sealed class NetworkConfigurationProvider : INetworkConfigurationProvider +{ + private readonly NetworkOptions _networkOptions; + private readonly IServiceProvider _serviceProvider; + private readonly IEnumerable _observers; + private readonly AsyncLazy _factory; + + public NetworkConfigurationProvider( + IOptions networkOptions, + IServiceProvider serviceProvider, + IEnumerable observers) + { + _networkOptions = networkOptions.Value; + _serviceProvider = serviceProvider; + _observers = observers; + _factory = new AsyncLazy(ReadNetworkConfiguration, AsyncLazyFlags.RetryOnFailure); + } + + public Task GetNetworkConfiguration(CancellationToken token = default) + { + return _factory.Task; + } + + private async Task ReadNetworkConfiguration() + { + using var scope = _serviceProvider.CreateScope(); + var coreApiNode = scope.ServiceProvider.GetRequiredService>().CurrentValue.CoreApiNodes.GetRandomEnabledNode(); + scope.ServiceProvider.GetRequiredService().CoreApiNode = coreApiNode; + var coreApiProvider = scope.ServiceProvider.GetRequiredService(); + + try + { + var configuration = await coreApiProvider.StatusApi.StatusNetworkConfigurationPostAsync(); + var status = await coreApiProvider.StatusApi.StatusNetworkStatusPostAsync(new CoreModel.NetworkStatusRequest(_networkOptions.NetworkName)); + + var addressTypeDefinitions = configuration.AddressTypes + .Select(at => new AddressTypeDefinition(Enum.Parse(at.EntityType.ToString(), true), at.HrpPrefix, (byte)at.AddressBytePrefix, at.AddressByteLength)) + .ToArray(); + + string GetHrpPrefix(AddressEntityType entityType) + { + return addressTypeDefinitions.First(at => at.EntityType == entityType).HrpPrefix; + } + + var hrpDefinition = new HrpDefinition( + GlobalPackage: GetHrpPrefix(AddressEntityType.GlobalPackage), + GlobalGenericComponent: GetHrpPrefix(AddressEntityType.GlobalGenericComponent), + InternalGenericComponent: GetHrpPrefix(AddressEntityType.InternalGenericComponent), + GlobalAccount: GetHrpPrefix(AddressEntityType.GlobalAccount), + GlobalVirtualEd25519Account: GetHrpPrefix(AddressEntityType.GlobalVirtualEd25519Account), + GlobalVirtualSecp256k1Account: GetHrpPrefix(AddressEntityType.GlobalVirtualSecp256k1Account), + GlobalValidator: GetHrpPrefix(AddressEntityType.GlobalValidator), + GlobalIdentity: GetHrpPrefix(AddressEntityType.GlobalIdentity), + GlobalVirtualEd25519Identity: GetHrpPrefix(AddressEntityType.GlobalVirtualEd25519Identity), + GlobalVirtualSecp256k1Identity: GetHrpPrefix(AddressEntityType.GlobalVirtualSecp256k1Identity), + GlobalConsensusManager: GetHrpPrefix(AddressEntityType.GlobalConsensusManager), + GlobalFungibleResource: GetHrpPrefix(AddressEntityType.GlobalFungibleResource), + GlobalNonFungibleResource: GetHrpPrefix(AddressEntityType.GlobalNonFungibleResource), + InternalFungibleVault: GetHrpPrefix(AddressEntityType.InternalFungibleVault), + InternalNonFungibleVault: GetHrpPrefix(AddressEntityType.InternalNonFungibleVault), + InternalKeyValueStore: GetHrpPrefix(AddressEntityType.InternalKeyValueStore), + GlobalAccessController: GetHrpPrefix(AddressEntityType.GlobalAccessController) + ); + + var wa = configuration.WellKnownAddresses; + var wellKnownAddresses = new WellKnownAddresses( + Xrd: wa.Xrd, + Secp256k1SignatureVirtualBadge: wa.Secp256k1SignatureVirtualBadge, + Ed25519SignatureVirtualBadge: wa.Ed25519SignatureVirtualBadge, + PackageOfDirectCallerVirtualBadge: wa.PackageOfDirectCallerVirtualBadge, + GlobalCallerVirtualBadge: wa.GlobalCallerVirtualBadge, + SystemTransactionBadge: wa.SystemTransactionBadge, + PackageOwnerBadge: wa.PackageOwnerBadge, + ValidatorOwnerBadge: wa.ValidatorOwnerBadge, + AccountOwnerBadge: wa.AccountOwnerBadge, + IdentityOwnerBadge: wa.IdentityOwnerBadge, + PackagePackage: wa.PackagePackage, + ResourcePackage: wa.ResourcePackage, + AccountPackage: wa.AccountPackage, + IdentityPackage: wa.IdentityPackage, + ConsensusManagerPackage: wa.ConsensusManagerPackage, + AccessControllerPackage: wa.AccessControllerPackage, + TransactionProcessorPackage: wa.TransactionProcessorPackage, + MetadataModulePackage: wa.MetadataModulePackage, + RoyaltyModulePackage: wa.RoyaltyModulePackage, + RoleAssignmentModulePackage: wa.RoleAssignmentModulePackage, + GenesisHelperPackage: wa.GenesisHelperPackage, + FaucetPackage: wa.FaucetPackage, + ConsensusManager: wa.ConsensusManager, + GenesisHelper: wa.GenesisHelper, + Faucet: wa.Faucet, + PoolPackage: wa.PoolPackage, + TransactionTracker: wa.TransactionTracker + ); + + return new NetworkConfiguration( + (byte)configuration.NetworkId, + configuration.Network, + status.GenesisEpochRound.Epoch, + status.GenesisEpochRound.Round, + wellKnownAddresses, + hrpDefinition, + configuration.NetworkHrpSuffix, + addressTypeDefinitions); + } + catch (Exception ex) + { + await _observers.ForEachAsync(x => x.GetNetworkConfigurationFailed(coreApiProvider.CoreApiNode.Name, ex)); + + throw; + } + } +} diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/INodeInitializerObserver.cs b/src/RadixDlt.NetworkGateway.Abstractions/Network/INetworkConfigurationReaderObserver.cs similarity index 94% rename from src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/INodeInitializerObserver.cs rename to src/RadixDlt.NetworkGateway.Abstractions/Network/INetworkConfigurationReaderObserver.cs index cf0f6fab6..13488d8ae 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/INodeInitializerObserver.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Network/INetworkConfigurationReaderObserver.cs @@ -63,10 +63,11 @@ */ using System; +using System.Threading.Tasks; -namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices; +namespace RadixDlt.NetworkGateway.Abstractions.Network; -public interface INodeInitializerObserver +public interface INetworkConfigurationReaderObserver { - void TrackInitializerFaultedException(Type worker, string nodeName, bool isStopRequested, Exception exception); + ValueTask GetNetworkConfigurationFailed(string nodeName, Exception exception); } diff --git a/src/RadixDlt.NetworkGateway.Abstractions/Addressing/RadixAddressCodec.cs b/src/RadixDlt.NetworkGateway.Abstractions/Network/RadixAddressCodec.cs similarity index 99% rename from src/RadixDlt.NetworkGateway.Abstractions/Addressing/RadixAddressCodec.cs rename to src/RadixDlt.NetworkGateway.Abstractions/Network/RadixAddressCodec.cs index 9ecc02293..fa73d4a6e 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/Addressing/RadixAddressCodec.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Network/RadixAddressCodec.cs @@ -69,7 +69,7 @@ using System; -namespace RadixDlt.NetworkGateway.Abstractions.Addressing; +namespace RadixDlt.NetworkGateway.Abstractions.Network; public sealed record DecodedRadixAddress(string Hrp, byte[] Data, Bech32Codec.Variant Variant) { diff --git a/src/RadixDlt.NetworkGateway.Abstractions/Addressing/Records.cs b/src/RadixDlt.NetworkGateway.Abstractions/Network/Records.cs similarity index 93% rename from src/RadixDlt.NetworkGateway.Abstractions/Addressing/Records.cs rename to src/RadixDlt.NetworkGateway.Abstractions/Network/Records.cs index 39be02863..becbf553d 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/Addressing/Records.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/Network/Records.cs @@ -62,7 +62,19 @@ * permissions under this License. */ -namespace RadixDlt.NetworkGateway.Abstractions.Addressing; +using System.Collections.Generic; + +namespace RadixDlt.NetworkGateway.Abstractions.Network; + +public sealed record NetworkConfiguration( + byte Id, + string Name, + long GenesisEpoch, + long GenesisRound, + WellKnownAddresses WellKnownAddresses, + HrpDefinition Hrp, + string HrpSuffix, + ICollection AddressTypeDefinitions); public sealed record HrpDefinition( string GlobalPackage, @@ -104,7 +116,7 @@ public sealed record WellKnownAddresses( string TransactionProcessorPackage, string MetadataModulePackage, string RoyaltyModulePackage, - string AccessRulesPackage, + string RoleAssignmentModulePackage, string GenesisHelperPackage, string FaucetPackage, string ConsensusManager, @@ -138,6 +150,6 @@ public enum AddressEntityType public sealed record AddressTypeDefinition( AddressEntityType EntityType, string HrpPrefix, - int AddressBytePrefix, + byte AddressBytePrefix, int AddressByteLength ); diff --git a/src/RadixDlt.NetworkGateway.Abstractions/RadixDlt.NetworkGateway.Abstractions.csproj b/src/RadixDlt.NetworkGateway.Abstractions/RadixDlt.NetworkGateway.Abstractions.csproj index 461a36fad..15c772c69 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/RadixDlt.NetworkGateway.Abstractions.csproj +++ b/src/RadixDlt.NetworkGateway.Abstractions/RadixDlt.NetworkGateway.Abstractions.csproj @@ -5,6 +5,7 @@ + diff --git a/src/RadixDlt.NetworkGateway.Abstractions/ServiceCollectionExtensions.cs b/src/RadixDlt.NetworkGateway.Abstractions/ServiceCollectionExtensions.cs index cdc8484d0..4f9011e24 100644 --- a/src/RadixDlt.NetworkGateway.Abstractions/ServiceCollectionExtensions.cs +++ b/src/RadixDlt.NetworkGateway.Abstractions/ServiceCollectionExtensions.cs @@ -64,13 +64,23 @@ using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.DependencyInjection.Extensions; +using RadixDlt.NetworkGateway.Abstractions.Network; namespace RadixDlt.NetworkGateway.Abstractions; public static class ServiceCollectionExtensions { - public static void AddNetworkGatewayAbstractions(this IServiceCollection services) + public static IServiceCollection AddNetworkGatewayAbstractions(this IServiceCollection services) { services.TryAddSingleton(); + + return services; + } + + public static IServiceCollection AddNetworkGatewayCoreServices(this IServiceCollection services) + { + services.TryAddSingleton(); + + return services; } } diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Configuration/.editorconfig b/src/RadixDlt.NetworkGateway.DataAggregator/Configuration/.editorconfig deleted file mode 100644 index 538a3a01e..000000000 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Configuration/.editorconfig +++ /dev/null @@ -1,19 +0,0 @@ -# To learn more about .editorconfig see https://aka.ms/editorconfigdocs - -#### This file is to tone-down warnings so they're useful for configuration models at write-time - -[*.cs] - -#### Resharper - see https://www.jetbrains.com/help/rider/EditorConfig_Index.html - -# Get rid of warnings for unused fields or accessors -resharper_unused_auto_property_accessor_global_highlighting = none -resharper_member_can_be_private_global_highlighting = none -resharper_auto_property_can_be_made_get_only_global_highlighting = none - -# Classes instantiating by reading code -resharper_class_never_instantiated_global_highlighting = none - -#### OTHER - -dotnet_diagnostic.SA1623.severity = none # SA1623PropertySummaryDocumentationMustMatchAccessors diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/Interfaces.cs b/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/Interfaces.cs index 6a2cd832b..8e2243cb4 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/Interfaces.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/Interfaces.cs @@ -71,22 +71,6 @@ namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; -public interface ICoreApiProvider -{ - CoreApi.TransactionApi TransactionsApi { get; } - - CoreApi.StreamApi StreamApi { get; } - - CoreApi.StatusApi StatusApi { get; } - - CoreApi.MempoolApi MempoolApi { get; } -} - -public interface INetworkConfigurationReader -{ - Task<(CoreModel.NetworkConfigurationResponse Configuration, CoreModel.NetworkStatusResponse Status)> GetNetworkConfiguration(CancellationToken token); -} - public interface INetworkStatusReader { Task GetNetworkStatus(CancellationToken token); @@ -97,11 +81,6 @@ public interface ITransactionStreamReader Task> GetTransactionStream(long fromStateVersion, int count, CancellationToken token); } -public interface INetworkConfigurationReaderObserver -{ - ValueTask GetNetworkConfigurationFailed(string nodeName, Exception exception); -} - public interface INetworkStatusReaderObserver { ValueTask GetNetworkStatusFailed(string nodeName, Exception exception); diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/NetworkStatusReader.cs b/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/NetworkStatusReader.cs index 0dc778eae..2df1fc6f3 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/NetworkStatusReader.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/NetworkStatusReader.cs @@ -62,13 +62,13 @@ * permissions under this License. */ +using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.DataAggregator.Services; +using RadixDlt.NetworkGateway.Abstractions.Network; using System; using System.Collections.Generic; using System.Threading; using System.Threading.Tasks; -using CoreApi = RadixDlt.CoreApiSdk.Api; using CoreModel = RadixDlt.CoreApiSdk.Model; namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; @@ -76,36 +76,33 @@ namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; internal class NetworkStatusReader : INetworkStatusReader { private readonly INetworkConfigurationProvider _networkConfigurationProvider; - private readonly CoreApi.StatusApi _statusApi; - private readonly INodeConfigProvider _nodeConfigProvider; + private readonly ICoreApiProvider _coreApiProvider; private readonly IEnumerable _observers; public NetworkStatusReader( INetworkConfigurationProvider networkConfigurationProvider, ICoreApiProvider coreApiProvider, - INodeConfigProvider nodeConfigProvider, IEnumerable observers) { _networkConfigurationProvider = networkConfigurationProvider; - _nodeConfigProvider = nodeConfigProvider; + _coreApiProvider = coreApiProvider; _observers = observers; - _statusApi = coreApiProvider.StatusApi; } public async Task GetNetworkStatus(CancellationToken token) { try { - return await _statusApi.StatusNetworkStatusPostAsync( + return await _coreApiProvider.StatusApi.StatusNetworkStatusPostAsync( new CoreModel.NetworkStatusRequest( - network: _networkConfigurationProvider.GetNetworkName() + network: (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Name ), token ); } catch (Exception ex) { - await _observers.ForEachAsync(x => x.GetNetworkStatusFailed(_nodeConfigProvider.CoreApiNode.Name, ex)); + await _observers.ForEachAsync(x => x.GetNetworkStatusFailed(_coreApiProvider.CoreApiNode.Name, ex)); throw; } diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/TransactionStreamReader.cs b/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/TransactionStreamReader.cs index d3513d192..167aca666 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/TransactionStreamReader.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/TransactionStreamReader.cs @@ -62,13 +62,13 @@ * permissions under this License. */ +using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.DataAggregator.Services; +using RadixDlt.NetworkGateway.Abstractions.Network; using System; using System.Collections.Generic; using System.Threading; using System.Threading.Tasks; -using CoreApi = RadixDlt.CoreApiSdk.Api; using CoreClient = RadixDlt.CoreApiSdk.Client; using CoreModel = RadixDlt.CoreApiSdk.Model; @@ -77,29 +77,26 @@ namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; internal class TransactionStreamReader : ITransactionStreamReader { private readonly INetworkConfigurationProvider _networkConfigurationProvider; - private readonly CoreApi.StreamApi _streamApi; - private readonly INodeConfigProvider _nodeConfigProvider; + private readonly ICoreApiProvider _coreApiProvider; private readonly IEnumerable _observers; public TransactionStreamReader( INetworkConfigurationProvider networkConfigurationProvider, ICoreApiProvider coreApiProvider, - INodeConfigProvider nodeConfigProvider, IEnumerable observers) { _networkConfigurationProvider = networkConfigurationProvider; - _nodeConfigProvider = nodeConfigProvider; + _coreApiProvider = coreApiProvider; _observers = observers; - _streamApi = coreApiProvider.StreamApi; } public async Task> GetTransactionStream(long fromStateVersion, int count, CancellationToken token) { try { - return await _streamApi.StreamTransactionsPostWithHttpInfoAsync( + return await _coreApiProvider.StreamApi.StreamTransactionsPostWithHttpInfoAsync( new CoreModel.StreamTransactionsRequest( - network: _networkConfigurationProvider.GetNetworkName(), + network: (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Name, fromStateVersion: fromStateVersion, limit: count, transactionFormatOptions: new CoreModel.TransactionFormatOptions @@ -130,7 +127,7 @@ public TransactionStreamReader( } catch (Exception ex) { - await _observers.ForEachAsync(x => x.GetTransactionsFailed(_nodeConfigProvider.CoreApiNode.Name, ex)); + await _observers.ForEachAsync(x => x.GetTransactionsFailed(_coreApiProvider.CoreApiNode.Name, ex)); throw; } diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeNetworkConfigurationInitializer.cs b/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeNetworkConfigurationInitializer.cs deleted file mode 100644 index b99dd91d1..000000000 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeNetworkConfigurationInitializer.cs +++ /dev/null @@ -1,136 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using Microsoft.Extensions.Logging; -using Microsoft.Extensions.Options; -using RadixDlt.NetworkGateway.DataAggregator.Configuration; -using RadixDlt.NetworkGateway.DataAggregator.Exceptions; -using RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; -using RadixDlt.NetworkGateway.DataAggregator.Services; -using System; -using System.Collections.Generic; -using System.Threading; -using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; - -namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices; - -public sealed class NodeNetworkConfigurationInitializer : NodeInitializer -{ - private readonly IOptionsMonitor _networkGatewayDataAggregatorOptionsMonitor; - private readonly INetworkConfigurationReader _networkConfigurationReader; - private readonly INetworkConfigurationProvider _networkConfigurationProvider; - private readonly ILogger _logger; - - public NodeNetworkConfigurationInitializer( - INodeConfigProvider nodeConfigProvider, - IOptionsMonitor networkGatewayDataAggregatorOptionsMonitor, - INetworkConfigurationReader networkConfigurationReader, - INetworkConfigurationProvider networkConfigurationProvider, - ILogger logger, - IEnumerable observers - ) - : base(nodeConfigProvider.CoreApiNode.Name, observers) - { - _networkGatewayDataAggregatorOptionsMonitor = networkGatewayDataAggregatorOptionsMonitor; - _networkConfigurationReader = networkConfigurationReader; - _networkConfigurationProvider = networkConfigurationProvider; - _logger = logger; - } - - protected override async Task Initialize(CancellationToken token) - { - var network = await ReadNetworkConfigurationFromNode(token); - - if (_networkGatewayDataAggregatorOptionsMonitor.CurrentValue.NetworkName != network.Configuration.Network) - { - throw new NodeInitializationException( - $"The node's network name is {network.Configuration.Network}, not {_networkGatewayDataAggregatorOptionsMonitor.CurrentValue.NetworkName}" - ); - } - - await _networkConfigurationProvider.SetNetworkConfigurationOrAssertMatching(network.Configuration, network.Status, token); - - _logger.LogInformation( - "The node has network name {NodeNetworkName}, with matching config to db ledger and/or any other nodes", - network.Configuration.Network - ); - } - - private async Task<(CoreModel.NetworkConfigurationResponse Configuration, CoreModel.NetworkStatusResponse Status)> ReadNetworkConfigurationFromNode(CancellationToken token) - { - try - { - // Check we can connect to the node, and get the network configuration - return await _networkConfigurationReader.GetNetworkConfiguration(token); - } - catch (Exception innerException) - { - throw new NodeInitializationException( - $"Failed to connect / read network configuration and/or status from node", - innerException - ); - } - } -} diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeWorkersRunner.cs b/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeWorkersRunner.cs index b13d0a04c..a7a584e41 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeWorkersRunner.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeWorkersRunner.cs @@ -104,7 +104,6 @@ private set } } - private readonly List _initializers; private readonly List _workers; private readonly object _statusLock = new(); private readonly ILogger _logger; @@ -130,7 +129,6 @@ public NodeWorkersRunner(ILogger logger, IServiceScope nodeDe _clock = clock; _nodeWorkersOptions = nodeWorkersOptions; _cancellationTokenSource = new CancellationTokenSource(); - _initializers = nodeDependencyInjectionScope.ServiceProvider.GetServices().ToList(); _workers = nodeDependencyInjectionScope.ServiceProvider.GetServices().ToList(); Status = NodeWorkersRunnerStatus.Uninitialized; } @@ -185,6 +183,8 @@ public bool IsHealthy() /// public async Task Initialize(CancellationToken cancellationToken) { + await Task.Yield(); + lock (_statusLock) { switch (Status) @@ -206,18 +206,6 @@ public async Task Initialize(CancellationToken cancellationToken) } _combinedInitializeCancellationTokenSource = CancellationTokenSource.CreateLinkedTokenSource(cancellationToken); - var combinedCancellationToken = _combinedInitializeCancellationTokenSource.Token; - - try - { - await Task.WhenAll(_initializers.Select(i => i.Run(combinedCancellationToken))); - } - catch (Exception ex) - { - _logger.LogInformation(ex, "At least one initializer errored - all workers for the node will now be stopped"); - await StopAllSafe(CancellationToken.None); - throw; - } lock (_statusLock) { @@ -366,7 +354,6 @@ public void Dispose() _runningWorkersCancellationTokenRegistration = null; _logScope?.Dispose(); _logScope = null; - GC.SuppressFinalize(this); } private void SafelyCancelInitializationOrStartup() diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/RadixDlt.NetworkGateway.DataAggregator.csproj b/src/RadixDlt.NetworkGateway.DataAggregator/RadixDlt.NetworkGateway.DataAggregator.csproj index 80a1c5244..3f001c2b4 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/RadixDlt.NetworkGateway.DataAggregator.csproj +++ b/src/RadixDlt.NetworkGateway.DataAggregator/RadixDlt.NetworkGateway.DataAggregator.csproj @@ -8,4 +8,5 @@ + diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/ServiceCollectionExtensions.cs b/src/RadixDlt.NetworkGateway.DataAggregator/ServiceCollectionExtensions.cs index 5734aefd3..53c40fcaf 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/ServiceCollectionExtensions.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/ServiceCollectionExtensions.cs @@ -70,7 +70,6 @@ using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.DataAggregator.Configuration; using RadixDlt.NetworkGateway.DataAggregator.Monitoring; -using RadixDlt.NetworkGateway.DataAggregator.NodeServices; using RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; using RadixDlt.NetworkGateway.DataAggregator.Services; using RadixDlt.NetworkGateway.DataAggregator.Workers.NodeWorkers; @@ -95,7 +94,8 @@ public static DataAggregatorBuilder AddNetworkGatewayDataAggregator(this IServic public static DataAggregatorBuilder AddNetworkGatewayDataAggregatorCore(this IServiceCollection services) { services - .AddNetworkGatewayAbstractions(); + .AddNetworkGatewayAbstractions() + .AddNetworkGatewayCoreServices(); services .AddValidatableOptionsAtSection("DataAggregator:Network") @@ -112,7 +112,6 @@ public static DataAggregatorBuilder AddNetworkGatewayDataAggregatorCore(this ISe // Node-Scoped services AddNodeScopedServices(services); AddTransientApiReaders(services, out var coreApiHttpClientBuilder); - AddNodeInitializers(services); AddNodeWorkers(services); return new DataAggregatorBuilder(services, coreApiHttpClientBuilder); @@ -123,13 +122,14 @@ private static void AddGlobalScopedServices(IServiceCollection services) services.TryAddSingleton(); services.TryAddSingleton(); services.TryAddSingleton(); - services.TryAddSingleton(x => x.GetRequiredService()); services.TryAddSingleton(); } private static void AddNodeScopedServices(IServiceCollection services) { - services.TryAddScoped(); + services.TryAddScoped(); + services.TryAddScoped(sp => sp.GetRequiredService()); + services.TryAddScoped(sp => sp.GetRequiredService()); } private static void AddTransientApiReaders(IServiceCollection services, out IHttpClientBuilder coreApiHttpClientBuilder) @@ -143,19 +143,12 @@ private static void AddTransientApiReaders(IServiceCollection services, out IHtt // We can mock these out in tests // These should be transient so that they don't capture a transient HttpClient services.TryAddTransient(); - services.TryAddTransient(); services.TryAddTransient(); services.TryAddTransient>(provider => provider.GetRequiredService); services.TryAddTransient>(provider => provider.GetRequiredService); } - private static void AddNodeInitializers(IServiceCollection services) - { - // Add node initializers - these will be instantiated by the NodeWorkersRunner.cs and run before the workers start - services.TryAddScoped(); - } - private static void AddNodeWorkers(IServiceCollection services) { // Add node workers - these will be instantiated by the NodeWorkersRunner.cs. diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Services/LedgerTransactionsProcessor.cs b/src/RadixDlt.NetworkGateway.DataAggregator/Services/LedgerTransactionsProcessor.cs index 3438631fb..ec4ceb2a7 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Services/LedgerTransactionsProcessor.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/Services/LedgerTransactionsProcessor.cs @@ -66,12 +66,12 @@ using Microsoft.Extensions.Options; using RadixDlt.NetworkGateway.Abstractions; using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.Abstractions.Utilities; using RadixDlt.NetworkGateway.DataAggregator.Configuration; using RadixDlt.NetworkGateway.DataAggregator.Exceptions; using RadixDlt.NetworkGateway.DataAggregator.Monitoring; using System.Collections.Generic; -using System.Linq; using System.Threading; using System.Threading.Tasks; using CoreModel = RadixDlt.CoreApiSdk.Model; @@ -87,47 +87,47 @@ public sealed class LedgerTransactionsProcessor : ILedgerTransactionsProcessor { private readonly ILogger _logger; private readonly IOptionsMonitor _ledgerConfirmationOptionsMonitor; - private readonly IOptionsMonitor _networkOptionsMonitor; private readonly ISystemStatusService _systemStatusService; private readonly ILedgerExtenderService _ledgerExtenderService; private readonly IEnumerable _observers; private readonly ITopOfLedgerProvider _topOfLedgerProvider; - private readonly IClock _clock; private readonly IFetchedTransactionStore _fetchedTransactionStore; - - private IList TransactionNodes { get; set; } = new List(); + private readonly INetworkConfigurationProvider _networkConfigurationProvider; + private readonly IClock _clock; private LedgerConfirmationOptions Config { get; set; } public LedgerTransactionsProcessor( ILogger logger, IOptionsMonitor ledgerConfirmationOptionsMonitor, - IOptionsMonitor networkOptionsMonitor, ISystemStatusService systemStatusService, ILedgerExtenderService ledgerExtenderService, IEnumerable observers, IFetchedTransactionStore fetchedTransactionStore, - IClock clock, - ITopOfLedgerProvider topOfLedgerProvider) + ITopOfLedgerProvider topOfLedgerProvider, + INetworkConfigurationProvider networkConfigurationProvider, + IClock clock) { _logger = logger; _ledgerConfirmationOptionsMonitor = ledgerConfirmationOptionsMonitor; - _networkOptionsMonitor = networkOptionsMonitor; _systemStatusService = systemStatusService; _ledgerExtenderService = ledgerExtenderService; _observers = observers; - _clock = clock; - _topOfLedgerProvider = topOfLedgerProvider; _fetchedTransactionStore = fetchedTransactionStore; + _topOfLedgerProvider = topOfLedgerProvider; + _clock = clock; + _networkConfigurationProvider = networkConfigurationProvider; Config = _ledgerConfirmationOptionsMonitor.CurrentValue; } public async Task ProcessTransactions(CancellationToken token) { + var networkConfiguration = await _networkConfigurationProvider.GetNetworkConfiguration(token); var lastCommittedTransactionSummary = await _topOfLedgerProvider.GetTopOfLedger(token); await _observers.ForEachAsync(x => x.PreHandleLedgerExtension(_clock.UtcNow)); - PrepareForLedgerExtensionCheck(); + Config = _ledgerConfirmationOptionsMonitor.CurrentValue; + var transactions = ConstructLedgerExtension(lastCommittedTransactionSummary); if (transactions.Count == 0) @@ -146,17 +146,6 @@ public async Task ProcessTransactions(CancellationToken token) await DelayBetweenIngestionBatchesIfRequested(commitReport); } - private void PrepareForLedgerExtensionCheck() - { - TransactionNodes = _networkOptionsMonitor - .CurrentValue - .CoreApiNodes - .Where(n => n.Enabled && !n.DisabledForTransactionIndexing) - .ToList(); - - Config = _ledgerConfirmationOptionsMonitor.CurrentValue; - } - private List ConstructLedgerExtension(TransactionSummary topOfLedger) { var startStateVersion = topOfLedger.StateVersion + 1; diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeStatusProvider.cs b/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeStatusProvider.cs index 537f25d49..81635b574 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeStatusProvider.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeStatusProvider.cs @@ -62,6 +62,7 @@ * permissions under this License. */ +using RadixDlt.NetworkGateway.Abstractions.Exceptions; using RadixDlt.NetworkGateway.Abstractions.Extensions; using RadixDlt.NetworkGateway.DataAggregator.NodeServices; using System.Collections.Concurrent; diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeWorkersRunnerFactory.cs b/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeWorkersRunnerFactory.cs index 9cc683210..d3d8c14c1 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeWorkersRunnerFactory.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeWorkersRunnerFactory.cs @@ -66,6 +66,8 @@ using Microsoft.Extensions.Logging; using Microsoft.Extensions.Options; using RadixDlt.NetworkGateway.Abstractions; +using RadixDlt.NetworkGateway.Abstractions.Configuration; +using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.DataAggregator.Configuration; using RadixDlt.NetworkGateway.DataAggregator.NodeServices; using System; @@ -96,7 +98,7 @@ public NodeWorkersRunnerFactory(ILogger logger, IServiceProvi public NodeWorkersRunner CreateWorkersForNode(CoreApiNode initialCoreApiNode) { var nodeScope = _services.CreateScope(); - nodeScope.ServiceProvider.GetRequiredService().CoreApiNode = initialCoreApiNode; + nodeScope.ServiceProvider.GetRequiredService().CoreApiNode = initialCoreApiNode; var logScope = _logger.BeginScope($"[NODE: {initialCoreApiNode.Name}]"); return new NodeWorkersRunner(_logger, nodeScope, logScope!, nodeScope.ServiceProvider.GetRequiredService(), nodeScope.ServiceProvider.GetRequiredService>()); diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeWorkersRunnerRegistry.cs b/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeWorkersRunnerRegistry.cs index 90596015c..8f5f0f8e7 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeWorkersRunnerRegistry.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/Services/NodeWorkersRunnerRegistry.cs @@ -64,6 +64,8 @@ using Microsoft.Extensions.Logging; using Microsoft.Extensions.Options; +using RadixDlt.NetworkGateway.Abstractions.Configuration; +using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Extensions; using RadixDlt.NetworkGateway.DataAggregator.Configuration; using RadixDlt.NetworkGateway.DataAggregator.NodeServices; diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Workers/GlobalWorkers/NodeConfigurationMonitorWorker.cs b/src/RadixDlt.NetworkGateway.DataAggregator/Workers/GlobalWorkers/NodeConfigurationMonitorWorker.cs index 6e0f407cb..ad39658b8 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Workers/GlobalWorkers/NodeConfigurationMonitorWorker.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/Workers/GlobalWorkers/NodeConfigurationMonitorWorker.cs @@ -65,6 +65,8 @@ using Microsoft.Extensions.Logging; using Microsoft.Extensions.Options; using RadixDlt.NetworkGateway.Abstractions; +using RadixDlt.NetworkGateway.Abstractions.Configuration; +using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Workers; using RadixDlt.NetworkGateway.DataAggregator.Configuration; using RadixDlt.NetworkGateway.DataAggregator.Services; @@ -123,11 +125,7 @@ protected override async Task OnStoppedSuccessfully() private async Task HandleNodeConfiguration(CancellationToken stoppingToken) { - var nodeConfiguration = _networkOptions.CurrentValue.CoreApiNodes; - - var enabledNodes = nodeConfiguration - .Where(n => n.Enabled) - .ToList(); + var enabledNodes = _networkOptions.CurrentValue.CoreApiNodes.GetEnabledNodes(); await _nodeWorkersRunnerRegistry.EnsureCorrectNodeServicesRunning(enabledNodes, stoppingToken); } diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Workers/LedgerSynchronizationWorker.cs b/src/RadixDlt.NetworkGateway.DataAggregator/Workers/LedgerSynchronizationWorker.cs deleted file mode 100644 index eab3ae617..000000000 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Workers/LedgerSynchronizationWorker.cs +++ /dev/null @@ -1,148 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using Microsoft.Extensions.Hosting; -using Microsoft.Extensions.Options; -using RadixDlt.NetworkGateway.DataAggregator.Configuration; -using System; -using System.Linq; -using System.Threading; -using System.Threading.Tasks; - -namespace RadixDlt.NetworkGateway.DataAggregator.Workers; - -public sealed class LedgerSynchronizationWorker : BackgroundService -{ - private readonly DistributedLockService _distributedLockService; - private readonly IOptionsMonitor _optionsMonitor; - - public LedgerSynchronizationWorker(DistributedLockService distributedLockService, IOptionsMonitor optionsMonitor) - { - _distributedLockService = distributedLockService; - _optionsMonitor = optionsMonitor; - } - - protected override async Task ExecuteAsync(CancellationToken stoppingToken) - { - // assume this class is based on LoopedWorker - - using var myVar = _optionsMonitor.OnChange((dao, name) => - { - Console.WriteLine($"Change on DataAggregatorOptions detected! {name}"); - }); - - while (!stoppingToken.IsCancellationRequested) - { - if (!await _distributedLockService.TryAcquire(stoppingToken)) - { - // failed to acquire lock - } - else - { - var distributedLockToken = _distributedLockService.CancellationToken; - - using var finalTokenSource = CancellationTokenSource.CreateLinkedTokenSource(stoppingToken, distributedLockToken); - - var o = _optionsMonitor.CurrentValue; - - Console.WriteLine(nameof(LedgerSynchronizationWorker) - + " --> " - + o.NetworkName - + " (" - + o.CoreApiNodes.Count - + ": " - + string.Join(";", o.CoreApiNodes.Select(n => n.CoreApiAddress)) - + ")"); - } - - await Task.Delay(5_000, stoppingToken); - } - } -} - -public sealed class DistributedLockService : IDisposable -{ - private CancellationTokenSource? _cts; - - public CancellationToken CancellationToken => (_cts ?? throw new InvalidOperationException("Lock hasn't been acquired yet, haven't you forgot to call .TryAcquire()?")).Token; - - public async Task TryAcquire(CancellationToken token = default) - { - await Task.Delay(1, token); - - // acquire token logic here - - if (_cts == null) - { - _cts = new CancellationTokenSource(); - } - - return true; - } - - public void Dispose() - { - _cts?.Dispose(); - } -} diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Workers/NodeWorkers/NodeTransactionFetchWorker.cs b/src/RadixDlt.NetworkGateway.DataAggregator/Workers/NodeWorkers/NodeTransactionFetchWorker.cs index 7371d9919..f6d7d0c3e 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Workers/NodeWorkers/NodeTransactionFetchWorker.cs +++ b/src/RadixDlt.NetworkGateway.DataAggregator/Workers/NodeWorkers/NodeTransactionFetchWorker.cs @@ -98,7 +98,7 @@ private record struct FetchedTransactions(List T /* Dependencies */ private readonly ILogger _logger; private readonly IFetchedTransactionStore _fetchedTransactionStore; - private readonly INodeConfigProvider _nodeConfigProvider; + private readonly ICoreApiNodeProvider _coreApiNodeProvider; private readonly INodeStatusProvider _nodeStatusProvider; private readonly IEnumerable _observers; private readonly IOptionsMonitor _ledgerConfirmationOptionsMonitor; @@ -108,12 +108,12 @@ private record struct FetchedTransactions(List T private readonly ITopOfLedgerProvider _topOfLedgerProvider; /* Properties */ - private string NodeName => _nodeConfigProvider.CoreApiNode.Name; + private string NodeName => _coreApiNodeProvider.CoreApiNode.Name; public NodeTransactionFetchWorker( ILogger logger, IFetchedTransactionStore fetchedTransactionStore, - INodeConfigProvider nodeConfigProvider, + ICoreApiNodeProvider coreApiNodeProvider, IEnumerable observers, IEnumerable nodeWorkerObservers, GatewayModel.IClock clock, @@ -123,11 +123,11 @@ public NodeTransactionFetchWorker( Func transactionStreamReaderFactory, Func networkStatusReaderFactory, ITopOfLedgerProvider topOfLedgerProvider) - : base(logger, nodeConfigProvider.CoreApiNode.Name, _delayBetweenLoopsStrategy, TimeSpan.FromSeconds(60), nodeWorkerObservers, clock) + : base(logger, coreApiNodeProvider.CoreApiNode.Name, _delayBetweenLoopsStrategy, TimeSpan.FromSeconds(60), nodeWorkerObservers, clock) { _logger = logger; _fetchedTransactionStore = fetchedTransactionStore; - _nodeConfigProvider = nodeConfigProvider; + _coreApiNodeProvider = coreApiNodeProvider; _observers = observers; _ledgerConfirmationOptionsMonitor = ledgerConfirmationOptionsMonitor; _nodeStatusProvider = nodeStatusProvider; @@ -139,7 +139,7 @@ public NodeTransactionFetchWorker( public override bool IsEnabledByNodeConfiguration() { - return _nodeConfigProvider.CoreApiNode is { Enabled: true, DisabledForTransactionIndexing: false }; + return _coreApiNodeProvider.CoreApiNode is { Enabled: true, DisabledForTransactionIndexing: false }; } protected override async Task DoWork(CancellationToken cancellationToken) diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Configuration/CoreApiIntegrationOptions.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Configuration/CoreApiIntegrationOptions.cs index 1a5f7097d..f3432bd5d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Configuration/CoreApiIntegrationOptions.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Configuration/CoreApiIntegrationOptions.cs @@ -95,9 +95,6 @@ public sealed class CoreApiIntegrationOptions [ConfigurationKeyName("ResubmissionDelayBackoffExponent")] public double ResubmissionDelayBackoffExponent { get; set; } = 2; - [ConfigurationKeyName("TransactionBalanceChangesMaxDegreeOfParallelism")] - public int TransactionBalanceChangesMaxDegreeOfParallelism { get; set; } = 8; - [ConfigurationKeyName("MaxTransientErrorRetryCount")] public int MaxTransientErrorRetryCount { get; set; } = 3; } @@ -109,7 +106,6 @@ public CoreApiIntegrationOptionsValidator() RuleFor(x => x.SubmitTransactionTimeout).GreaterThan(TimeSpan.Zero); RuleFor(x => x.StopResubmittingAfterSeconds).GreaterThanOrEqualTo(0); RuleFor(x => x.MaxSubmissionAttempts).GreaterThanOrEqualTo(0); - RuleFor(x => x.TransactionBalanceChangesMaxDegreeOfParallelism).GreaterThan(0); RuleFor(x => x.MaxTransientErrorRetryCount).GreaterThanOrEqualTo(0); } } diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Configuration/NetworkOptions.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Configuration/NetworkOptions.cs deleted file mode 100644 index 7bcd8eea7..000000000 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Configuration/NetworkOptions.cs +++ /dev/null @@ -1,147 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using FluentValidation; -using Microsoft.Extensions.Configuration; -using RadixDlt.NetworkGateway.Abstractions.Configuration; -using System.Collections.Generic; - -namespace RadixDlt.NetworkGateway.GatewayApi.Configuration; - -public sealed class NetworkOptions -{ - [ConfigurationKeyName("NetworkName")] - public string NetworkName { get; set; } = null!; - - [ConfigurationKeyName("CoreApiNodes")] - public ICollection CoreApiNodes { get; set; } = new List(); - - [ConfigurationKeyName("DisableCoreApiHttpsCertificateChecks")] - public bool DisableCoreApiHttpsCertificateChecks { get; set; } - - [ConfigurationKeyName("CoreApiHttpProxyAddress")] - public string? CoreApiHttpProxyAddress { get; set; } - - [ConfigurationKeyName("MaxAllowedStateVersionLagToBeConsideredSynced")] - public long MaxAllowedStateVersionLagToBeConsideredSynced { get; set; } = 100; - - [ConfigurationKeyName("IgnoreNonSyncedNodes")] - public bool IgnoreNonSyncedNodes { get; set; } = true; -} - -public sealed record CoreApiNode -{ - /// - /// Whether the node's core API should be used to read from (defaults to true). - /// - [ConfigurationKeyName("Enabled")] - public bool Enabled { get; set; } = true; - - /// - /// A unique name identifying this node - used as the node's id. - /// - [ConfigurationKeyName("Name")] - public string Name { get; set; } = string.Empty; - - /// - /// Address of the node's Core API. - /// - [ConfigurationKeyName("CoreApiAddress")] - public string CoreApiAddress { get; set; } = string.Empty; - - /// - /// AuthorizationHeader - if set, can allow for basic auth. - /// - [ConfigurationKeyName("CoreApiAuthorizationHeader")] - public string? CoreApiAuthorizationHeader { get; set; } = null; - - /// - /// Relative weighting of the node. - /// - [ConfigurationKeyName("RequestWeighting")] - public decimal RequestWeighting { get; set; } = 1; -} - -internal class NetworkOptionsValidator : AbstractOptionsValidator -{ - public NetworkOptionsValidator() - { - RuleFor(x => x.NetworkName).NotNull(); - RuleFor(x => x.CoreApiNodes).NotNull(); - RuleForEach(x => x.CoreApiNodes).SetValidator(new CoreApiNodeOptionsValidator()); - RuleFor(x => x.MaxAllowedStateVersionLagToBeConsideredSynced).GreaterThan(0); - } -} - -internal class CoreApiNodeOptionsValidator : AbstractOptionsValidator -{ - public CoreApiNodeOptionsValidator() - { - When(x => x.Enabled, () => - { - RuleFor(x => x.Name).NotNull(); - RuleFor(x => x.CoreApiAddress).NotNull(); - }); - } -} diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/CoreCommunications/CoreApiHandler.cs b/src/RadixDlt.NetworkGateway.GatewayApi/CoreCommunications/CoreApiHandler.cs deleted file mode 100644 index 66375a81f..000000000 --- a/src/RadixDlt.NetworkGateway.GatewayApi/CoreCommunications/CoreApiHandler.cs +++ /dev/null @@ -1,154 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using RadixDlt.CoreApiSdk.Api; -using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; -using RadixDlt.NetworkGateway.GatewayApi.Configuration; -using RadixDlt.NetworkGateway.GatewayApi.Services; -using System; -using System.Net.Http; -using System.Threading; -using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; - -namespace RadixDlt.NetworkGateway.GatewayApi.CoreCommunications; - -public interface ICoreApiHandler -{ - string GetNetworkName(); - - byte GetNetworkId(); - - CoreApiNode GetCoreNodeConnectedTo(); - - TransactionApi GetTransactionApi(); - - Task> TransactionPreview( - CoreModel.TransactionPreviewRequest request, - CancellationToken token = default); - - Task> TransactionOutcome( - CoreModel.LtsStreamTransactionOutcomesRequest request, - CancellationToken token = default); -} - -/// -/// This should be Scoped to the request, so it picks up a fresh HttpClient per request. -/// By default, this selects a random healthy Core API to handle the request. -/// -internal class CoreApiHandler : ICoreApiHandler -{ - private readonly INetworkConfigurationProvider _networkConfigurationProvider; - private readonly Lazy _coreApiProvider; - - public CoreApiHandler( - INetworkConfigurationProvider networkConfigurationProvider, - ICoreNodesSelectorService coreNodesSelectorService, - HttpClient httpClient) - { - _networkConfigurationProvider = networkConfigurationProvider; - _coreApiProvider = new Lazy(() => ChooseCoreApiProvider(coreNodesSelectorService, httpClient)); - } - - public byte GetNetworkId() - { - return _networkConfigurationProvider.GetNetworkId(); - } - - public string GetNetworkName() - { - return _networkConfigurationProvider.GetNetworkName(); - } - - public CoreApiNode GetCoreNodeConnectedTo() - { - return _coreApiProvider.Value.CoreApiNode; - } - - public TransactionApi GetTransactionApi() - { - return _coreApiProvider.Value.TransactionApi; - } - - public async Task> TransactionPreview( - CoreModel.TransactionPreviewRequest request, - CancellationToken token = default) - { - return await CoreApiErrorWrapper.ResultOrError(() => - _coreApiProvider.Value.TransactionApi.TransactionPreviewPostAsync(request, token)); - } - - public async Task> TransactionOutcome( - CoreModel.LtsStreamTransactionOutcomesRequest request, - CancellationToken token = default) - { - return await CoreApiErrorWrapper.ResultOrError(() => - _coreApiProvider.Value.LtsApi.LtsStreamTransactionOutcomesPostAsync(request, token)); - } - - private static ICoreApiProvider ChooseCoreApiProvider(ICoreNodesSelectorService coreNodesSelectorService, HttpClient httpClient) - { - return new CoreApiProvider(coreNodesSelectorService.GetRandomTopTierCoreNode(), httpClient); - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/CapturedConfigProvider.cs b/src/RadixDlt.NetworkGateway.GatewayApi/GatewayModelExtensions.cs similarity index 76% rename from src/RadixDlt.NetworkGateway.PostgresIntegration/Services/CapturedConfigProvider.cs rename to src/RadixDlt.NetworkGateway.GatewayApi/GatewayModelExtensions.cs index 358d4916d..c2cd294ee 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/CapturedConfigProvider.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/GatewayModelExtensions.cs @@ -62,41 +62,27 @@ * permissions under this License. */ -using Microsoft.EntityFrameworkCore; -using RadixDlt.NetworkGateway.Abstractions.Configuration; -using RadixDlt.NetworkGateway.GatewayApi.Services; -using System.Threading.Tasks; +using RadixDlt.NetworkGateway.Abstractions.Model; +using System; using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; -namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; +namespace RadixDlt.NetworkGateway.GatewayApi; -internal class CapturedConfigProvider : ICapturedConfigProvider +internal static class GatewayModelExtensions { - private readonly ReadOnlyDbContext _dbContext; - - public CapturedConfigProvider(ReadOnlyDbContext dbContext) - { - _dbContext = dbContext; - } - - public async Task CaptureConfiguration() + public static LedgerTransactionManifestClass ToModel(this GatewayModel.ManifestClass input) { - var networkConfiguration = await _dbContext.NetworkConfiguration.AsNoTracking().AnnotateMetricName().SingleOrDefaultAsync(); - - if (networkConfiguration == null) + return input switch { - throw new ConfigurationException("Can't set current configuration from database as it's not there"); - } - - return new CapturedConfig( - networkConfiguration.NetworkId, - networkConfiguration.NetworkName, - networkConfiguration.NetworkHrpSuffix, - networkConfiguration.HrpDefinition, - networkConfiguration.WellKnownAddresses, - networkConfiguration.AddressTypeDefinitions, - networkConfiguration.GenesisEpoch, - networkConfiguration.GenesisRound - ); + GatewayModel.ManifestClass.General => LedgerTransactionManifestClass.General, + GatewayModel.ManifestClass.Transfer => LedgerTransactionManifestClass.Transfer, + GatewayModel.ManifestClass.ValidatorStake => LedgerTransactionManifestClass.ValidatorStake, + GatewayModel.ManifestClass.ValidatorUnstake => LedgerTransactionManifestClass.ValidatorUnstake, + GatewayModel.ManifestClass.ValidatorClaim => LedgerTransactionManifestClass.ValidatorClaim, + GatewayModel.ManifestClass.AccountDepositSettingsUpdate => LedgerTransactionManifestClass.AccountDepositSettingsUpdate, + GatewayModel.ManifestClass.PoolContribution => LedgerTransactionManifestClass.PoolContribution, + GatewayModel.ManifestClass.PoolRedemption => LedgerTransactionManifestClass.PoolRedemption, + _ => throw new ArgumentOutOfRangeException(nameof(input), input, null), + }; } } diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultKeyValueStoreHandler.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultKeyValueStoreHandler.cs index 89ff77d1b..9d49a6b31 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultKeyValueStoreHandler.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultKeyValueStoreHandler.cs @@ -63,8 +63,10 @@ */ using Microsoft.Extensions.Logging; +using Microsoft.Extensions.Options; using RadixDlt.NetworkGateway.Abstractions; using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.GatewayApi.Configuration; using RadixDlt.NetworkGateway.GatewayApi.Services; using System; using System.Collections.Generic; @@ -79,14 +81,33 @@ namespace RadixDlt.NetworkGateway.GatewayApi.Handlers; internal class DefaultKeyValueStoreHandler : IKeyValueStoreHandler { private readonly ILedgerStateQuerier _ledgerStateQuerier; - private readonly IEntityStateQuerier _entityStateQuerier; + private readonly IKeyValueStoreQuerier _keyValueStoreQuerier; private readonly ILogger _logger; + private readonly IOptionsSnapshot _endpointConfiguration; - public DefaultKeyValueStoreHandler(ILedgerStateQuerier ledgerStateQuerier, IEntityStateQuerier entityStateQuerier, ILogger logger) + public DefaultKeyValueStoreHandler( + ILedgerStateQuerier ledgerStateQuerier, + IKeyValueStoreQuerier keyValueStoreQuerier, + ILogger logger, + IOptionsSnapshot endpointConfiguration) { _ledgerStateQuerier = ledgerStateQuerier; - _entityStateQuerier = entityStateQuerier; + _keyValueStoreQuerier = keyValueStoreQuerier; _logger = logger; + _endpointConfiguration = endpointConfiguration; + } + + public async Task Keys(GatewayModel.StateKeyValueStoreKeysRequest request, CancellationToken token = default) + { + var ledgerState = await _ledgerStateQuerier.GetValidLedgerStateForReadRequest(request.AtLedgerState, token); + var cursor = GatewayModel.StateKeyValueStoreItemsCursor.FromCursorString(request.Cursor); + + return await _keyValueStoreQuerier.KeyValueStoreItems( + (EntityAddress)request.KeyValueStoreAddress, + ledgerState, + GatewayModel.OffsetCursor.FromCursorString(request.Cursor)?.Offset ?? 0, + request.LimitPerPage ?? _endpointConfiguration.Value.DefaultPageSize, + token); } public async Task Data(GatewayModel.StateKeyValueStoreDataRequest request, CancellationToken token = default) @@ -94,7 +115,7 @@ public DefaultKeyValueStoreHandler(ILedgerStateQuerier ledgerStateQuerier, IEnti var ledgerState = await _ledgerStateQuerier.GetValidLedgerStateForReadRequest(request.AtLedgerState, token); var keys = ExtractKeys(request.Keys).ToArray(); - return await _entityStateQuerier.KeyValueStoreData((EntityAddress)request.KeyValueStoreAddress, keys, ledgerState, token); + return await _keyValueStoreQuerier.KeyValueStoreData((EntityAddress)request.KeyValueStoreAddress, keys, ledgerState, token); } private IEnumerable ExtractKeys(List keys) diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultTransactionHandler.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultTransactionHandler.cs index bf13cd6e3..d3206eafb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultTransactionHandler.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultTransactionHandler.cs @@ -180,6 +180,16 @@ public DefaultTransactionHandler( ResourceAddress = ef.ResourceAddress != null ? (EntityAddress)ef.ResourceAddress : null, }); }); + request.AccountsWithManifestOwnerMethodCalls?.ForEach(a => searchCriteria.AccountsWithManifestOwnerMethodCalls.Add((EntityAddress)a)); + request.AccountsWithoutManifestOwnerMethodCalls?.ForEach(a => searchCriteria.AccountsWithoutManifestOwnerMethodCalls.Add((EntityAddress)a)); + + searchCriteria.ManifestClassFilter = request.ManifestClassFilter == null + ? null + : new ManifestClassFilter + { + Class = request.ManifestClassFilter.Class.ToModel(), + MatchOnlyMostSpecificType = request.ManifestClassFilter.MatchOnlyMostSpecific, + }; var transactionsPageRequest = new TransactionStreamPageRequest( FromStateVersion: fromLedgerState?.StateVersion, diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/IKeyValueStoreHandler.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/IKeyValueStoreHandler.cs index d6ac8dc0d..e974fccc2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/IKeyValueStoreHandler.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Handlers/IKeyValueStoreHandler.cs @@ -70,5 +70,7 @@ namespace RadixDlt.NetworkGateway.GatewayApi.Handlers; public interface IKeyValueStoreHandler { + Task Keys(GatewayModel.StateKeyValueStoreKeysRequest request, CancellationToken token = default); + Task Data(GatewayModel.StateKeyValueStoreDataRequest request, CancellationToken token = default); } diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/ServiceCollectionExtensions.cs b/src/RadixDlt.NetworkGateway.GatewayApi/ServiceCollectionExtensions.cs index 405b1dc6f..4c1455d14 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/ServiceCollectionExtensions.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/ServiceCollectionExtensions.cs @@ -74,7 +74,6 @@ using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.GatewayApi.AspNetCore; using RadixDlt.NetworkGateway.GatewayApi.Configuration; -using RadixDlt.NetworkGateway.GatewayApi.CoreCommunications; using RadixDlt.NetworkGateway.GatewayApi.Handlers; using RadixDlt.NetworkGateway.GatewayApi.Services; using System.Net; @@ -97,7 +96,8 @@ public static GatewayApiBuilder AddNetworkGatewayApi(this IServiceCollection ser public static GatewayApiBuilder AddNetworkGatewayApiCore(this IServiceCollection services) { services - .AddNetworkGatewayAbstractions(); + .AddNetworkGatewayAbstractions() + .AddNetworkGatewayCoreServices(); services .AddValidatableOptionsAtSection("GatewayApi:Endpoint") @@ -122,6 +122,9 @@ public static GatewayApiBuilder AddNetworkGatewayApiCore(this IServiceCollection // Request-scoped services AddRequestServices(services); + // Node-Scoped services + AddNodeScopedServices(services); + // Transient (pooled) services AddCoreApiHttpClient(services, out var coreApiHttpClientBuilder, out var coreNodeHealthCheckerClientBuilder); @@ -130,15 +133,18 @@ public static GatewayApiBuilder AddNetworkGatewayApiCore(this IServiceCollection private static void AddSingletonServices(IServiceCollection services) { - // Should only contain services without any DBContext or HttpClient - as these both need to be recycled - // semi-regularly - services.TryAddSingleton(); - services.TryAddSingleton(x => x.GetRequiredService()); services.TryAddSingleton(); services.TryAddSingleton(); services.TryAddSingleton(); } + private static void AddNodeScopedServices(IServiceCollection services) + { + services.TryAddScoped(); + services.TryAddScoped(sp => sp.GetRequiredService()); + services.TryAddScoped(sp => sp.GetRequiredService()); + } + private static void AddRequestServices(IServiceCollection services) { services.TryAddScoped(); @@ -154,10 +160,16 @@ private static void AddRequestServices(IServiceCollection services) private static void AddCoreApiHttpClient(IServiceCollection services, out IHttpClientBuilder coreApiHttpClientBuilder, out IHttpClientBuilder coreNodeHealthCheckerClientBuilder) { - // NB - AddHttpClient is essentially like AddTransient, except it provides a HttpClient from the HttpClientFactory - // See https://docs.microsoft.com/en-us/dotnet/architecture/microservices/implement-resilient-applications/use-httpclientfactory-to-implement-resilient-http-requests coreApiHttpClientBuilder = services - .AddHttpClient() + .AddHttpClient((httpClient, serviceProvider) => + { + var nodeProvider = new CoreApiNodeProvider + { + CoreApiNode = serviceProvider.GetRequiredService().GetRandomTopTierCoreNode(), + }; + + return new CoreApiProvider(nodeProvider, httpClient); + }) .AddPolicyHandler((serviceProvider, _) => { var retryCount = serviceProvider.GetRequiredService>().Value.MaxTransientErrorRetryCount; diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Services/CoreNodeHealthChecker.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Services/CoreNodeHealthChecker.cs index 662ecc354..c97d4e36e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Services/CoreNodeHealthChecker.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Services/CoreNodeHealthChecker.cs @@ -64,9 +64,9 @@ using Microsoft.Extensions.Logging; using Microsoft.Extensions.Options; +using RadixDlt.NetworkGateway.Abstractions.Configuration; +using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.GatewayApi.Configuration; -using RadixDlt.NetworkGateway.GatewayApi.CoreCommunications; using System; using System.Collections.Generic; using System.Linq; @@ -82,7 +82,7 @@ public interface ICoreNodeHealthChecker Task CheckCoreNodeHealth(CancellationToken cancellationToken); } -public sealed record CoreNodeHealthResult(Dictionary> CoreApiNodesByStatus); +public sealed record CoreNodeHealthResult(Dictionary> CoreApiNodesByStatus); // Using explicit integers for enum values // because they're used for ordering the nodes (from best to worst). @@ -100,40 +100,37 @@ public enum CoreNodeStatus /// internal class CoreNodeHealthChecker : ICoreNodeHealthChecker { - private readonly ILogger _logger; private readonly HttpClient _httpClient; private readonly ILedgerStateQuerier _ledgerStateQuerier; private readonly IOptionsMonitor _networkOptionsMonitor; private readonly IEnumerable _observers; + private readonly ILogger _logger; public CoreNodeHealthChecker( - ILogger logger, HttpClient httpClient, ILedgerStateQuerier ledgerStateQuerier, IOptionsMonitor networkOptionsMonitor, - IEnumerable observers) + IEnumerable observers, + ILogger logger) { - _logger = logger; _httpClient = httpClient; _ledgerStateQuerier = ledgerStateQuerier; _networkOptionsMonitor = networkOptionsMonitor; _observers = observers; + _logger = logger; } public async Task CheckCoreNodeHealth(CancellationToken cancellationToken) { - var coreNodes = _networkOptionsMonitor.CurrentValue.CoreApiNodes; - var enabledCoreNodes = coreNodes - .Where(n => n.Enabled && !string.IsNullOrWhiteSpace(n.CoreApiAddress)) - .ToList(); + var enabledCoreNodes = _networkOptionsMonitor.CurrentValue.CoreApiNodes.GetEnabledNodes(); if (!enabledCoreNodes.Any()) { _logger.LogError("No Core API Nodes have been defined as enabled"); - return new CoreNodeHealthResult(new Dictionary>()); + return new CoreNodeHealthResult(new Dictionary>()); } - var enabledCoreNodeStateVersionLookupTasks = coreNodes + var enabledCoreNodeStateVersionLookupTasks = enabledCoreNodes .Where(n => n.Enabled && !string.IsNullOrWhiteSpace(n.CoreApiAddress)) .Select(n => GetCoreNodeStateVersion(n, _networkOptionsMonitor.CurrentValue.NetworkName, cancellationToken)); @@ -171,7 +168,7 @@ public async Task CheckCoreNodeHealth(CancellationToken ca return new CoreNodeHealthResult(coreNodesByStatus); } - private CoreNodeStatus DetermineNodeStatus((Configuration.CoreApiNode CoreApiNode, long? NodeStateVersion, System.Exception? Exception) healthCheckData, long topOfLedgerStateVersion) + private CoreNodeStatus DetermineNodeStatus((CoreApiNode CoreApiNode, long? NodeStateVersion, Exception? Exception) healthCheckData, long topOfLedgerStateVersion) { if (healthCheckData.NodeStateVersion == null) { @@ -225,7 +222,7 @@ private CoreNodeStatus DetermineNodeStatus((Configuration.CoreApiNode CoreApiNod string networkName, CancellationToken cancellationToken) { - var coreApiProvider = new CoreApiProvider(coreApiNode, _httpClient); + var coreApiProvider = new CoreApiProvider(new CoreApiNodeProvider { CoreApiNode = coreApiNode, }, _httpClient); var timeoutSeconds = 5; try { diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Services/CoreNodesSelectorService.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Services/CoreNodesSelectorService.cs index 012affff6..004b7f818 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Services/CoreNodesSelectorService.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Services/CoreNodesSelectorService.cs @@ -64,8 +64,8 @@ using Microsoft.Extensions.DependencyInjection; using Microsoft.Extensions.Options; +using RadixDlt.NetworkGateway.Abstractions.Configuration; using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.GatewayApi.Configuration; using RadixDlt.NetworkGateway.GatewayApi.Exceptions; using System; using System.Collections.Generic; @@ -105,8 +105,7 @@ public CoreNodesSelectorService( _allEnabledCoreNodes = networkOptions .CoreApiNodes - .Where(n => n.Enabled && !string.IsNullOrWhiteSpace(n.CoreApiAddress)) - .ToList(); + .GetEnabledNodes(); _nodesInTheTopTierStatus = new List(_allEnabledCoreNodes); } diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Services/ICoreNodeHealthCheckerObserver.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Services/ICoreNodeHealthCheckerObserver.cs index f5302e881..5fb1c4e72 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Services/ICoreNodeHealthCheckerObserver.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Services/ICoreNodeHealthCheckerObserver.cs @@ -62,7 +62,7 @@ * permissions under this License. */ -using RadixDlt.NetworkGateway.GatewayApi.Configuration; +using RadixDlt.NetworkGateway.Abstractions.Configuration; using System; using System.Threading.Tasks; diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Services/IEntityStateQuerier.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Services/IEntityStateQuerier.cs index 21ec50e1a..02e9776dc 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Services/IEntityStateQuerier.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Services/IEntityStateQuerier.cs @@ -132,10 +132,4 @@ public sealed record ResourceVaultsPageRequest(EntityAddress Address, EntityAddr CancellationToken token = default); Task StateValidatorsList(GatewayModel.StateValidatorsListCursor? cursor, GatewayModel.LedgerState ledgerState, CancellationToken token = default); - - Task KeyValueStoreData( - EntityAddress keyValueStoreAddress, - IList keys, - GatewayModel.LedgerState ledgerState, - CancellationToken token = default); } diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/Services/NetworkConfigurationProvider.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Services/IKeyValueStoreQuerier.cs similarity index 85% rename from src/RadixDlt.NetworkGateway.DataAggregator/Services/NetworkConfigurationProvider.cs rename to src/RadixDlt.NetworkGateway.GatewayApi/Services/IKeyValueStoreQuerier.cs index e9a8efda3..001a16b2e 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/Services/NetworkConfigurationProvider.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Services/IKeyValueStoreQuerier.cs @@ -62,24 +62,25 @@ * permissions under this License. */ -using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; +using RadixDlt.NetworkGateway.Abstractions; +using System.Collections.Generic; using System.Threading; using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; -namespace RadixDlt.NetworkGateway.DataAggregator.Services; +namespace RadixDlt.NetworkGateway.GatewayApi.Services; -public interface INetworkConfigurationProvider : INetworkAddressConfigProvider +public interface IKeyValueStoreQuerier { - Task SetNetworkConfigurationOrAssertMatching(CoreModel.NetworkConfigurationResponse inputNetworkConfiguration, CoreModel.NetworkStatusResponse inputNetworkStatus, CancellationToken token); + Task KeyValueStoreData( + EntityAddress keyValueStoreAddress, + IList keys, + GatewayApiSdk.Model.LedgerState ledgerState, + CancellationToken token = default); - Task SaveLedgerNetworkConfigurationToDatabaseOnInitIfNotExists(CancellationToken token); - - byte GetNetworkId(); - - string GetNetworkName(); - - long GetGenesisEpoch(); - - long GetGenesisRound(); + Task KeyValueStoreItems( + EntityAddress keyValueStoreAddress, + GatewayApiSdk.Model.LedgerState ledgerState, + int offset, + int limit, + CancellationToken token = default); } diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionQuerier.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionQuerier.cs index 46665a073..a0a00c95d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionQuerier.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionQuerier.cs @@ -114,4 +114,10 @@ public class TransactionStreamPageRequestSearchCriteria public List ManifestResources { get; set; } = new(); public List AffectedGlobalEntities { get; set; } = new(); + + public List AccountsWithoutManifestOwnerMethodCalls { get; set; } = new(); + + public List AccountsWithManifestOwnerMethodCalls { get; set; } = new(); + + public ManifestClassFilter? ManifestClassFilter { get; set; } } diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Services/NetworkConfigurationProvider.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Services/NetworkConfigurationProvider.cs deleted file mode 100644 index 0ef044d2f..000000000 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Services/NetworkConfigurationProvider.cs +++ /dev/null @@ -1,154 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using RadixDlt.NetworkGateway.Abstractions.Addressing; -using RadixDlt.NetworkGateway.Abstractions.Configuration; -using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; -using System.Linq; -using System.Threading; -using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; -using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; - -namespace RadixDlt.NetworkGateway.GatewayApi.Services; - -public interface INetworkConfigurationProvider : INetworkAddressConfigProvider -{ - Task Initialize(ICapturedConfigProvider capturedConfigProvider, CancellationToken token); - - byte GetNetworkId(); - - string GetNetworkName(); -} - -public sealed record CapturedConfig( - byte NetworkId, - string NetworkName, - string NetworkHrpSuffix, - HrpDefinition HrpDefinition, - WellKnownAddresses WellKnownAddresses, - AddressTypeDefinition[] AddressTypeDefinitions, - long GenesisEpoch, - long GenesisRound); - -public interface ICapturedConfigProvider -{ - Task CaptureConfiguration(); -} - -internal class NetworkConfigurationProvider : INetworkConfigurationProvider -{ - private readonly object _writeLock = new(); - private CapturedConfig? _capturedConfig; - - public async Task Initialize(ICapturedConfigProvider capturedConfigProvider, CancellationToken token) - { - var capturedConfig = await capturedConfigProvider.CaptureConfiguration(); - - lock (_writeLock) - { - if (_capturedConfig != null) - { - return; - } - - _capturedConfig = capturedConfig; - } - } - - public byte GetNetworkId() - { - return GetCapturedConfig().NetworkId; - } - - public string GetNetworkName() - { - return GetCapturedConfig().NetworkName; - } - - public string GetNetworkHrpSuffix() - { - return GetCapturedConfig().NetworkHrpSuffix; - } - - public HrpDefinition GetHrpDefinition() - { - return GetCapturedConfig().HrpDefinition; - } - - public WellKnownAddresses GetWellKnownAddresses() - { - return GetCapturedConfig().WellKnownAddresses; - } - - public AddressTypeDefinition GetAddressTypeDefinition(AddressEntityType entityType) - { - return GetCapturedConfig().AddressTypeDefinitions.First(atd => atd.EntityType == entityType); - } - - private CapturedConfig GetCapturedConfig() - { - return _capturedConfig ?? throw new ConfigurationException("Config hasn't been captured from a Node or from the Database yet."); - } -} diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Services/SubmissionService.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Services/SubmissionService.cs index 7a92e6aeb..b1e095cb4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Services/SubmissionService.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Services/SubmissionService.cs @@ -65,16 +65,16 @@ using Microsoft.Extensions.Logging; using Microsoft.Extensions.Options; using RadixDlt.NetworkGateway.Abstractions.Configuration; +using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.GatewayApi.Configuration; -using RadixDlt.NetworkGateway.GatewayApi.CoreCommunications; using RadixDlt.NetworkGateway.GatewayApi.Exceptions; using System; using System.Collections.Generic; using System.Linq; using System.Threading; using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; using ToolkitModel = RadixEngineToolkit; @@ -87,20 +87,23 @@ public interface ISubmissionService internal class SubmissionService : ISubmissionService { - private readonly ICoreApiHandler _coreApiHandler; + private readonly INetworkConfigurationProvider _networkConfigurationProvider; + private readonly ICoreApiProvider _coreApiProvider; private readonly ISubmissionTrackingService _submissionTrackingService; private readonly IReadOnlyCollection _observers; private readonly IOptionsMonitor _coreApiIntegrationOptions; private readonly ILogger _logger; public SubmissionService( - ICoreApiHandler coreApiHandler, + INetworkConfigurationProvider networkConfigurationProvider, + ICoreApiProvider coreApiProvider, ISubmissionTrackingService submissionTrackingService, IEnumerable observers, IOptionsMonitor coreApiIntegrationOptions, ILogger logger) { - _coreApiHandler = coreApiHandler; + _networkConfigurationProvider = networkConfigurationProvider; + _coreApiProvider = coreApiProvider; _submissionTrackingService = submissionTrackingService; _observers = observers.ToArray(); _coreApiIntegrationOptions = coreApiIntegrationOptions; @@ -114,11 +117,11 @@ public SubmissionService( using var parsedTransaction = await HandlePreSubmissionParseTransaction(transactionBytes); await CheckPendingTransactionEpochValidity(ledgerState, parsedTransaction); - var targetNode = _coreApiHandler.GetCoreNodeConnectedTo(); + var targetNode = _coreApiProvider.CoreApiNode; var options = _coreApiIntegrationOptions.CurrentValue; var submissionResult = await _submissionTrackingService.ObserveSubmissionToGatewayAndSubmitToNetworkIfNew( - _coreApiHandler.GetTransactionApi(), - _coreApiHandler.GetNetworkName(), + _coreApiProvider.TransactionApi, + (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Name, targetNode.Name, new PendingTransactionHandlingConfig( options.MaxSubmissionAttempts, @@ -172,7 +175,7 @@ private async Task CheckPendingTransactionEpochValidity(GatewayModel.LedgerState try { var notarizedTransaction = ToolkitModel.NotarizedTransaction.Decompile(notarizedTransactionBytes); - notarizedTransaction.StaticallyValidate(ToolkitModel.ValidationConfig.Default(_coreApiHandler.GetNetworkId())); + notarizedTransaction.StaticallyValidate(ToolkitModel.ValidationConfig.Default((await _networkConfigurationProvider.GetNetworkConfiguration()).Id)); return notarizedTransaction; } catch (ToolkitModel.RadixEngineToolkitException.TransactionValidationFailed ex) diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionPreviewService.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Services/TransactionPreviewService.cs similarity index 89% rename from src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionPreviewService.cs rename to src/RadixDlt.NetworkGateway.GatewayApi/Services/TransactionPreviewService.cs index 88764ee07..7ec6c47b7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionPreviewService.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Services/TransactionPreviewService.cs @@ -62,8 +62,9 @@ * permissions under this License. */ +using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.GatewayApi.CoreCommunications; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.GatewayApi.Exceptions; using System; using System.Collections.Generic; @@ -71,7 +72,6 @@ using System.Linq; using System.Threading; using System.Threading.Tasks; -using CoreClient = RadixDlt.CoreApiSdk.Client; using CoreModel = RadixDlt.CoreApiSdk.Model; using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; @@ -84,20 +84,23 @@ public interface ITransactionPreviewService internal class TransactionPreviewService : ITransactionPreviewService { - private readonly ICoreApiHandler _coreApiHandler; + private readonly INetworkConfigurationProvider _networkConfigurationProvider; + private readonly ICoreApiProvider _coreApiProvider; private readonly IEnumerable _observers; - public TransactionPreviewService(ICoreApiHandler coreApiHandler, IEnumerable observers) + public TransactionPreviewService(INetworkConfigurationProvider networkConfigurationProvider, ICoreApiProvider coreApiProvider, IEnumerable observers) { - _coreApiHandler = coreApiHandler; + _networkConfigurationProvider = networkConfigurationProvider; + _coreApiProvider = coreApiProvider; _observers = observers; } public async Task HandlePreviewRequest(GatewayModel.TransactionPreviewRequest request, CancellationToken token = default) { + var selectedNode = _coreApiProvider.CoreApiNode; + try { - var selectedNode = _coreApiHandler.GetCoreNodeConnectedTo(); await _observers.ForEachAsync(x => x.PreHandlePreviewRequest(request, selectedNode.Name)); var response = await HandlePreviewAndCreateResponse(request, token); @@ -108,7 +111,6 @@ public TransactionPreviewService(ICoreApiHandler coreApiHandler, IEnumerable x.HandlePreviewRequestFailed(request, selectedNode.Name, ex)); throw; @@ -130,7 +132,7 @@ public TransactionPreviewService(ICoreApiHandler coreApiHandler, IEnumerable(() => + _coreApiProvider.TransactionApi.TransactionPreviewPostAsync(coreRequest, token)); if (result.Succeeded) { diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Validators/ManifestClassFilterValidator.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Validators/ManifestClassFilterValidator.cs new file mode 100644 index 000000000..0b41544fb --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Validators/ManifestClassFilterValidator.cs @@ -0,0 +1,77 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using FluentValidation; +using RadixDlt.NetworkGateway.GatewayApiSdk.Model; + +namespace RadixDlt.NetworkGateway.GatewayApi.Validators; + +internal class ManifestClassFilterValidator : AbstractValidator +{ + public ManifestClassFilterValidator() + { + RuleFor(x => x.Class) + .IsInEnum(); + } +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Validators/RadixAddressValidator.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Validators/RadixAddressValidator.cs index 4f66fe8ad..59eda115f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Validators/RadixAddressValidator.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Validators/RadixAddressValidator.cs @@ -63,8 +63,8 @@ */ using FluentValidation; -using RadixDlt.NetworkGateway.Abstractions.Addressing; using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; +using RadixDlt.NetworkGateway.Abstractions.Network; using System; using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; @@ -72,10 +72,8 @@ namespace RadixDlt.NetworkGateway.GatewayApi.Validators; public sealed class RadixAddressValidator : AbstractValidator { - public RadixAddressValidator(INetworkAddressConfigProvider networkAddressConfigProvider) + public RadixAddressValidator(INetworkConfigurationProvider networkConfigurationProvider) { - var networkHrpSuffix = networkAddressConfigProvider.GetNetworkHrpSuffix(); - RuleFor(x => x) .Custom((address, context) => { @@ -83,13 +81,13 @@ public RadixAddressValidator(INetworkAddressConfigProvider networkAddressConfigP try { + var networkHrpSuffix = networkConfigurationProvider.GetNetworkConfiguration().GetAwaiter().GetResult().HrpSuffix; var decodedAddress = RadixAddressCodec.Decode(address); if (!decodedAddress.Hrp.EndsWith(networkHrpSuffix, StringComparison.OrdinalIgnoreCase)) { context.MessageFormatter.AppendArgument("networkHrpSuffix", networkHrpSuffix); context.AddFailure("'{PropertyName}' doesn't belong to this network. Expected network Hrp suffix: {networkHrpSuffix}"); - return; } } catch (AddressException) diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231122094710_AddLedgerTransactionBalanceChanges.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Validators/StateKeyValueStoreItemsRequestValidator.cs similarity index 78% rename from src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231122094710_AddLedgerTransactionBalanceChanges.cs rename to src/RadixDlt.NetworkGateway.GatewayApi/Validators/StateKeyValueStoreItemsRequestValidator.cs index f3997614e..fa25296f0 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231122094710_AddLedgerTransactionBalanceChanges.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Validators/StateKeyValueStoreItemsRequestValidator.cs @@ -62,31 +62,36 @@ * permissions under this License. */ -using Microsoft.EntityFrameworkCore.Migrations; +using FluentValidation; +using Microsoft.Extensions.Options; +using RadixDlt.NetworkGateway.GatewayApi.Configuration; +using RadixDlt.NetworkGateway.GatewayApiSdk.Model; -#nullable disable +namespace RadixDlt.NetworkGateway.GatewayApi.Validators; -namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations +internal class StateKeyValueStoreItemsRequestValidator : AbstractValidator { - /// - public partial class AddLedgerTransactionBalanceChanges : Migration + public StateKeyValueStoreItemsRequestValidator( + LedgerStateSelectorValidator ledgerStateSelectorValidator, + RadixAddressValidator radixAddressValidator, + IOptionsSnapshot endpointOptionsSnapshot, + PaginableRequestValidator paginableRequestValidator) { - /// - protected override void Up(MigrationBuilder migrationBuilder) - { - migrationBuilder.AddColumn( - name: "balance_changes", - table: "ledger_transactions", - type: "jsonb", - nullable: true); - } + RuleFor(x => x.KeyValueStoreAddress) + .NotEmpty() + .SetValidator(radixAddressValidator); - /// - protected override void Down(MigrationBuilder migrationBuilder) - { - migrationBuilder.DropColumn( - name: "balance_changes", - table: "ledger_transactions"); - } + RuleFor(x => x.AtLedgerState) + .SetValidator(ledgerStateSelectorValidator); + + RuleFor(x => x.Cursor) + .Base64(); + + RuleFor(x => x) + .SetValidator(paginableRequestValidator); + + RuleFor(x => x.LimitPerPage) + .GreaterThan(0) + .LessThanOrEqualTo(endpointOptionsSnapshot.Value.MaxPageSize); } } diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Validators/StreamTransactionsRequestValidator.cs b/src/RadixDlt.NetworkGateway.GatewayApi/Validators/StreamTransactionsRequestValidator.cs index d071963f1..7e612ee75 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Validators/StreamTransactionsRequestValidator.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApi/Validators/StreamTransactionsRequestValidator.cs @@ -107,6 +107,17 @@ public StreamTransactionsRequestValidator( .NotNull() .SetValidator(radixAddressValidator); + RuleForEach(x => x.AccountsWithManifestOwnerMethodCalls) + .NotNull() + .SetValidator(radixAddressValidator); + + RuleForEach(x => x.AccountsWithoutManifestOwnerMethodCalls) + .NotNull() + .SetValidator(radixAddressValidator); + + RuleFor(x => x.ManifestClassFilter) + .SetValidator(new ManifestClassFilterValidator()); + RuleForEach(x => x.EventsFilter) .NotNull() .SetValidator(new StreamTransactionsRequestEventItemValidator(radixAddressValidator)); diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml b/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml index 31f874da7..60f1afc57 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml +++ b/src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml @@ -1,6 +1,6 @@ openapi: 3.0.0 info: - version: v1.3.0 + version: v1.4.0 title: Radix Gateway API - Babylon license: name: The Radix License, Version 1.0 @@ -502,6 +502,12 @@ tags: * `manifest_resources_filter` - allows specifying array of resource addresses. If specified, the response will contain only transactions containing the given resources in the manifest (regardless of their usage). + * `accounts_with_manifest_owner_method_calls` - allows specifying an array of account addresses. If specified, the response will contain only transactions that, for all specified accounts, contain manifest method calls to that account which require the owner role. See the [account docs](https://docs.radixdlt.com/docs/account) for more information. + + * `accounts_without_manifest_owner_method_calls` - allows specifying an array of account addresses. If specified, the response will contain only transactions that, for all specified accounts, do NOT contain manifest method calls to that account which require owner role. See the [account docs](https://docs.radixdlt.com/docs/account) for more information. + + * `manifest_class_filter` - allows filtering to transactions which match the given manifest classification. If specified, the response will contain only transactions which have a class that matches the filter. If `match_only_most_specific` set to true, only transactions where the queried class is most specific will be returned. See the [docs on manifest classification](https://docs.radixdlt.com/docs/conforming-transaction-manifest-types) for more information. + * `affected_global_entities_filter` - allows specifying an array of global addresses. If specified, the response will contain transactions that affected all of the given global entities. A global entity is marked as "affected" by a transaction if any of its state (or its descendents' state) was modified as a result of the transaction. * `events_filter` - filters the transaction stream to transactions which emitted at least one event matching each filter (each filter can be satisfied by a different event). Currently *only* deposit and withdrawal events emitted by an internal vault entity are tracked. For the purpose of filtering, the emitter address is replaced by the global ancestor of the emitter, for example, the top-level account / component which contains the vault which emitted the event. @@ -873,11 +879,99 @@ tags: } ``` + ### Iterating over all `KeyValueStore` keys + + You can use `/state/key-value-store/keys` endpoint to iterate over all keys in certain `KeyValueStore`. + If the queried `KeyValueStore` contains more than one page of keys, a `next_cursor` will be returned, which can be used as `cursor` in the request to fetch further pages. + + i.e: + ``` + /state/key-value-store/keys + + { + "key_value_store_address": "internal_keyvaluestore_tdx_2_1kzjd929eqlzd9n02uuj8jd48705vcrpvhv4mgxnaltrgystnca3qxk" + } + ``` + + Will respond with list of all keys (in both `hex` and `programmatic_json` form) and state version when they were last updated. + + ``` + { + ... + "total_count": 8, + "items": [ + { + "key": { + "raw_hex": "5c0c0131", + "programmatic_json": { + "value": "1", + "kind": "String" + } + }, + "last_updated_at_state_version": 4939670 + }, + ... + ], + "key_value_store_address": "internal_keyvaluestore_tdx_2_1kzjd929eqlzd9n02uuj8jd48705vcrpvhv4mgxnaltrgystnca3qxk" + } + ``` + ### Querying for the content under specific keys - After that you can use `/state/key-value-store/data` endpoint to query the content for given keys. To do that you can either use key in form of `json` or `hex`. + You can either rely on keys returned from `/state/key-value-store/keys` endpoint or construct keys in json form on your own. It's possible if you created that `KeyValueStore` and you know what is the form of keys. + + #### Querying using hex keys + + Simply grab `raw_hex` key returned from `/state/key-value-store/keys` endpoint and call `/state/key-value-store/data` with it as parameter. - The gateway doesn't currently support iterating over keys, although we plan to add APIs which can support this in the near future. For now, a client would need to keep track on their own of all created keys or use lower level APIs to extract that data. + i.e: + ``` + /state/key-value-store/data + + { + "key_value_store_address": "internal_keyvaluestore_tdx_2_1kzjd929eqlzd9n02uuj8jd48705vcrpvhv4mgxnaltrgystnca3qxk", + "keys": [ + { + "key_hex": "5c0c0131" + } + ] + } + ``` + + Will respond with data held under that key: + + ``` + { + ... + "key_value_store_address": "internal_keyvaluestore_tdx_2_1kzjd929eqlzd9n02uuj8jd48705vcrpvhv4mgxnaltrgystnca3qxk", + "entries": [ + { + "key": { + "raw_hex": "5c0c0131", + "programmatic_json": { + "value": "1", + "kind": "String" + } + }, + "value": { + "raw_hex": "5c90588c6d59227f64bd7fc68e38bf7c7013cf179a78d5562ce9378b1378e2fa", + "programmatic_json": { + "value": "internal_vault_tdx_2_1tzxx6kfz0ajt6l7x3cut7lrsz0830xnc64tze6fh3vfh3ch6587c5d", + "kind": "Own", + "type_name": "Vault" + } + }, + "last_updated_at_state_version": 4939415, + "is_locked": false + } + ] + } + ``` + + In our case, we may want to look up information about the vault (for example, the vault's resource address and balance). + This can be done with the `/state/entity/details` endpoint. + + #### Constructing json keys The json keys are specified as programmatic SBOR JSON (which is a recursive data format, with each layer being a discriminated union with the `kind` discriminator). Search for [SBOR on our docs site](https://docs.radixdlt.com) for more information on SBOR and the programmatic SBOR JSON format. @@ -1372,6 +1466,30 @@ paths: "4XX": $ref: "#/components/responses/ErrorResponse" + /state/key-value-store/keys: + post: + operationId: KeyValueStoreKeys + summary: Get KeyValueStore Keys + description: | + Allows to iterate over key value store keys. + tags: + - State + requestBody: + required: true + content: + application/json: + schema: + $ref: "#/components/schemas/StateKeyValueStoreKeysRequest" + responses: + "200": + description: KeyValueStore keys collection + content: + application/json: + schema: + $ref: "#/components/schemas/StateKeyValueStoreKeysResponse" + "4XX": + $ref: "#/components/responses/ErrorResponse" + /state/key-value-store/data: post: operationId: KeyValueStoreData @@ -1656,6 +1774,28 @@ components: # Common Response Types # + ManifestClass: + description: | + High-level manifest class type: + * `General`: A general manifest that involves any amount of arbitrary components and packages where nothing more concrete can be said about the manifest and its nature. + * `Transfer`: A manifest of a 1-to-1 transfer to a one-to-many transfer of resources. + * `PoolContribution`: A manifest that contributed some amount of resources to a liquidity pool that can be a one-resource pool, two-resource pool, or a multi-resource pool. + * `PoolRedemption`: A manifest that redeemed resources from a liquidity pool. Similar to contributions, this can be any of the three pool blueprints available in the pool package. + * `ValidatorStake`: A manifest where XRD is staked to one or more validators. + * `ValidatorUnstake`: A manifest where XRD is unstaked from one or more validators. + * `ValidatorClaim`: A manifest where XRD is claimed from one or more validators. + * `AccountDepositSettingsUpdate`: A manifest that updated the deposit settings of the account. + type: string + enum: + - General + - Transfer + - PoolContribution + - PoolRedemption + - ValidatorStake + - ValidatorUnstake + - ValidatorClaim + - AccountDepositSettingsUpdate + ObjectModuleId: type: string enum: @@ -2072,6 +2212,20 @@ components: $ref: "#/components/schemas/HexString" receipt: $ref: "#/components/schemas/TransactionReceipt" + manifest_instructions: + description: | + A text-representation of a transaction manifest. + This field will be present only for user transactions and when explicitly opted-in using `manifest_instructions` flag. + type: string + nullable: true + manifest_classes: + description: | + A collection of zero or more manifest classes ordered from the most specific class to the least specific one. + This field will be present only for user transactions. + type: array + nullable: true + items: + $ref: "#/components/schemas/ManifestClass" message: type: object description: | @@ -2354,6 +2508,7 @@ components: - metadata_module_package - royalty_module_package - access_rules_package + - role_assignment_module_package - genesis_helper_package - faucet_package - consensus_manager @@ -2401,6 +2556,10 @@ components: royalty_module_package: $ref: "#/components/schemas/Address" access_rules_package: + description: "Obsolete! Use `role_assignment_module_package` instead." + deprecated: true + $ref: "#/components/schemas/Address" + role_assignment_module_package: $ref: "#/components/schemas/Address" genesis_helper_package: $ref: "#/components/schemas/Address" @@ -2615,6 +2774,13 @@ components: type: integer format: int64 nullable: true + permanently_rejects_at_epoch: + description: The epoch number at which the transaction is guaranteed to get permanently rejected by the Network due to exceeded epoch range defined when submitting transaction. + nullable: true + type: integer + format: int64 + minimum: 0 + maximum: 10000000000 error_message: description: | The most relevant error message received, due to a rejection or commit as failure. @@ -2728,6 +2894,10 @@ components: description: if set to `true`, all affected global entities by given transaction are returned. type: boolean default: false + manifest_instructions: + description: if set to `true`, manifest instructions for user transactions are returned. + type: boolean + default: false balance_changes: description: | if set to `true`, returns the fungible and non-fungible balance changes. @@ -2879,6 +3049,24 @@ components: type: array items: $ref: "#/components/schemas/StreamTransactionsRequestEventFilterItem" + accounts_with_manifest_owner_method_calls: + type: array + items: + $ref: "#/components/schemas/Address" + accounts_without_manifest_owner_method_calls: + type: array + items: + $ref: "#/components/schemas/Address" + manifest_class_filter: + type: object + required: + - class + properties: + class: + $ref: "#/components/schemas/ManifestClass" + match_only_most_specific: + type: boolean + default: false order: description: Configures the order of returned result set. Defaults to `desc`. type: string @@ -3122,15 +3310,15 @@ components: codes: $ref: "#/components/schemas/StateEntityDetailsResponsePackageDetailsCodeCollection" vm_type: - description: "Obsolete! Use codes collection" + description: "Obsolete! Use `codes` collection instead." deprecated: true $ref: "#/components/schemas/PackageVmType" code_hash_hex: - description: "Obsolete! Use codes collection" + description: "Obsolete! Use `codes` collection instead." deprecated: true $ref: "#/components/schemas/HexString" code_hex: - description: "Obsolete! Use codes collection" + description: "Obsolete! Use `codes` collection instead." deprecated: true $ref: "#/components/schemas/HexString" royalty_vault_balance: @@ -3585,6 +3773,54 @@ components: last_updated_at_state_version: $ref: "#/components/schemas/LastUpdatedAtStateVersion" + StateKeyValueStoreKeysRequest: + allOf: + - $ref: "#/components/schemas/AtLedgerStateMixin" + - $ref: "#/components/schemas/CursorLimitMixin" + - type: object + required: + - key_value_store_address + properties: + key_value_store_address: + $ref: "#/components/schemas/Address" + example: + key_value_store_address: "" + + StateKeyValueStoreKeysResponse: + allOf: + - $ref: "#/components/schemas/LedgerStateMixin" + - $ref: "#/components/schemas/StateKeyValueStoreKeysCollection" + - type: object + required: + - key_value_store_address + properties: + key_value_store_address: + $ref: "#/components/schemas/Address" + + StateKeyValueStoreKeysCollection: + description: Key value store items collection. + allOf: + - $ref: "#/components/schemas/ResultSetCursorMixin" + - type: object + required: + - items + properties: + items: + type: array + items: + $ref: "#/components/schemas/StateKeyValueStoreKeysResponseItem" + + StateKeyValueStoreKeysResponseItem: + type: object + required: + - key + - last_updated_at_state_version + properties: + key: + $ref: "#/components/schemas/ScryptoSborValue" + last_updated_at_state_version: + $ref: "#/components/schemas/LastUpdatedAtStateVersion" + StateKeyValueStoreDataRequest: allOf: - $ref: "#/components/schemas/AtLedgerStateMixin" diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/Model/StateKeyValueStoreItemsCursor.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/Model/StateKeyValueStoreItemsCursor.cs new file mode 100644 index 000000000..f5e89bf2e --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/Model/StateKeyValueStoreItemsCursor.cs @@ -0,0 +1,84 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using System.Runtime.Serialization; + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model; + +[DataContract] +public sealed record StateKeyValueStoreItemsCursor(long? StateVersionBoundary) +{ + [DataMember(Name = "v", EmitDefaultValue = false)] + public long? StateVersionBoundary { get; set; } = StateVersionBoundary; + + public static StateKeyValueStoreItemsCursor FromCursorString(string cursorString) + { + return Serializations.FromBase64JsonOrDefault(cursorString); + } + + public string ToCursorString() + { + return Serializations.AsBase64Json(this); + } +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/Model/StateKeyValueStoreItemsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/Model/StateKeyValueStoreItemsRequest.cs new file mode 100644 index 000000000..3cf2a81f4 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/Model/StateKeyValueStoreItemsRequest.cs @@ -0,0 +1,69 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model; + +public partial class StateKeyValueStoreKeysRequest : IPaginableRequest +{ +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StateApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StateApi.cs index c2f6122ed..992bf2c58 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StateApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StateApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -239,6 +239,27 @@ public interface IStateApiSync : IApiAccessor /// ApiResponse of StateKeyValueStoreDataResponse ApiResponse KeyValueStoreDataWithHttpInfo(StateKeyValueStoreDataRequest stateKeyValueStoreDataRequest); /// + /// Get KeyValueStore Keys + /// + /// + /// Allows to iterate over key value store keys. + /// + /// Thrown when fails to make API call + /// + /// StateKeyValueStoreKeysResponse + StateKeyValueStoreKeysResponse KeyValueStoreKeys(StateKeyValueStoreKeysRequest stateKeyValueStoreKeysRequest); + + /// + /// Get KeyValueStore Keys + /// + /// + /// Allows to iterate over key value store keys. + /// + /// Thrown when fails to make API call + /// + /// ApiResponse of StateKeyValueStoreKeysResponse + ApiResponse KeyValueStoreKeysWithHttpInfo(StateKeyValueStoreKeysRequest stateKeyValueStoreKeysRequest); + /// /// Get Non-Fungible Data /// /// @@ -511,6 +532,29 @@ public interface IStateApiAsync : IApiAccessor /// Task of ApiResponse (StateKeyValueStoreDataResponse) System.Threading.Tasks.Task> KeyValueStoreDataWithHttpInfoAsync(StateKeyValueStoreDataRequest stateKeyValueStoreDataRequest, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)); /// + /// Get KeyValueStore Keys + /// + /// + /// Allows to iterate over key value store keys. + /// + /// Thrown when fails to make API call + /// + /// Cancellation Token to cancel the request. + /// Task of StateKeyValueStoreKeysResponse + System.Threading.Tasks.Task KeyValueStoreKeysAsync(StateKeyValueStoreKeysRequest stateKeyValueStoreKeysRequest, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)); + + /// + /// Get KeyValueStore Keys + /// + /// + /// Allows to iterate over key value store keys. + /// + /// Thrown when fails to make API call + /// + /// Cancellation Token to cancel the request. + /// Task of ApiResponse (StateKeyValueStoreKeysResponse) + System.Threading.Tasks.Task> KeyValueStoreKeysWithHttpInfoAsync(StateKeyValueStoreKeysRequest stateKeyValueStoreKeysRequest, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)); + /// /// Get Non-Fungible Data /// /// @@ -1657,6 +1701,123 @@ public RadixDlt.NetworkGateway.GatewayApiSdk.Client.ApiResponse + /// Get KeyValueStore Keys Allows to iterate over key value store keys. + /// + /// Thrown when fails to make API call + /// + /// StateKeyValueStoreKeysResponse + public StateKeyValueStoreKeysResponse KeyValueStoreKeys(StateKeyValueStoreKeysRequest stateKeyValueStoreKeysRequest) + { + RadixDlt.NetworkGateway.GatewayApiSdk.Client.ApiResponse localVarResponse = KeyValueStoreKeysWithHttpInfo(stateKeyValueStoreKeysRequest); + return localVarResponse.Data; + } + + /// + /// Get KeyValueStore Keys Allows to iterate over key value store keys. + /// + /// Thrown when fails to make API call + /// + /// ApiResponse of StateKeyValueStoreKeysResponse + public RadixDlt.NetworkGateway.GatewayApiSdk.Client.ApiResponse KeyValueStoreKeysWithHttpInfo(StateKeyValueStoreKeysRequest stateKeyValueStoreKeysRequest) + { + // verify the required parameter 'stateKeyValueStoreKeysRequest' is set + if (stateKeyValueStoreKeysRequest == null) + throw new RadixDlt.NetworkGateway.GatewayApiSdk.Client.ApiException(400, "Missing required parameter 'stateKeyValueStoreKeysRequest' when calling StateApi->KeyValueStoreKeys"); + + RadixDlt.NetworkGateway.GatewayApiSdk.Client.RequestOptions localVarRequestOptions = new RadixDlt.NetworkGateway.GatewayApiSdk.Client.RequestOptions(); + + string[] _contentTypes = new string[] { + "application/json" + }; + + // to determine the Accept header + string[] _accepts = new string[] { + "application/json" + }; + + var localVarContentType = RadixDlt.NetworkGateway.GatewayApiSdk.Client.ClientUtils.SelectHeaderContentType(_contentTypes); + if (localVarContentType != null) localVarRequestOptions.HeaderParameters.Add("Content-Type", localVarContentType); + + var localVarAccept = RadixDlt.NetworkGateway.GatewayApiSdk.Client.ClientUtils.SelectHeaderAccept(_accepts); + if (localVarAccept != null) localVarRequestOptions.HeaderParameters.Add("Accept", localVarAccept); + + localVarRequestOptions.Data = stateKeyValueStoreKeysRequest; + + + // make the HTTP request + var localVarResponse = this.Client.Post("/state/key-value-store/keys", localVarRequestOptions, this.Configuration); + + if (this.ExceptionFactory != null) + { + Exception _exception = this.ExceptionFactory("KeyValueStoreKeys", localVarResponse); + if (_exception != null) throw _exception; + } + + return localVarResponse; + } + + /// + /// Get KeyValueStore Keys Allows to iterate over key value store keys. + /// + /// Thrown when fails to make API call + /// + /// Cancellation Token to cancel the request. + /// Task of StateKeyValueStoreKeysResponse + public async System.Threading.Tasks.Task KeyValueStoreKeysAsync(StateKeyValueStoreKeysRequest stateKeyValueStoreKeysRequest, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)) + { + RadixDlt.NetworkGateway.GatewayApiSdk.Client.ApiResponse localVarResponse = await KeyValueStoreKeysWithHttpInfoAsync(stateKeyValueStoreKeysRequest, cancellationToken).ConfigureAwait(false); + return localVarResponse.Data; + } + + /// + /// Get KeyValueStore Keys Allows to iterate over key value store keys. + /// + /// Thrown when fails to make API call + /// + /// Cancellation Token to cancel the request. + /// Task of ApiResponse (StateKeyValueStoreKeysResponse) + public async System.Threading.Tasks.Task> KeyValueStoreKeysWithHttpInfoAsync(StateKeyValueStoreKeysRequest stateKeyValueStoreKeysRequest, System.Threading.CancellationToken cancellationToken = default(System.Threading.CancellationToken)) + { + // verify the required parameter 'stateKeyValueStoreKeysRequest' is set + if (stateKeyValueStoreKeysRequest == null) + throw new RadixDlt.NetworkGateway.GatewayApiSdk.Client.ApiException(400, "Missing required parameter 'stateKeyValueStoreKeysRequest' when calling StateApi->KeyValueStoreKeys"); + + + RadixDlt.NetworkGateway.GatewayApiSdk.Client.RequestOptions localVarRequestOptions = new RadixDlt.NetworkGateway.GatewayApiSdk.Client.RequestOptions(); + + string[] _contentTypes = new string[] { + "application/json" + }; + + // to determine the Accept header + string[] _accepts = new string[] { + "application/json" + }; + + + var localVarContentType = RadixDlt.NetworkGateway.GatewayApiSdk.Client.ClientUtils.SelectHeaderContentType(_contentTypes); + if (localVarContentType != null) localVarRequestOptions.HeaderParameters.Add("Content-Type", localVarContentType); + + var localVarAccept = RadixDlt.NetworkGateway.GatewayApiSdk.Client.ClientUtils.SelectHeaderAccept(_accepts); + if (localVarAccept != null) localVarRequestOptions.HeaderParameters.Add("Accept", localVarAccept); + + localVarRequestOptions.Data = stateKeyValueStoreKeysRequest; + + + // make the HTTP request + + var localVarResponse = await this.AsynchronousClient.PostAsync("/state/key-value-store/keys", localVarRequestOptions, this.Configuration, cancellationToken).ConfigureAwait(false); + + if (this.ExceptionFactory != null) + { + Exception _exception = this.ExceptionFactory("KeyValueStoreKeys", localVarResponse); + if (_exception != null) throw _exception; + } + + return localVarResponse; + } + /// /// Get Non-Fungible Data Returns data associated with a given non-fungible ID of a given non-fungible resource. /// diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatisticsApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatisticsApi.cs index 8f3aa113c..082f78d60 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatisticsApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatisticsApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatusApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatusApi.cs index edf2a51c1..9d40ed79e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatusApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StatusApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StreamApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StreamApi.cs index d30ceebc9..3f5b63b16 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StreamApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/StreamApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/TransactionApi.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/TransactionApi.cs index a94a7cfa2..776c6cd2b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/TransactionApi.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Api/TransactionApi.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiClient.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiClient.cs index a292c8cb9..0bfc7b36f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiClient.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiClient.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiException.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiException.cs index 43014802d..526e4ffa8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiException.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiException.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiResponse.cs index 6670b942b..131a407ca 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ApiResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ClientUtils.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ClientUtils.cs index d6bd9e3e6..336ae7884 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ClientUtils.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ClientUtils.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Configuration.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Configuration.cs index 3a1ca18ee..1fa22a4f6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Configuration.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Configuration.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -591,7 +591,7 @@ public static string ToDebugReport() string report = "C# SDK (RadixDlt.NetworkGateway.GatewayApiSdk) Debug Report:\n"; report += " OS: " + System.Environment.OSVersion + "\n"; report += " .NET Framework Version: " + System.Environment.Version + "\n"; - report += " Version of the API: v1.3.0\n"; + report += " Version of the API: v1.4.0\n"; report += " SDK Package Version: 1.0.0\n"; return report; diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ExceptionFactory.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ExceptionFactory.cs index 0455c9f8b..62f579a1c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ExceptionFactory.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ExceptionFactory.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/FileParameter.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/FileParameter.cs index 847c40e47..80c09a900 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/FileParameter.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/FileParameter.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/GlobalConfiguration.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/GlobalConfiguration.cs index 42ad65e89..8289163d5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/GlobalConfiguration.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/GlobalConfiguration.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IApiAccessor.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IApiAccessor.cs index cf776e616..23f5de938 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IApiAccessor.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IApiAccessor.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IAsynchronousClient.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IAsynchronousClient.cs index 5c1b6226b..dbba01e4c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IAsynchronousClient.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IAsynchronousClient.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IReadableConfiguration.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IReadableConfiguration.cs index 145a91f91..4b518ff74 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IReadableConfiguration.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/IReadableConfiguration.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ISynchronousClient.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ISynchronousClient.cs index 9bd2c7880..0246d5dc2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ISynchronousClient.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/ISynchronousClient.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Multimap.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Multimap.cs index 7d5ec07ce..9b9e36c86 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Multimap.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/Multimap.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/OpenAPIDateConverter.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/OpenAPIDateConverter.cs index 9434bb615..caae1c4fa 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/OpenAPIDateConverter.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/OpenAPIDateConverter.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RequestOptions.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RequestOptions.cs index 720ee41d1..ed32f722e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RequestOptions.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RequestOptions.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RetryConfiguration.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RetryConfiguration.cs index 679caef4b..9cbb52c4d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RetryConfiguration.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/RetryConfiguration.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/WebRequestPathBuilder.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/WebRequestPathBuilder.cs index 47e87d672..880bec625 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/WebRequestPathBuilder.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Client/WebRequestPathBuilder.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AbstractOpenAPISchema.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AbstractOpenAPISchema.cs index 56e12a64f..2d48a9a9e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AbstractOpenAPISchema.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AbstractOpenAPISchema.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AtLedgerStateMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AtLedgerStateMixin.cs index 1919eb1a0..47c5c7eed 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AtLedgerStateMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/AtLedgerStateMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CommittedTransactionInfo.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CommittedTransactionInfo.cs index 2f476c693..cc2b7146a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CommittedTransactionInfo.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CommittedTransactionInfo.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -122,9 +122,11 @@ protected CommittedTransactionInfo() { } /// errorMessage. /// Hex-encoded binary blob.. /// receipt. + /// A text-representation of a transaction manifest. This field will be present only for user transactions and when explicitly opted-in using `manifest_instructions` flag. . + /// A collection of zero or more manifest classes ordered from the most specific class to the least specific one. This field will be present only for user transactions. . /// The optional transaction message. This type is defined in the Core API as `TransactionMessage`. See the Core API documentation for more details. . /// balanceChanges. - public CommittedTransactionInfo(long stateVersion = default(long), long epoch = default(long), long round = default(long), string roundTimestamp = default(string), TransactionStatus transactionStatus = default(TransactionStatus), string payloadHash = default(string), string intentHash = default(string), string feePaid = default(string), List affectedGlobalEntities = default(List), DateTime? confirmedAt = default(DateTime?), string errorMessage = default(string), string rawHex = default(string), TransactionReceipt receipt = default(TransactionReceipt), Object message = default(Object), TransactionBalanceChanges balanceChanges = default(TransactionBalanceChanges)) + public CommittedTransactionInfo(long stateVersion = default(long), long epoch = default(long), long round = default(long), string roundTimestamp = default(string), TransactionStatus transactionStatus = default(TransactionStatus), string payloadHash = default(string), string intentHash = default(string), string feePaid = default(string), List affectedGlobalEntities = default(List), DateTime? confirmedAt = default(DateTime?), string errorMessage = default(string), string rawHex = default(string), TransactionReceipt receipt = default(TransactionReceipt), string manifestInstructions = default(string), List manifestClasses = default(List), Object message = default(Object), TransactionBalanceChanges balanceChanges = default(TransactionBalanceChanges)) { this.StateVersion = stateVersion; this.Epoch = epoch; @@ -144,6 +146,8 @@ protected CommittedTransactionInfo() { } this.ErrorMessage = errorMessage; this.RawHex = rawHex; this.Receipt = receipt; + this.ManifestInstructions = manifestInstructions; + this.ManifestClasses = manifestClasses; this.Message = message; this.BalanceChanges = balanceChanges; } @@ -224,6 +228,20 @@ protected CommittedTransactionInfo() { } [DataMember(Name = "receipt", EmitDefaultValue = true)] public TransactionReceipt Receipt { get; set; } + /// + /// A text-representation of a transaction manifest. This field will be present only for user transactions and when explicitly opted-in using `manifest_instructions` flag. + /// + /// A text-representation of a transaction manifest. This field will be present only for user transactions and when explicitly opted-in using `manifest_instructions` flag. + [DataMember(Name = "manifest_instructions", EmitDefaultValue = true)] + public string ManifestInstructions { get; set; } + + /// + /// A collection of zero or more manifest classes ordered from the most specific class to the least specific one. This field will be present only for user transactions. + /// + /// A collection of zero or more manifest classes ordered from the most specific class to the least specific one. This field will be present only for user transactions. + [DataMember(Name = "manifest_classes", EmitDefaultValue = true)] + public List ManifestClasses { get; set; } + /// /// The optional transaction message. This type is defined in the Core API as `TransactionMessage`. See the Core API documentation for more details. /// @@ -258,6 +276,8 @@ public override string ToString() sb.Append(" ErrorMessage: ").Append(ErrorMessage).Append("\n"); sb.Append(" RawHex: ").Append(RawHex).Append("\n"); sb.Append(" Receipt: ").Append(Receipt).Append("\n"); + sb.Append(" ManifestInstructions: ").Append(ManifestInstructions).Append("\n"); + sb.Append(" ManifestClasses: ").Append(ManifestClasses).Append("\n"); sb.Append(" Message: ").Append(Message).Append("\n"); sb.Append(" BalanceChanges: ").Append(BalanceChanges).Append("\n"); sb.Append("}\n"); @@ -357,6 +377,17 @@ public bool Equals(CommittedTransactionInfo input) (this.Receipt != null && this.Receipt.Equals(input.Receipt)) ) && + ( + this.ManifestInstructions == input.ManifestInstructions || + (this.ManifestInstructions != null && + this.ManifestInstructions.Equals(input.ManifestInstructions)) + ) && + ( + this.ManifestClasses == input.ManifestClasses || + this.ManifestClasses != null && + input.ManifestClasses != null && + this.ManifestClasses.SequenceEqual(input.ManifestClasses) + ) && ( this.Message == input.Message || (this.Message != null && @@ -418,6 +449,14 @@ public override int GetHashCode() { hashCode = (hashCode * 59) + this.Receipt.GetHashCode(); } + if (this.ManifestInstructions != null) + { + hashCode = (hashCode * 59) + this.ManifestInstructions.GetHashCode(); + } + if (this.ManifestClasses != null) + { + hashCode = (hashCode * 59) + this.ManifestClasses.GetHashCode(); + } if (this.Message != null) { hashCode = (hashCode * 59) + this.Message.GetHashCode(); diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntry.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntry.cs index 1d9c38dd1..f85ce1aaa 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntry.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntry.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntryAssignment.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntryAssignment.cs index 1aa9fe0c0..c7eac7983 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntryAssignment.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignmentEntryAssignment.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignments.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignments.cs index f79aec15d..94c9fbac5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignments.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ComponentEntityRoleAssignments.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CursorLimitMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CursorLimitMixin.cs index c7c431fd2..dd31aec4f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CursorLimitMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/CursorLimitMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollection.cs index bb6bc6936..c40bbda07 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollectionAllOf.cs index aa840d338..e402c2ae7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItem.cs index 8d6053d60..ce996be7f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValue.cs index 5ee729a80..c2251120c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValueAllOf.cs index 5f7b28308..0aadad748 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityMetadataItemValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityNotFoundError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityNotFoundError.cs index cc7fa0ea7..17b537bc7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityNotFoundError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EntityNotFoundError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ErrorResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ErrorResponse.cs index f4e0f66c2..a67a233f4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ErrorResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ErrorResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EventsItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EventsItem.cs index a0174da61..1ce94b39d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EventsItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/EventsItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FromLedgerStateMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FromLedgerStateMixin.cs index 03c8bc3d5..63d31ea89 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FromLedgerStateMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FromLedgerStateMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollection.cs index 3b98e1781..b548e4e8b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionAllOf.cs index 6944fafd9..9df0c4cd5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItem.cs index f6d56982b..524343a99 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregated.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregated.cs index cd79a44a9..71115189a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregated.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregated.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregatedAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregatedAllOf.cs index 35e5506f1..e59e236ff 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregatedAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemGloballyAggregatedAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregated.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregated.cs index bb21e7614..e9136fd4e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregated.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregated.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedAllOf.cs index ebea3b506..cfe9bfe5b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVault.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVault.cs index 4c93c40df..2beca34fb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVault.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVault.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs index c711b56b7..3ab2372a6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultItem.cs index bb1a97b53..96090cece 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/FungibleResourcesCollectionItemVaultAggregatedVaultItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayError.cs index e72ec9929..d13b9d274 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseKnownTarget.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseKnownTarget.cs index 176138060..662ae2364 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseKnownTarget.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseKnownTarget.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseReleaseInfo.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseReleaseInfo.cs index abb146efb..ee450f91f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseReleaseInfo.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayInfoResponseReleaseInfo.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponse.cs index 43f543ae6..10e06aa9d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponseAllOf.cs index ee7ee403a..1cc976ce0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/GatewayStatusResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerError.cs index 275b972c6..273b6b1fb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerErrorAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerErrorAllOf.cs index 8df3f1f05..ad26a673b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerErrorAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InternalServerErrorAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidEntityError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidEntityError.cs index 4baf48208..fa21c6fd7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidEntityError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidEntityError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestError.cs index d80d51aaf..61b90776b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestErrorAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestErrorAllOf.cs index a2ba63356..da80f20e1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestErrorAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidRequestErrorAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidTransactionError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidTransactionError.cs index ecac1c22a..df98d4bb0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidTransactionError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/InvalidTransactionError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerState.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerState.cs index a25a79e1e..06e2f39e0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerState.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerState.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateMixin.cs index e5498024f..c709ed71e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateSelector.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateSelector.cs index e9ebdd75c..3ed996f78 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateSelector.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/LedgerStateSelector.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ManifestClass.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ManifestClass.cs new file mode 100644 index 000000000..492312101 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ManifestClass.cs @@ -0,0 +1,149 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +/* + * Radix Gateway API - Babylon + * + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * Generated by: https://github.com/openapitools/openapi-generator.git + */ + + +using System; +using System.Collections; +using System.Collections.Generic; +using System.Collections.ObjectModel; +using System.Linq; +using System.IO; +using System.Runtime.Serialization; +using System.Text; +using System.Text.RegularExpressions; +using Newtonsoft.Json; +using Newtonsoft.Json.Converters; +using Newtonsoft.Json.Linq; +using FileParameter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.FileParameter; +using OpenAPIDateConverter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.OpenAPIDateConverter; + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model +{ + /// + /// High-level manifest class type: * `General`: A general manifest that involves any amount of arbitrary components and packages where nothing more concrete can be said about the manifest and its nature. * `Transfer`: A manifest of a 1-to-1 transfer to a one-to-many transfer of resources. * `PoolContribution`: A manifest that contributed some amount of resources to a liquidity pool that can be a one-resource pool, two-resource pool, or a multi-resource pool. * `PoolRedemption`: A manifest that redeemed resources from a liquidity pool. Similar to contributions, this can be any of the three pool blueprints available in the pool package. * `ValidatorStake`: A manifest where XRD is staked to one or more validators. * `ValidatorUnstake`: A manifest where XRD is unstaked from one or more validators. * `ValidatorClaim`: A manifest where XRD is claimed from one or more validators. * `AccountDepositSettingsUpdate`: A manifest that updated the deposit settings of the account. + /// + /// High-level manifest class type: * `General`: A general manifest that involves any amount of arbitrary components and packages where nothing more concrete can be said about the manifest and its nature. * `Transfer`: A manifest of a 1-to-1 transfer to a one-to-many transfer of resources. * `PoolContribution`: A manifest that contributed some amount of resources to a liquidity pool that can be a one-resource pool, two-resource pool, or a multi-resource pool. * `PoolRedemption`: A manifest that redeemed resources from a liquidity pool. Similar to contributions, this can be any of the three pool blueprints available in the pool package. * `ValidatorStake`: A manifest where XRD is staked to one or more validators. * `ValidatorUnstake`: A manifest where XRD is unstaked from one or more validators. * `ValidatorClaim`: A manifest where XRD is claimed from one or more validators. * `AccountDepositSettingsUpdate`: A manifest that updated the deposit settings of the account. + [JsonConverter(typeof(StringEnumConverter))] + public enum ManifestClass + { + /// + /// Enum General for value: General + /// + [EnumMember(Value = "General")] + General = 1, + + /// + /// Enum Transfer for value: Transfer + /// + [EnumMember(Value = "Transfer")] + Transfer = 2, + + /// + /// Enum PoolContribution for value: PoolContribution + /// + [EnumMember(Value = "PoolContribution")] + PoolContribution = 3, + + /// + /// Enum PoolRedemption for value: PoolRedemption + /// + [EnumMember(Value = "PoolRedemption")] + PoolRedemption = 4, + + /// + /// Enum ValidatorStake for value: ValidatorStake + /// + [EnumMember(Value = "ValidatorStake")] + ValidatorStake = 5, + + /// + /// Enum ValidatorUnstake for value: ValidatorUnstake + /// + [EnumMember(Value = "ValidatorUnstake")] + ValidatorUnstake = 6, + + /// + /// Enum ValidatorClaim for value: ValidatorClaim + /// + [EnumMember(Value = "ValidatorClaim")] + ValidatorClaim = 7, + + /// + /// Enum AccountDepositSettingsUpdate for value: AccountDepositSettingsUpdate + /// + [EnumMember(Value = "AccountDepositSettingsUpdate")] + AccountDepositSettingsUpdate = 8 + + } + +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValue.cs index 6dae99308..e231fd9e6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValueAllOf.cs index 041a7e1eb..95b68d0a9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValue.cs index 5d1a0ec29..c7e318068 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValueAllOf.cs index cfb0d4707..39fa55a7c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataBoolValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalArrayValue.cs index c4968894e..9c380f03f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalValue.cs index 6de3fe352..afe6c4c3f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataDecimalValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressArrayValue.cs index 13755a5e5..410f4f9c2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressValue.cs index 73c557391..74e5e961d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataGlobalAddressValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32ArrayValue.cs index 0ec72ae1d..b090b7b43 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32Value.cs index 4f2771b11..04e9d534e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI32Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64ArrayValue.cs index b0ef726ec..59583bd4c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64Value.cs index a24f225fc..8b27acf6e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataI64Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValue.cs index 411237858..710460bda 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValue.cs index 90c58f7af..a6bace024 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataInstantValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValue.cs index 983c7b955..15405e713 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValueAllOf.cs index eb0f9b8ed..5dcd98f01 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValue.cs index 87dfe787a..9b1a2d188 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValueAllOf.cs index cd4ab4eb7..afd9f3bf8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleGlobalIdValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdArrayValue.cs index fd86ac754..0d49a0483 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdValue.cs index d443085b1..81e4a3b89 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataNonFungibleLocalIdValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginArrayValue.cs index beff72470..80edc8d9e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginValue.cs index 967d6f12a..ca8b95c92 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataOriginValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValue.cs index 0a44e8dbc..73527c996 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValueAllOf.cs index 7d0fd494c..ae5461721 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValue.cs index 2634c39a8..115ee6476 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValueAllOf.cs index 067262e87..d3c0c3dbe 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValue.cs index 908a1bf6c..5b3f8c51e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValueAllOf.cs index f2e20c763..d9d806773 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyHashValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValue.cs index 24233600b..82a6f9c1e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValueAllOf.cs index 2cf661095..1e5292fdb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataPublicKeyValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValue.cs index 615a3dc9b..81d7a948b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValueAllOf.cs index 5891c771f..db61fe465 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValue.cs index acc9492ec..b55a88dc9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValueAllOf.cs index 3edea7e10..0a622b81f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataStringValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataTypedValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataTypedValue.cs index c95b20aa5..5435c6020 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataTypedValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataTypedValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32ArrayValue.cs index 1e6d97030..5aea24fc4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32Value.cs index b45f50ada..a59feb381 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU32Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64ArrayValue.cs index 4dceadbdc..34a2f50b1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64Value.cs index ed7e10633..c90e5a5f5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU64Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValue.cs index fe2ed63b6..b77d1fce2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValueAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValueAllOf.cs index e787e081c..32b6b120e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValueAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8ArrayValueAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8Value.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8Value.cs index 760a92a53..a068a182e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8Value.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataU8Value.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlArrayValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlArrayValue.cs index c86b5b5f6..3d2c52b63 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlArrayValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlArrayValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlValue.cs index 5df61bc15..701b0f30c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataUrlValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataValueType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataValueType.cs index 1644f04dc..1fc3501f6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataValueType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/MetadataValueType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponse.cs index 1d60759fa..0f446fc12 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponseWellKnownAddresses.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponseWellKnownAddresses.cs index 9f0393bd3..62ad7160d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponseWellKnownAddresses.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NetworkConfigurationResponseWellKnownAddresses.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -123,6 +123,7 @@ protected NetworkConfigurationResponseWellKnownAddresses() { } /// Bech32m-encoded human readable version of the address. (required). /// Bech32m-encoded human readable version of the address. (required). /// Bech32m-encoded human readable version of the address. (required). + /// Bech32m-encoded human readable version of the address. (required). /// Bech32m-encoded human readable version of the address. (required). /// Bech32m-encoded human readable version of the address. (required). /// Bech32m-encoded human readable version of the address. (required). @@ -130,7 +131,7 @@ protected NetworkConfigurationResponseWellKnownAddresses() { } /// Bech32m-encoded human readable version of the address. (required). /// Bech32m-encoded human readable version of the address. (required). /// Bech32m-encoded human readable version of the address. (required). - public NetworkConfigurationResponseWellKnownAddresses(string xrd = default(string), string secp256k1SignatureVirtualBadge = default(string), string ed25519SignatureVirtualBadge = default(string), string packageOfDirectCallerVirtualBadge = default(string), string globalCallerVirtualBadge = default(string), string systemTransactionBadge = default(string), string packageOwnerBadge = default(string), string validatorOwnerBadge = default(string), string accountOwnerBadge = default(string), string identityOwnerBadge = default(string), string packagePackage = default(string), string resourcePackage = default(string), string accountPackage = default(string), string identityPackage = default(string), string consensusManagerPackage = default(string), string accessControllerPackage = default(string), string transactionProcessorPackage = default(string), string metadataModulePackage = default(string), string royaltyModulePackage = default(string), string accessRulesPackage = default(string), string genesisHelperPackage = default(string), string faucetPackage = default(string), string consensusManager = default(string), string genesisHelper = default(string), string faucet = default(string), string poolPackage = default(string), string transactionTracker = default(string)) + public NetworkConfigurationResponseWellKnownAddresses(string xrd = default(string), string secp256k1SignatureVirtualBadge = default(string), string ed25519SignatureVirtualBadge = default(string), string packageOfDirectCallerVirtualBadge = default(string), string globalCallerVirtualBadge = default(string), string systemTransactionBadge = default(string), string packageOwnerBadge = default(string), string validatorOwnerBadge = default(string), string accountOwnerBadge = default(string), string identityOwnerBadge = default(string), string packagePackage = default(string), string resourcePackage = default(string), string accountPackage = default(string), string identityPackage = default(string), string consensusManagerPackage = default(string), string accessControllerPackage = default(string), string transactionProcessorPackage = default(string), string metadataModulePackage = default(string), string royaltyModulePackage = default(string), string accessRulesPackage = default(string), string roleAssignmentModulePackage = default(string), string genesisHelperPackage = default(string), string faucetPackage = default(string), string consensusManager = default(string), string genesisHelper = default(string), string faucet = default(string), string poolPackage = default(string), string transactionTracker = default(string)) { // to ensure "xrd" is required (not null) if (xrd == null) @@ -252,6 +253,12 @@ protected NetworkConfigurationResponseWellKnownAddresses() { } throw new ArgumentNullException("accessRulesPackage is a required property for NetworkConfigurationResponseWellKnownAddresses and cannot be null"); } this.AccessRulesPackage = accessRulesPackage; + // to ensure "roleAssignmentModulePackage" is required (not null) + if (roleAssignmentModulePackage == null) + { + throw new ArgumentNullException("roleAssignmentModulePackage is a required property for NetworkConfigurationResponseWellKnownAddresses and cannot be null"); + } + this.RoleAssignmentModulePackage = roleAssignmentModulePackage; // to ensure "genesisHelperPackage" is required (not null) if (genesisHelperPackage == null) { @@ -436,6 +443,13 @@ protected NetworkConfigurationResponseWellKnownAddresses() { } [DataMember(Name = "access_rules_package", IsRequired = true, EmitDefaultValue = true)] public string AccessRulesPackage { get; set; } + /// + /// Bech32m-encoded human readable version of the address. + /// + /// Bech32m-encoded human readable version of the address. + [DataMember(Name = "role_assignment_module_package", IsRequired = true, EmitDefaultValue = true)] + public string RoleAssignmentModulePackage { get; set; } + /// /// Bech32m-encoded human readable version of the address. /// @@ -513,6 +527,7 @@ public override string ToString() sb.Append(" MetadataModulePackage: ").Append(MetadataModulePackage).Append("\n"); sb.Append(" RoyaltyModulePackage: ").Append(RoyaltyModulePackage).Append("\n"); sb.Append(" AccessRulesPackage: ").Append(AccessRulesPackage).Append("\n"); + sb.Append(" RoleAssignmentModulePackage: ").Append(RoleAssignmentModulePackage).Append("\n"); sb.Append(" GenesisHelperPackage: ").Append(GenesisHelperPackage).Append("\n"); sb.Append(" FaucetPackage: ").Append(FaucetPackage).Append("\n"); sb.Append(" ConsensusManager: ").Append(ConsensusManager).Append("\n"); @@ -655,6 +670,11 @@ public bool Equals(NetworkConfigurationResponseWellKnownAddresses input) (this.AccessRulesPackage != null && this.AccessRulesPackage.Equals(input.AccessRulesPackage)) ) && + ( + this.RoleAssignmentModulePackage == input.RoleAssignmentModulePackage || + (this.RoleAssignmentModulePackage != null && + this.RoleAssignmentModulePackage.Equals(input.RoleAssignmentModulePackage)) + ) && ( this.GenesisHelperPackage == input.GenesisHelperPackage || (this.GenesisHelperPackage != null && @@ -781,6 +801,10 @@ public override int GetHashCode() { hashCode = (hashCode * 59) + this.AccessRulesPackage.GetHashCode(); } + if (this.RoleAssignmentModulePackage != null) + { + hashCode = (hashCode * 59) + this.RoleAssignmentModulePackage.GetHashCode(); + } if (this.GenesisHelperPackage != null) { hashCode = (hashCode * 59) + this.GenesisHelperPackage.GetHashCode(); diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdType.cs index 96b25a378..f158a0355 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollection.cs index 2e3a6c476..06bea9dcb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollectionAllOf.cs index bb235b628..801fcc952 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleIdsCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollection.cs index b937826be..3750c5793 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionAllOf.cs index 9e1f7e0c3..31f9fc394 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItem.cs index 0d2106135..f74581075 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregated.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregated.cs index c5543a9b8..4b412e9e6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregated.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregated.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.cs index 0837900e6..ffda891de 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemGloballyAggregatedAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregated.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregated.cs index 6ddfde868..6a9fde480 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregated.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregated.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.cs index 7ec5b4df2..b8f59dc1f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVault.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVault.cs index 8c96613e4..0a05d2db6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVault.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVault.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs index 089132f29..8e10e3af7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.cs index 6539cf96c..427a84701 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.cs index 3ae775827..3c05e609c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NonFungibleResourcesCollectionItemVaultAggregatedVaultItemAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpError.cs index 29646f20d..492af0913 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpErrorAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpErrorAllOf.cs index 508225ae0..da68219de 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpErrorAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/NotSyncedUpErrorAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ObjectModuleId.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ObjectModuleId.cs index b3f2bbab3..34c6af339 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ObjectModuleId.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ObjectModuleId.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollection.cs index a7f72b16d..45ae9d0f3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollectionAllOf.cs index d3fe35276..e1a48c84f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/OptionalNonFungibleIdsCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionItem.cs index f3eda3776..2f1b5050f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageCodeCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageVmType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageVmType.cs index fa10e3936..832a86ada 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageVmType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PackageVmType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValue.cs index 0f814fd68..f90c06c7a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArray.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArray.cs index 7dce1e453..8eb1c22a6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArray.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArray.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArrayAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArrayAllOf.cs index d6d54553e..100025b7e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArrayAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueArrayAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBool.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBool.cs index 1d661175e..f7ea0436e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBool.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBool.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytes.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytes.cs index 599468072..2768b36af 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytes.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytes.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytesAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytesAllOf.cs index 8a9eb124e..6eb061100 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytesAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueBytesAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueDecimal.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueDecimal.cs index 7c7dd0bea..88e7a42ce 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueDecimal.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueDecimal.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnum.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnum.cs index ece0a077f..db1c5c976 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnum.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnum.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnumAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnumAllOf.cs index 7c17bb8f7..4313a6408 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnumAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueEnumAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI128.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI128.cs index e223461b8..45ff775b5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI128.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI128.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI16.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI16.cs index a42433515..cad537345 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI16.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI16.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI32.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI32.cs index b8760edb8..158f5ae2a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI32.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI32.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI64.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI64.cs index 09512de07..072b5a412 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI64.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI64.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI8.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI8.cs index f52398747..e65587364 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI8.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueI8.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueKind.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueKind.cs index 5b3af3456..62f6212e4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueKind.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueKind.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMap.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMap.cs index 5fcf7858a..1dbc0bd6f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMap.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMap.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapAllOf.cs index f58f4ba0f..469c7bf89 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapEntry.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapEntry.cs index d2cac6d9d..838e5df69 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapEntry.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueMapEntry.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueNonFungibleLocalId.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueNonFungibleLocalId.cs index aa3afcbde..4d2f1466c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueNonFungibleLocalId.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueNonFungibleLocalId.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueOwn.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueOwn.cs index 47a393958..ccb8e2da4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueOwn.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueOwn.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValuePreciseDecimal.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValuePreciseDecimal.cs index ab4524572..7c84448ea 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValuePreciseDecimal.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValuePreciseDecimal.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReference.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReference.cs index 5326db432..71ae8b4a5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReference.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueReference.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueString.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueString.cs index d00d39dee..101349de2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueString.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueString.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTuple.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTuple.cs index d099d98f5..50e16f0e1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTuple.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTuple.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTupleAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTupleAllOf.cs index ac2a34b8b..d01573678 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTupleAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueTupleAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU128.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU128.cs index 433035272..3c54db816 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU128.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU128.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU16.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU16.cs index 2ee509152..c19c214b9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU16.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU16.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU32.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU32.cs index cf43dc28a..220c533c3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU32.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU32.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU64.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU64.cs index bd0964ba9..7bbefbe5f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU64.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU64.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU8.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU8.cs index a55d282bb..421837b73 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU8.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ProgrammaticScryptoSborValueU8.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKey.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKey.cs index 2a082fc73..5081bfeec 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKey.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKey.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1.cs index 18c8c0779..a2a823fd5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1AllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1AllOf.cs index b678132d4..db66c2fa5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1AllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEcdsaSecp256k1AllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519.cs index c5ef607c9..5e74b4885 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519AllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519AllOf.cs index 38f1e4dda..df611bb36 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519AllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyEddsaEd25519AllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHash.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHash.cs index 33c90b4b2..5f0652b58 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHash.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHash.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1.cs index be0e07f64..4da3db4be 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1AllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1AllOf.cs index e0645f286..f86ced8d5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1AllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEcdsaSecp256k1AllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEddsaEd25519.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEddsaEd25519.cs index 8645cce38..ba8fa2a4c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEddsaEd25519.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashEddsaEd25519.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashType.cs index a78352c15..998fbafbb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyHashType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyType.cs index 64432d386..2571fd512 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/PublicKeyType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceAggregationLevel.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceAggregationLevel.cs index 6bb8163ce..6aed77b46 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceAggregationLevel.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResourceAggregationLevel.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResultSetCursorMixin.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResultSetCursorMixin.cs index 3160487fc..dc30dbe7b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResultSetCursorMixin.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ResultSetCursorMixin.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleAssignmentResolution.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleAssignmentResolution.cs index cc8864816..2b752611e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleAssignmentResolution.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleAssignmentResolution.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleKey.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleKey.cs index 69d676f68..9fccc58e8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleKey.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/RoleKey.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ScryptoSborValue.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ScryptoSborValue.cs index 2085d1781..3d996f0a7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ScryptoSborValue.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ScryptoSborValue.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsOptIns.cs index aea5ee5c6..8d8f9801c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequest.cs index df7f06c12..adbb24614 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequestAllOf.cs index dfb034833..21995cecb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponse.cs index 591ec140e..2a5c1ce54 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseAllOf.cs index 501138537..50111eaf6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetails.cs index 3b23e0867..c60f575b6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetailsAllOf.cs index 8196dc580..63c58cc5f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseComponentDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetails.cs index df6b778b0..7d164d192 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetailsAllOf.cs index 9182d9267..34062e83b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleResourceDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetails.cs index bbcf8756e..959865210 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetailsAllOf.cs index ca4747844..d619faef7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseFungibleVaultDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItem.cs index 6af22bb1f..bdd92858a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemAncestorIdentities.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemAncestorIdentities.cs index 9c02a632c..1f21e14ed 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemAncestorIdentities.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemAncestorIdentities.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetails.cs index a272f60e4..55924d03b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetailsType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetailsType.cs index 04fb66152..ec71ecc24 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetailsType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseItemDetailsType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetails.cs index 973ca6a7e..fe4d289a0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.cs index 70615e328..a1d758372 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleResourceDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetails.cs index f287b2ea6..bb5a85833 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.cs index 3317bf8b2..73be53cc0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponseNonFungibleVaultDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetails.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetails.cs index 67583791e..e9ea2b65b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetails.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetails.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsAllOf.cs index b6fb0177f..5fe8036ff 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintCollection.cs index ede05328c..9805d0529 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintCollectionAllOf.cs index c83c2e2b7..0e845d96f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintItem.cs index 771c6d30b..2b09880b1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsBlueprintItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsCodeCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsCodeCollection.cs index 6303578b0..68ab5b722 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsCodeCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsCodeCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsCodeCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsCodeCollectionAllOf.cs index 69a1101c9..5b4b757db 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsCodeCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsCodeCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaCollection.cs index 0f6c20274..fa5544b60 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaCollectionAllOf.cs index 6f1676636..27d9d34bc 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaItem.cs index 327db1d71..7cfd9dff7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityDetailsResponsePackageDetailsSchemaItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequest.cs index 8c5614552..95139e5c3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequestAllOf.cs index 60a536096..55af15d30 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageResponse.cs index 79466d04b..e162b4ccf 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungibleResourceVaultsPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequest.cs index a770bfddd..a8abb2194 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestAllOf.cs index cc2c98c7d..1ce5375e0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestOptIns.cs index 44013185d..1b6bdddf3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageRequestOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageResponse.cs index 842253d2f..c36271452 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityFungiblesPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequest.cs index 20bb05aaa..b3475fbc7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequestAllOf.cs index d2b295600..a135650a5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageResponse.cs index 2ce5b3448..cdfa8b789 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityMetadataPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequest.cs index b3ef1561e..452c90951 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequestAllOf.cs index c81eda5a2..89d642677 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageResponse.cs index 6209a32dc..2bd8d4570 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleIdsPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageOptIns.cs index 32bc5d30c..049f8bf53 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequest.cs index 975ca07cb..ef5475f5d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequestAllOf.cs index 02dba8f55..50a26aed8 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageResponse.cs index ff01ed6e1..e4080e8c2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungibleResourceVaultsPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequest.cs index ecc4e67bd..fd37658ee 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestAllOf.cs index cb7b7846a..0e8b7efa0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestOptIns.cs index d35132d3b..e45aa19bb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageRequestOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageResponse.cs index 90cb1eaa9..597454fe3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateEntityNonFungiblesPageResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequest.cs index 9d3019044..ad1204403 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestAllOf.cs index 38427b4b1..b9628d8aa 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestKeyItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestKeyItem.cs index f1982bd81..b5a2356e7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestKeyItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataRequestKeyItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponse.cs index 4258c57bb..4a8dec8fe 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseAllOf.cs index 7b26b8c9c..84aced67b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseItem.cs index 48dcd7773..c76607564 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreDataResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollection.cs new file mode 100644 index 000000000..bfd6c07f3 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollection.cs @@ -0,0 +1,232 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +/* + * Radix Gateway API - Babylon + * + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * Generated by: https://github.com/openapitools/openapi-generator.git + */ + + +using System; +using System.Collections; +using System.Collections.Generic; +using System.Collections.ObjectModel; +using System.Linq; +using System.IO; +using System.Runtime.Serialization; +using System.Text; +using System.Text.RegularExpressions; +using Newtonsoft.Json; +using Newtonsoft.Json.Converters; +using Newtonsoft.Json.Linq; +using FileParameter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.FileParameter; +using OpenAPIDateConverter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.OpenAPIDateConverter; + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model +{ + /// + /// Key value store items collection. + /// + [DataContract(Name = "StateKeyValueStoreKeysCollection")] + public partial class StateKeyValueStoreKeysCollection : IEquatable + { + /// + /// Initializes a new instance of the class. + /// + [JsonConstructorAttribute] + protected StateKeyValueStoreKeysCollection() { } + /// + /// Initializes a new instance of the class. + /// + /// Total number of items in underlying collection, fragment of which is available in `items` collection.. + /// If specified, contains a cursor to query next page of the `items` collection.. + /// items (required). + public StateKeyValueStoreKeysCollection(long? totalCount = default(long?), string nextCursor = default(string), List items = default(List)) + { + // to ensure "items" is required (not null) + if (items == null) + { + throw new ArgumentNullException("items is a required property for StateKeyValueStoreKeysCollection and cannot be null"); + } + this.Items = items; + this.TotalCount = totalCount; + this.NextCursor = nextCursor; + } + + /// + /// Total number of items in underlying collection, fragment of which is available in `items` collection. + /// + /// Total number of items in underlying collection, fragment of which is available in `items` collection. + [DataMember(Name = "total_count", EmitDefaultValue = true)] + public long? TotalCount { get; set; } + + /// + /// If specified, contains a cursor to query next page of the `items` collection. + /// + /// If specified, contains a cursor to query next page of the `items` collection. + [DataMember(Name = "next_cursor", EmitDefaultValue = true)] + public string NextCursor { get; set; } + + /// + /// Gets or Sets Items + /// + [DataMember(Name = "items", IsRequired = true, EmitDefaultValue = true)] + public List Items { get; set; } + + /// + /// Returns the string presentation of the object + /// + /// String presentation of the object + public override string ToString() + { + StringBuilder sb = new StringBuilder(); + sb.Append("class StateKeyValueStoreKeysCollection {\n"); + sb.Append(" TotalCount: ").Append(TotalCount).Append("\n"); + sb.Append(" NextCursor: ").Append(NextCursor).Append("\n"); + sb.Append(" Items: ").Append(Items).Append("\n"); + sb.Append("}\n"); + return sb.ToString(); + } + + /// + /// Returns the JSON string presentation of the object + /// + /// JSON string presentation of the object + public virtual string ToJson() + { + return Newtonsoft.Json.JsonConvert.SerializeObject(this, Newtonsoft.Json.Formatting.Indented); + } + + /// + /// Returns true if objects are equal + /// + /// Object to be compared + /// Boolean + public override bool Equals(object input) + { + return this.Equals(input as StateKeyValueStoreKeysCollection); + } + + /// + /// Returns true if StateKeyValueStoreKeysCollection instances are equal + /// + /// Instance of StateKeyValueStoreKeysCollection to be compared + /// Boolean + public bool Equals(StateKeyValueStoreKeysCollection input) + { + if (input == null) + { + return false; + } + return + ( + this.TotalCount == input.TotalCount || + (this.TotalCount != null && + this.TotalCount.Equals(input.TotalCount)) + ) && + ( + this.NextCursor == input.NextCursor || + (this.NextCursor != null && + this.NextCursor.Equals(input.NextCursor)) + ) && + ( + this.Items == input.Items || + this.Items != null && + input.Items != null && + this.Items.SequenceEqual(input.Items) + ); + } + + /// + /// Gets the hash code + /// + /// Hash code + public override int GetHashCode() + { + unchecked // Overflow is fine, just wrap + { + int hashCode = 41; + if (this.TotalCount != null) + { + hashCode = (hashCode * 59) + this.TotalCount.GetHashCode(); + } + if (this.NextCursor != null) + { + hashCode = (hashCode * 59) + this.NextCursor.GetHashCode(); + } + if (this.Items != null) + { + hashCode = (hashCode * 59) + this.Items.GetHashCode(); + } + return hashCode; + } + } + + } + +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollectionAllOf.cs new file mode 100644 index 000000000..1f83c1e1e --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysCollectionAllOf.cs @@ -0,0 +1,194 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +/* + * Radix Gateway API - Babylon + * + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * Generated by: https://github.com/openapitools/openapi-generator.git + */ + + +using System; +using System.Collections; +using System.Collections.Generic; +using System.Collections.ObjectModel; +using System.Linq; +using System.IO; +using System.Runtime.Serialization; +using System.Text; +using System.Text.RegularExpressions; +using Newtonsoft.Json; +using Newtonsoft.Json.Converters; +using Newtonsoft.Json.Linq; +using FileParameter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.FileParameter; +using OpenAPIDateConverter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.OpenAPIDateConverter; + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model +{ + /// + /// StateKeyValueStoreKeysCollectionAllOf + /// + [DataContract(Name = "StateKeyValueStoreKeysCollection_allOf")] + public partial class StateKeyValueStoreKeysCollectionAllOf : IEquatable + { + /// + /// Initializes a new instance of the class. + /// + [JsonConstructorAttribute] + protected StateKeyValueStoreKeysCollectionAllOf() { } + /// + /// Initializes a new instance of the class. + /// + /// items (required). + public StateKeyValueStoreKeysCollectionAllOf(List items = default(List)) + { + // to ensure "items" is required (not null) + if (items == null) + { + throw new ArgumentNullException("items is a required property for StateKeyValueStoreKeysCollectionAllOf and cannot be null"); + } + this.Items = items; + } + + /// + /// Gets or Sets Items + /// + [DataMember(Name = "items", IsRequired = true, EmitDefaultValue = true)] + public List Items { get; set; } + + /// + /// Returns the string presentation of the object + /// + /// String presentation of the object + public override string ToString() + { + StringBuilder sb = new StringBuilder(); + sb.Append("class StateKeyValueStoreKeysCollectionAllOf {\n"); + sb.Append(" Items: ").Append(Items).Append("\n"); + sb.Append("}\n"); + return sb.ToString(); + } + + /// + /// Returns the JSON string presentation of the object + /// + /// JSON string presentation of the object + public virtual string ToJson() + { + return Newtonsoft.Json.JsonConvert.SerializeObject(this, Newtonsoft.Json.Formatting.Indented); + } + + /// + /// Returns true if objects are equal + /// + /// Object to be compared + /// Boolean + public override bool Equals(object input) + { + return this.Equals(input as StateKeyValueStoreKeysCollectionAllOf); + } + + /// + /// Returns true if StateKeyValueStoreKeysCollectionAllOf instances are equal + /// + /// Instance of StateKeyValueStoreKeysCollectionAllOf to be compared + /// Boolean + public bool Equals(StateKeyValueStoreKeysCollectionAllOf input) + { + if (input == null) + { + return false; + } + return + ( + this.Items == input.Items || + this.Items != null && + input.Items != null && + this.Items.SequenceEqual(input.Items) + ); + } + + /// + /// Gets the hash code + /// + /// Hash code + public override int GetHashCode() + { + unchecked // Overflow is fine, just wrap + { + int hashCode = 41; + if (this.Items != null) + { + hashCode = (hashCode * 59) + this.Items.GetHashCode(); + } + return hashCode; + } + } + + } + +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequest.cs new file mode 100644 index 000000000..c38677619 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequest.cs @@ -0,0 +1,250 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +/* + * Radix Gateway API - Babylon + * + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * Generated by: https://github.com/openapitools/openapi-generator.git + */ + + +using System; +using System.Collections; +using System.Collections.Generic; +using System.Collections.ObjectModel; +using System.Linq; +using System.IO; +using System.Runtime.Serialization; +using System.Text; +using System.Text.RegularExpressions; +using Newtonsoft.Json; +using Newtonsoft.Json.Converters; +using Newtonsoft.Json.Linq; +using FileParameter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.FileParameter; +using OpenAPIDateConverter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.OpenAPIDateConverter; + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model +{ + /// + /// StateKeyValueStoreKeysRequest + /// + [DataContract(Name = "StateKeyValueStoreKeysRequest")] + public partial class StateKeyValueStoreKeysRequest : IEquatable + { + /// + /// Initializes a new instance of the class. + /// + [JsonConstructorAttribute] + protected StateKeyValueStoreKeysRequest() { } + /// + /// Initializes a new instance of the class. + /// + /// atLedgerState. + /// This cursor allows forward pagination, by providing the cursor from the previous request.. + /// The page size requested.. + /// Bech32m-encoded human readable version of the address. (required). + public StateKeyValueStoreKeysRequest(LedgerStateSelector atLedgerState = default(LedgerStateSelector), string cursor = default(string), int? limitPerPage = default(int?), string keyValueStoreAddress = default(string)) + { + // to ensure "keyValueStoreAddress" is required (not null) + if (keyValueStoreAddress == null) + { + throw new ArgumentNullException("keyValueStoreAddress is a required property for StateKeyValueStoreKeysRequest and cannot be null"); + } + this.KeyValueStoreAddress = keyValueStoreAddress; + this.AtLedgerState = atLedgerState; + this.Cursor = cursor; + this.LimitPerPage = limitPerPage; + } + + /// + /// Gets or Sets AtLedgerState + /// + [DataMember(Name = "at_ledger_state", EmitDefaultValue = true)] + public LedgerStateSelector AtLedgerState { get; set; } + + /// + /// This cursor allows forward pagination, by providing the cursor from the previous request. + /// + /// This cursor allows forward pagination, by providing the cursor from the previous request. + [DataMember(Name = "cursor", EmitDefaultValue = true)] + public string Cursor { get; set; } + + /// + /// The page size requested. + /// + /// The page size requested. + [DataMember(Name = "limit_per_page", EmitDefaultValue = true)] + public int? LimitPerPage { get; set; } + + /// + /// Bech32m-encoded human readable version of the address. + /// + /// Bech32m-encoded human readable version of the address. + [DataMember(Name = "key_value_store_address", IsRequired = true, EmitDefaultValue = true)] + public string KeyValueStoreAddress { get; set; } + + /// + /// Returns the string presentation of the object + /// + /// String presentation of the object + public override string ToString() + { + StringBuilder sb = new StringBuilder(); + sb.Append("class StateKeyValueStoreKeysRequest {\n"); + sb.Append(" AtLedgerState: ").Append(AtLedgerState).Append("\n"); + sb.Append(" Cursor: ").Append(Cursor).Append("\n"); + sb.Append(" LimitPerPage: ").Append(LimitPerPage).Append("\n"); + sb.Append(" KeyValueStoreAddress: ").Append(KeyValueStoreAddress).Append("\n"); + sb.Append("}\n"); + return sb.ToString(); + } + + /// + /// Returns the JSON string presentation of the object + /// + /// JSON string presentation of the object + public virtual string ToJson() + { + return Newtonsoft.Json.JsonConvert.SerializeObject(this, Newtonsoft.Json.Formatting.Indented); + } + + /// + /// Returns true if objects are equal + /// + /// Object to be compared + /// Boolean + public override bool Equals(object input) + { + return this.Equals(input as StateKeyValueStoreKeysRequest); + } + + /// + /// Returns true if StateKeyValueStoreKeysRequest instances are equal + /// + /// Instance of StateKeyValueStoreKeysRequest to be compared + /// Boolean + public bool Equals(StateKeyValueStoreKeysRequest input) + { + if (input == null) + { + return false; + } + return + ( + this.AtLedgerState == input.AtLedgerState || + (this.AtLedgerState != null && + this.AtLedgerState.Equals(input.AtLedgerState)) + ) && + ( + this.Cursor == input.Cursor || + (this.Cursor != null && + this.Cursor.Equals(input.Cursor)) + ) && + ( + this.LimitPerPage == input.LimitPerPage || + (this.LimitPerPage != null && + this.LimitPerPage.Equals(input.LimitPerPage)) + ) && + ( + this.KeyValueStoreAddress == input.KeyValueStoreAddress || + (this.KeyValueStoreAddress != null && + this.KeyValueStoreAddress.Equals(input.KeyValueStoreAddress)) + ); + } + + /// + /// Gets the hash code + /// + /// Hash code + public override int GetHashCode() + { + unchecked // Overflow is fine, just wrap + { + int hashCode = 41; + if (this.AtLedgerState != null) + { + hashCode = (hashCode * 59) + this.AtLedgerState.GetHashCode(); + } + if (this.Cursor != null) + { + hashCode = (hashCode * 59) + this.Cursor.GetHashCode(); + } + if (this.LimitPerPage != null) + { + hashCode = (hashCode * 59) + this.LimitPerPage.GetHashCode(); + } + if (this.KeyValueStoreAddress != null) + { + hashCode = (hashCode * 59) + this.KeyValueStoreAddress.GetHashCode(); + } + return hashCode; + } + } + + } + +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequestAllOf.cs new file mode 100644 index 000000000..8bd2b61ed --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysRequestAllOf.cs @@ -0,0 +1,194 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +/* + * Radix Gateway API - Babylon + * + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * Generated by: https://github.com/openapitools/openapi-generator.git + */ + + +using System; +using System.Collections; +using System.Collections.Generic; +using System.Collections.ObjectModel; +using System.Linq; +using System.IO; +using System.Runtime.Serialization; +using System.Text; +using System.Text.RegularExpressions; +using Newtonsoft.Json; +using Newtonsoft.Json.Converters; +using Newtonsoft.Json.Linq; +using FileParameter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.FileParameter; +using OpenAPIDateConverter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.OpenAPIDateConverter; + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model +{ + /// + /// StateKeyValueStoreKeysRequestAllOf + /// + [DataContract(Name = "StateKeyValueStoreKeysRequest_allOf")] + public partial class StateKeyValueStoreKeysRequestAllOf : IEquatable + { + /// + /// Initializes a new instance of the class. + /// + [JsonConstructorAttribute] + protected StateKeyValueStoreKeysRequestAllOf() { } + /// + /// Initializes a new instance of the class. + /// + /// Bech32m-encoded human readable version of the address. (required). + public StateKeyValueStoreKeysRequestAllOf(string keyValueStoreAddress = default(string)) + { + // to ensure "keyValueStoreAddress" is required (not null) + if (keyValueStoreAddress == null) + { + throw new ArgumentNullException("keyValueStoreAddress is a required property for StateKeyValueStoreKeysRequestAllOf and cannot be null"); + } + this.KeyValueStoreAddress = keyValueStoreAddress; + } + + /// + /// Bech32m-encoded human readable version of the address. + /// + /// Bech32m-encoded human readable version of the address. + [DataMember(Name = "key_value_store_address", IsRequired = true, EmitDefaultValue = true)] + public string KeyValueStoreAddress { get; set; } + + /// + /// Returns the string presentation of the object + /// + /// String presentation of the object + public override string ToString() + { + StringBuilder sb = new StringBuilder(); + sb.Append("class StateKeyValueStoreKeysRequestAllOf {\n"); + sb.Append(" KeyValueStoreAddress: ").Append(KeyValueStoreAddress).Append("\n"); + sb.Append("}\n"); + return sb.ToString(); + } + + /// + /// Returns the JSON string presentation of the object + /// + /// JSON string presentation of the object + public virtual string ToJson() + { + return Newtonsoft.Json.JsonConvert.SerializeObject(this, Newtonsoft.Json.Formatting.Indented); + } + + /// + /// Returns true if objects are equal + /// + /// Object to be compared + /// Boolean + public override bool Equals(object input) + { + return this.Equals(input as StateKeyValueStoreKeysRequestAllOf); + } + + /// + /// Returns true if StateKeyValueStoreKeysRequestAllOf instances are equal + /// + /// Instance of StateKeyValueStoreKeysRequestAllOf to be compared + /// Boolean + public bool Equals(StateKeyValueStoreKeysRequestAllOf input) + { + if (input == null) + { + return false; + } + return + ( + this.KeyValueStoreAddress == input.KeyValueStoreAddress || + (this.KeyValueStoreAddress != null && + this.KeyValueStoreAddress.Equals(input.KeyValueStoreAddress)) + ); + } + + /// + /// Gets the hash code + /// + /// Hash code + public override int GetHashCode() + { + unchecked // Overflow is fine, just wrap + { + int hashCode = 41; + if (this.KeyValueStoreAddress != null) + { + hashCode = (hashCode * 59) + this.KeyValueStoreAddress.GetHashCode(); + } + return hashCode; + } + } + + } + +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponse.cs new file mode 100644 index 000000000..05aec5d20 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponse.cs @@ -0,0 +1,279 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +/* + * Radix Gateway API - Babylon + * + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * Generated by: https://github.com/openapitools/openapi-generator.git + */ + + +using System; +using System.Collections; +using System.Collections.Generic; +using System.Collections.ObjectModel; +using System.Linq; +using System.IO; +using System.Runtime.Serialization; +using System.Text; +using System.Text.RegularExpressions; +using Newtonsoft.Json; +using Newtonsoft.Json.Converters; +using Newtonsoft.Json.Linq; +using FileParameter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.FileParameter; +using OpenAPIDateConverter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.OpenAPIDateConverter; + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model +{ + /// + /// StateKeyValueStoreKeysResponse + /// + [DataContract(Name = "StateKeyValueStoreKeysResponse")] + public partial class StateKeyValueStoreKeysResponse : IEquatable + { + /// + /// Initializes a new instance of the class. + /// + [JsonConstructorAttribute] + protected StateKeyValueStoreKeysResponse() { } + /// + /// Initializes a new instance of the class. + /// + /// ledgerState (required). + /// Total number of items in underlying collection, fragment of which is available in `items` collection.. + /// If specified, contains a cursor to query next page of the `items` collection.. + /// items (required). + /// Bech32m-encoded human readable version of the address. (required). + public StateKeyValueStoreKeysResponse(LedgerState ledgerState = default(LedgerState), long? totalCount = default(long?), string nextCursor = default(string), List items = default(List), string keyValueStoreAddress = default(string)) + { + // to ensure "ledgerState" is required (not null) + if (ledgerState == null) + { + throw new ArgumentNullException("ledgerState is a required property for StateKeyValueStoreKeysResponse and cannot be null"); + } + this.LedgerState = ledgerState; + // to ensure "items" is required (not null) + if (items == null) + { + throw new ArgumentNullException("items is a required property for StateKeyValueStoreKeysResponse and cannot be null"); + } + this.Items = items; + // to ensure "keyValueStoreAddress" is required (not null) + if (keyValueStoreAddress == null) + { + throw new ArgumentNullException("keyValueStoreAddress is a required property for StateKeyValueStoreKeysResponse and cannot be null"); + } + this.KeyValueStoreAddress = keyValueStoreAddress; + this.TotalCount = totalCount; + this.NextCursor = nextCursor; + } + + /// + /// Gets or Sets LedgerState + /// + [DataMember(Name = "ledger_state", IsRequired = true, EmitDefaultValue = true)] + public LedgerState LedgerState { get; set; } + + /// + /// Total number of items in underlying collection, fragment of which is available in `items` collection. + /// + /// Total number of items in underlying collection, fragment of which is available in `items` collection. + [DataMember(Name = "total_count", EmitDefaultValue = true)] + public long? TotalCount { get; set; } + + /// + /// If specified, contains a cursor to query next page of the `items` collection. + /// + /// If specified, contains a cursor to query next page of the `items` collection. + [DataMember(Name = "next_cursor", EmitDefaultValue = true)] + public string NextCursor { get; set; } + + /// + /// Gets or Sets Items + /// + [DataMember(Name = "items", IsRequired = true, EmitDefaultValue = true)] + public List Items { get; set; } + + /// + /// Bech32m-encoded human readable version of the address. + /// + /// Bech32m-encoded human readable version of the address. + [DataMember(Name = "key_value_store_address", IsRequired = true, EmitDefaultValue = true)] + public string KeyValueStoreAddress { get; set; } + + /// + /// Returns the string presentation of the object + /// + /// String presentation of the object + public override string ToString() + { + StringBuilder sb = new StringBuilder(); + sb.Append("class StateKeyValueStoreKeysResponse {\n"); + sb.Append(" LedgerState: ").Append(LedgerState).Append("\n"); + sb.Append(" TotalCount: ").Append(TotalCount).Append("\n"); + sb.Append(" NextCursor: ").Append(NextCursor).Append("\n"); + sb.Append(" Items: ").Append(Items).Append("\n"); + sb.Append(" KeyValueStoreAddress: ").Append(KeyValueStoreAddress).Append("\n"); + sb.Append("}\n"); + return sb.ToString(); + } + + /// + /// Returns the JSON string presentation of the object + /// + /// JSON string presentation of the object + public virtual string ToJson() + { + return Newtonsoft.Json.JsonConvert.SerializeObject(this, Newtonsoft.Json.Formatting.Indented); + } + + /// + /// Returns true if objects are equal + /// + /// Object to be compared + /// Boolean + public override bool Equals(object input) + { + return this.Equals(input as StateKeyValueStoreKeysResponse); + } + + /// + /// Returns true if StateKeyValueStoreKeysResponse instances are equal + /// + /// Instance of StateKeyValueStoreKeysResponse to be compared + /// Boolean + public bool Equals(StateKeyValueStoreKeysResponse input) + { + if (input == null) + { + return false; + } + return + ( + this.LedgerState == input.LedgerState || + (this.LedgerState != null && + this.LedgerState.Equals(input.LedgerState)) + ) && + ( + this.TotalCount == input.TotalCount || + (this.TotalCount != null && + this.TotalCount.Equals(input.TotalCount)) + ) && + ( + this.NextCursor == input.NextCursor || + (this.NextCursor != null && + this.NextCursor.Equals(input.NextCursor)) + ) && + ( + this.Items == input.Items || + this.Items != null && + input.Items != null && + this.Items.SequenceEqual(input.Items) + ) && + ( + this.KeyValueStoreAddress == input.KeyValueStoreAddress || + (this.KeyValueStoreAddress != null && + this.KeyValueStoreAddress.Equals(input.KeyValueStoreAddress)) + ); + } + + /// + /// Gets the hash code + /// + /// Hash code + public override int GetHashCode() + { + unchecked // Overflow is fine, just wrap + { + int hashCode = 41; + if (this.LedgerState != null) + { + hashCode = (hashCode * 59) + this.LedgerState.GetHashCode(); + } + if (this.TotalCount != null) + { + hashCode = (hashCode * 59) + this.TotalCount.GetHashCode(); + } + if (this.NextCursor != null) + { + hashCode = (hashCode * 59) + this.NextCursor.GetHashCode(); + } + if (this.Items != null) + { + hashCode = (hashCode * 59) + this.Items.GetHashCode(); + } + if (this.KeyValueStoreAddress != null) + { + hashCode = (hashCode * 59) + this.KeyValueStoreAddress.GetHashCode(); + } + return hashCode; + } + } + + } + +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponseItem.cs new file mode 100644 index 000000000..d03a95263 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateKeyValueStoreKeysResponseItem.cs @@ -0,0 +1,208 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +/* + * Radix Gateway API - Babylon + * + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * Generated by: https://github.com/openapitools/openapi-generator.git + */ + + +using System; +using System.Collections; +using System.Collections.Generic; +using System.Collections.ObjectModel; +using System.Linq; +using System.IO; +using System.Runtime.Serialization; +using System.Text; +using System.Text.RegularExpressions; +using Newtonsoft.Json; +using Newtonsoft.Json.Converters; +using Newtonsoft.Json.Linq; +using FileParameter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.FileParameter; +using OpenAPIDateConverter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.OpenAPIDateConverter; + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model +{ + /// + /// StateKeyValueStoreKeysResponseItem + /// + [DataContract(Name = "StateKeyValueStoreKeysResponseItem")] + public partial class StateKeyValueStoreKeysResponseItem : IEquatable + { + /// + /// Initializes a new instance of the class. + /// + [JsonConstructorAttribute] + protected StateKeyValueStoreKeysResponseItem() { } + /// + /// Initializes a new instance of the class. + /// + /// key (required). + /// The most recent state version underlying object was modified at. (required). + public StateKeyValueStoreKeysResponseItem(ScryptoSborValue key = default(ScryptoSborValue), long lastUpdatedAtStateVersion = default(long)) + { + // to ensure "key" is required (not null) + if (key == null) + { + throw new ArgumentNullException("key is a required property for StateKeyValueStoreKeysResponseItem and cannot be null"); + } + this.Key = key; + this.LastUpdatedAtStateVersion = lastUpdatedAtStateVersion; + } + + /// + /// Gets or Sets Key + /// + [DataMember(Name = "key", IsRequired = true, EmitDefaultValue = true)] + public ScryptoSborValue Key { get; set; } + + /// + /// The most recent state version underlying object was modified at. + /// + /// The most recent state version underlying object was modified at. + [DataMember(Name = "last_updated_at_state_version", IsRequired = true, EmitDefaultValue = true)] + public long LastUpdatedAtStateVersion { get; set; } + + /// + /// Returns the string presentation of the object + /// + /// String presentation of the object + public override string ToString() + { + StringBuilder sb = new StringBuilder(); + sb.Append("class StateKeyValueStoreKeysResponseItem {\n"); + sb.Append(" Key: ").Append(Key).Append("\n"); + sb.Append(" LastUpdatedAtStateVersion: ").Append(LastUpdatedAtStateVersion).Append("\n"); + sb.Append("}\n"); + return sb.ToString(); + } + + /// + /// Returns the JSON string presentation of the object + /// + /// JSON string presentation of the object + public virtual string ToJson() + { + return Newtonsoft.Json.JsonConvert.SerializeObject(this, Newtonsoft.Json.Formatting.Indented); + } + + /// + /// Returns true if objects are equal + /// + /// Object to be compared + /// Boolean + public override bool Equals(object input) + { + return this.Equals(input as StateKeyValueStoreKeysResponseItem); + } + + /// + /// Returns true if StateKeyValueStoreKeysResponseItem instances are equal + /// + /// Instance of StateKeyValueStoreKeysResponseItem to be compared + /// Boolean + public bool Equals(StateKeyValueStoreKeysResponseItem input) + { + if (input == null) + { + return false; + } + return + ( + this.Key == input.Key || + (this.Key != null && + this.Key.Equals(input.Key)) + ) && + ( + this.LastUpdatedAtStateVersion == input.LastUpdatedAtStateVersion || + this.LastUpdatedAtStateVersion.Equals(input.LastUpdatedAtStateVersion) + ); + } + + /// + /// Gets the hash code + /// + /// Hash code + public override int GetHashCode() + { + unchecked // Overflow is fine, just wrap + { + int hashCode = 41; + if (this.Key != null) + { + hashCode = (hashCode * 59) + this.Key.GetHashCode(); + } + hashCode = (hashCode * 59) + this.LastUpdatedAtStateVersion.GetHashCode(); + return hashCode; + } + } + + } + +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataRequest.cs index 8bfb223f6..de9b2f0f3 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponse.cs index 3639c9df9..7bb962076 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponseAllOf.cs index e5ad598c0..d3f53baa5 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDataResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDetailsResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDetailsResponseItem.cs index b26e96360..3b2387744 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDetailsResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleDetailsResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequest.cs index 58fa4f3f3..bf1a82e3d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequestAllOf.cs index e26906ba3..b355cb012 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponse.cs index cdbcbd05e..903de6108 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponseAllOf.cs index 2d34d4372..20d17b489 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleIdsResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequest.cs index 9d672455c..ffc0a450e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequestAllOf.cs index e6181b53b..3b22b200d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponse.cs index 4032b78d4..3a324e008 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseAllOf.cs index 70b8dd044..0037f433b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseItem.cs index 3db02ed8d..fa4fdc017 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateNonFungibleLocationResponseItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequest.cs index d863a1f2a..665e6254c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequestAllOf.cs index 83fd3fb69..2d88c6a48 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponse.cs index d95a654e3..76b210ea4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponseAllOf.cs index dedc9c468..ca26eeded 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StateValidatorsListResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequest.cs index fdc8d97fa..24e42ca5b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -170,9 +170,12 @@ public enum OrderEnum /// manifestResourcesFilter. /// affectedGlobalEntitiesFilter. /// eventsFilter. + /// accountsWithManifestOwnerMethodCalls. + /// accountsWithoutManifestOwnerMethodCalls. + /// manifestClassFilter. /// Configures the order of returned result set. Defaults to `desc`.. /// optIns. - public StreamTransactionsRequest(LedgerStateSelector atLedgerState = default(LedgerStateSelector), LedgerStateSelector fromLedgerState = default(LedgerStateSelector), string cursor = default(string), int? limitPerPage = default(int?), KindFilterEnum? kindFilter = default(KindFilterEnum?), List manifestAccountsWithdrawnFromFilter = default(List), List manifestAccountsDepositedIntoFilter = default(List), List manifestResourcesFilter = default(List), List affectedGlobalEntitiesFilter = default(List), List eventsFilter = default(List), OrderEnum? order = default(OrderEnum?), TransactionDetailsOptIns optIns = default(TransactionDetailsOptIns)) + public StreamTransactionsRequest(LedgerStateSelector atLedgerState = default(LedgerStateSelector), LedgerStateSelector fromLedgerState = default(LedgerStateSelector), string cursor = default(string), int? limitPerPage = default(int?), KindFilterEnum? kindFilter = default(KindFilterEnum?), List manifestAccountsWithdrawnFromFilter = default(List), List manifestAccountsDepositedIntoFilter = default(List), List manifestResourcesFilter = default(List), List affectedGlobalEntitiesFilter = default(List), List eventsFilter = default(List), List accountsWithManifestOwnerMethodCalls = default(List), List accountsWithoutManifestOwnerMethodCalls = default(List), StreamTransactionsRequestAllOfManifestClassFilter manifestClassFilter = default(StreamTransactionsRequestAllOfManifestClassFilter), OrderEnum? order = default(OrderEnum?), TransactionDetailsOptIns optIns = default(TransactionDetailsOptIns)) { this.AtLedgerState = atLedgerState; this.FromLedgerState = fromLedgerState; @@ -184,6 +187,9 @@ public enum OrderEnum this.ManifestResourcesFilter = manifestResourcesFilter; this.AffectedGlobalEntitiesFilter = affectedGlobalEntitiesFilter; this.EventsFilter = eventsFilter; + this.AccountsWithManifestOwnerMethodCalls = accountsWithManifestOwnerMethodCalls; + this.AccountsWithoutManifestOwnerMethodCalls = accountsWithoutManifestOwnerMethodCalls; + this.ManifestClassFilter = manifestClassFilter; this.Order = order; this.OptIns = optIns; } @@ -244,6 +250,24 @@ public enum OrderEnum [DataMember(Name = "events_filter", EmitDefaultValue = true)] public List EventsFilter { get; set; } + /// + /// Gets or Sets AccountsWithManifestOwnerMethodCalls + /// + [DataMember(Name = "accounts_with_manifest_owner_method_calls", EmitDefaultValue = true)] + public List AccountsWithManifestOwnerMethodCalls { get; set; } + + /// + /// Gets or Sets AccountsWithoutManifestOwnerMethodCalls + /// + [DataMember(Name = "accounts_without_manifest_owner_method_calls", EmitDefaultValue = true)] + public List AccountsWithoutManifestOwnerMethodCalls { get; set; } + + /// + /// Gets or Sets ManifestClassFilter + /// + [DataMember(Name = "manifest_class_filter", EmitDefaultValue = true)] + public StreamTransactionsRequestAllOfManifestClassFilter ManifestClassFilter { get; set; } + /// /// Gets or Sets OptIns /// @@ -268,6 +292,9 @@ public override string ToString() sb.Append(" ManifestResourcesFilter: ").Append(ManifestResourcesFilter).Append("\n"); sb.Append(" AffectedGlobalEntitiesFilter: ").Append(AffectedGlobalEntitiesFilter).Append("\n"); sb.Append(" EventsFilter: ").Append(EventsFilter).Append("\n"); + sb.Append(" AccountsWithManifestOwnerMethodCalls: ").Append(AccountsWithManifestOwnerMethodCalls).Append("\n"); + sb.Append(" AccountsWithoutManifestOwnerMethodCalls: ").Append(AccountsWithoutManifestOwnerMethodCalls).Append("\n"); + sb.Append(" ManifestClassFilter: ").Append(ManifestClassFilter).Append("\n"); sb.Append(" Order: ").Append(Order).Append("\n"); sb.Append(" OptIns: ").Append(OptIns).Append("\n"); sb.Append("}\n"); @@ -359,6 +386,23 @@ public bool Equals(StreamTransactionsRequest input) input.EventsFilter != null && this.EventsFilter.SequenceEqual(input.EventsFilter) ) && + ( + this.AccountsWithManifestOwnerMethodCalls == input.AccountsWithManifestOwnerMethodCalls || + this.AccountsWithManifestOwnerMethodCalls != null && + input.AccountsWithManifestOwnerMethodCalls != null && + this.AccountsWithManifestOwnerMethodCalls.SequenceEqual(input.AccountsWithManifestOwnerMethodCalls) + ) && + ( + this.AccountsWithoutManifestOwnerMethodCalls == input.AccountsWithoutManifestOwnerMethodCalls || + this.AccountsWithoutManifestOwnerMethodCalls != null && + input.AccountsWithoutManifestOwnerMethodCalls != null && + this.AccountsWithoutManifestOwnerMethodCalls.SequenceEqual(input.AccountsWithoutManifestOwnerMethodCalls) + ) && + ( + this.ManifestClassFilter == input.ManifestClassFilter || + (this.ManifestClassFilter != null && + this.ManifestClassFilter.Equals(input.ManifestClassFilter)) + ) && ( this.Order == input.Order || this.Order.Equals(input.Order) @@ -416,6 +460,18 @@ public override int GetHashCode() { hashCode = (hashCode * 59) + this.EventsFilter.GetHashCode(); } + if (this.AccountsWithManifestOwnerMethodCalls != null) + { + hashCode = (hashCode * 59) + this.AccountsWithManifestOwnerMethodCalls.GetHashCode(); + } + if (this.AccountsWithoutManifestOwnerMethodCalls != null) + { + hashCode = (hashCode * 59) + this.AccountsWithoutManifestOwnerMethodCalls.GetHashCode(); + } + if (this.ManifestClassFilter != null) + { + hashCode = (hashCode * 59) + this.ManifestClassFilter.GetHashCode(); + } hashCode = (hashCode * 59) + this.Order.GetHashCode(); if (this.OptIns != null) { diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOf.cs index e794a47b1..2c097a37c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -166,9 +166,12 @@ public enum OrderEnum /// manifestResourcesFilter. /// affectedGlobalEntitiesFilter. /// eventsFilter. + /// accountsWithManifestOwnerMethodCalls. + /// accountsWithoutManifestOwnerMethodCalls. + /// manifestClassFilter. /// Configures the order of returned result set. Defaults to `desc`.. /// optIns. - public StreamTransactionsRequestAllOf(KindFilterEnum? kindFilter = default(KindFilterEnum?), List manifestAccountsWithdrawnFromFilter = default(List), List manifestAccountsDepositedIntoFilter = default(List), List manifestResourcesFilter = default(List), List affectedGlobalEntitiesFilter = default(List), List eventsFilter = default(List), OrderEnum? order = default(OrderEnum?), TransactionDetailsOptIns optIns = default(TransactionDetailsOptIns)) + public StreamTransactionsRequestAllOf(KindFilterEnum? kindFilter = default(KindFilterEnum?), List manifestAccountsWithdrawnFromFilter = default(List), List manifestAccountsDepositedIntoFilter = default(List), List manifestResourcesFilter = default(List), List affectedGlobalEntitiesFilter = default(List), List eventsFilter = default(List), List accountsWithManifestOwnerMethodCalls = default(List), List accountsWithoutManifestOwnerMethodCalls = default(List), StreamTransactionsRequestAllOfManifestClassFilter manifestClassFilter = default(StreamTransactionsRequestAllOfManifestClassFilter), OrderEnum? order = default(OrderEnum?), TransactionDetailsOptIns optIns = default(TransactionDetailsOptIns)) { this.KindFilter = kindFilter; this.ManifestAccountsWithdrawnFromFilter = manifestAccountsWithdrawnFromFilter; @@ -176,6 +179,9 @@ public enum OrderEnum this.ManifestResourcesFilter = manifestResourcesFilter; this.AffectedGlobalEntitiesFilter = affectedGlobalEntitiesFilter; this.EventsFilter = eventsFilter; + this.AccountsWithManifestOwnerMethodCalls = accountsWithManifestOwnerMethodCalls; + this.AccountsWithoutManifestOwnerMethodCalls = accountsWithoutManifestOwnerMethodCalls; + this.ManifestClassFilter = manifestClassFilter; this.Order = order; this.OptIns = optIns; } @@ -210,6 +216,24 @@ public enum OrderEnum [DataMember(Name = "events_filter", EmitDefaultValue = true)] public List EventsFilter { get; set; } + /// + /// Gets or Sets AccountsWithManifestOwnerMethodCalls + /// + [DataMember(Name = "accounts_with_manifest_owner_method_calls", EmitDefaultValue = true)] + public List AccountsWithManifestOwnerMethodCalls { get; set; } + + /// + /// Gets or Sets AccountsWithoutManifestOwnerMethodCalls + /// + [DataMember(Name = "accounts_without_manifest_owner_method_calls", EmitDefaultValue = true)] + public List AccountsWithoutManifestOwnerMethodCalls { get; set; } + + /// + /// Gets or Sets ManifestClassFilter + /// + [DataMember(Name = "manifest_class_filter", EmitDefaultValue = true)] + public StreamTransactionsRequestAllOfManifestClassFilter ManifestClassFilter { get; set; } + /// /// Gets or Sets OptIns /// @@ -230,6 +254,9 @@ public override string ToString() sb.Append(" ManifestResourcesFilter: ").Append(ManifestResourcesFilter).Append("\n"); sb.Append(" AffectedGlobalEntitiesFilter: ").Append(AffectedGlobalEntitiesFilter).Append("\n"); sb.Append(" EventsFilter: ").Append(EventsFilter).Append("\n"); + sb.Append(" AccountsWithManifestOwnerMethodCalls: ").Append(AccountsWithManifestOwnerMethodCalls).Append("\n"); + sb.Append(" AccountsWithoutManifestOwnerMethodCalls: ").Append(AccountsWithoutManifestOwnerMethodCalls).Append("\n"); + sb.Append(" ManifestClassFilter: ").Append(ManifestClassFilter).Append("\n"); sb.Append(" Order: ").Append(Order).Append("\n"); sb.Append(" OptIns: ").Append(OptIns).Append("\n"); sb.Append("}\n"); @@ -301,6 +328,23 @@ public bool Equals(StreamTransactionsRequestAllOf input) input.EventsFilter != null && this.EventsFilter.SequenceEqual(input.EventsFilter) ) && + ( + this.AccountsWithManifestOwnerMethodCalls == input.AccountsWithManifestOwnerMethodCalls || + this.AccountsWithManifestOwnerMethodCalls != null && + input.AccountsWithManifestOwnerMethodCalls != null && + this.AccountsWithManifestOwnerMethodCalls.SequenceEqual(input.AccountsWithManifestOwnerMethodCalls) + ) && + ( + this.AccountsWithoutManifestOwnerMethodCalls == input.AccountsWithoutManifestOwnerMethodCalls || + this.AccountsWithoutManifestOwnerMethodCalls != null && + input.AccountsWithoutManifestOwnerMethodCalls != null && + this.AccountsWithoutManifestOwnerMethodCalls.SequenceEqual(input.AccountsWithoutManifestOwnerMethodCalls) + ) && + ( + this.ManifestClassFilter == input.ManifestClassFilter || + (this.ManifestClassFilter != null && + this.ManifestClassFilter.Equals(input.ManifestClassFilter)) + ) && ( this.Order == input.Order || this.Order.Equals(input.Order) @@ -342,6 +386,18 @@ public override int GetHashCode() { hashCode = (hashCode * 59) + this.EventsFilter.GetHashCode(); } + if (this.AccountsWithManifestOwnerMethodCalls != null) + { + hashCode = (hashCode * 59) + this.AccountsWithManifestOwnerMethodCalls.GetHashCode(); + } + if (this.AccountsWithoutManifestOwnerMethodCalls != null) + { + hashCode = (hashCode * 59) + this.AccountsWithoutManifestOwnerMethodCalls.GetHashCode(); + } + if (this.ManifestClassFilter != null) + { + hashCode = (hashCode * 59) + this.ManifestClassFilter.GetHashCode(); + } hashCode = (hashCode * 59) + this.Order.GetHashCode(); if (this.OptIns != null) { diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOfManifestClassFilter.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOfManifestClassFilter.cs new file mode 100644 index 000000000..699ad9797 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestAllOfManifestClassFilter.cs @@ -0,0 +1,198 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +/* + * Radix Gateway API - Babylon + * + * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. + * + * The version of the OpenAPI document: v1.4.0 + * Generated by: https://github.com/openapitools/openapi-generator.git + */ + + +using System; +using System.Collections; +using System.Collections.Generic; +using System.Collections.ObjectModel; +using System.Linq; +using System.IO; +using System.Runtime.Serialization; +using System.Text; +using System.Text.RegularExpressions; +using Newtonsoft.Json; +using Newtonsoft.Json.Converters; +using Newtonsoft.Json.Linq; +using FileParameter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.FileParameter; +using OpenAPIDateConverter = RadixDlt.NetworkGateway.GatewayApiSdk.Client.OpenAPIDateConverter; + +namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model +{ + /// + /// StreamTransactionsRequestAllOfManifestClassFilter + /// + [DataContract(Name = "StreamTransactionsRequest_allOf_manifest_class_filter")] + public partial class StreamTransactionsRequestAllOfManifestClassFilter : IEquatable + { + + /// + /// Gets or Sets Class + /// + [DataMember(Name = "class", IsRequired = true, EmitDefaultValue = true)] + public ManifestClass Class { get; set; } + /// + /// Initializes a new instance of the class. + /// + [JsonConstructorAttribute] + protected StreamTransactionsRequestAllOfManifestClassFilter() { } + /// + /// Initializes a new instance of the class. + /// + /// _class (required). + /// matchOnlyMostSpecific (default to false). + public StreamTransactionsRequestAllOfManifestClassFilter(ManifestClass _class = default(ManifestClass), bool matchOnlyMostSpecific = false) + { + this.Class = _class; + this.MatchOnlyMostSpecific = matchOnlyMostSpecific; + } + + /// + /// Gets or Sets MatchOnlyMostSpecific + /// + [DataMember(Name = "match_only_most_specific", EmitDefaultValue = true)] + public bool MatchOnlyMostSpecific { get; set; } + + /// + /// Returns the string presentation of the object + /// + /// String presentation of the object + public override string ToString() + { + StringBuilder sb = new StringBuilder(); + sb.Append("class StreamTransactionsRequestAllOfManifestClassFilter {\n"); + sb.Append(" Class: ").Append(Class).Append("\n"); + sb.Append(" MatchOnlyMostSpecific: ").Append(MatchOnlyMostSpecific).Append("\n"); + sb.Append("}\n"); + return sb.ToString(); + } + + /// + /// Returns the JSON string presentation of the object + /// + /// JSON string presentation of the object + public virtual string ToJson() + { + return Newtonsoft.Json.JsonConvert.SerializeObject(this, Newtonsoft.Json.Formatting.Indented); + } + + /// + /// Returns true if objects are equal + /// + /// Object to be compared + /// Boolean + public override bool Equals(object input) + { + return this.Equals(input as StreamTransactionsRequestAllOfManifestClassFilter); + } + + /// + /// Returns true if StreamTransactionsRequestAllOfManifestClassFilter instances are equal + /// + /// Instance of StreamTransactionsRequestAllOfManifestClassFilter to be compared + /// Boolean + public bool Equals(StreamTransactionsRequestAllOfManifestClassFilter input) + { + if (input == null) + { + return false; + } + return + ( + this.Class == input.Class || + this.Class.Equals(input.Class) + ) && + ( + this.MatchOnlyMostSpecific == input.MatchOnlyMostSpecific || + this.MatchOnlyMostSpecific.Equals(input.MatchOnlyMostSpecific) + ); + } + + /// + /// Gets the hash code + /// + /// Hash code + public override int GetHashCode() + { + unchecked // Overflow is fine, just wrap + { + int hashCode = 41; + hashCode = (hashCode * 59) + this.Class.GetHashCode(); + hashCode = (hashCode * 59) + this.MatchOnlyMostSpecific.GetHashCode(); + return hashCode; + } + } + + } + +} diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestEventFilterItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestEventFilterItem.cs index 1ae3b4716..54e1db302 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestEventFilterItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsRequestEventFilterItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponse.cs index a80acbd9a..2a955bbf4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponseAllOf.cs index 9056479f4..dd844f5bd 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/StreamTransactionsResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionBalanceChanges.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionBalanceChanges.cs index 01157b8e1..6d05bbcc9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionBalanceChanges.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionBalanceChanges.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequest.cs index 860e7c59c..c2bbfbdf9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequestAllOf.cs index c1c2b648d..41aceeaa7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponse.cs index ac1774300..8f47d801f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponseAllOf.cs index 46ae1212f..7085ad02c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionCommittedDetailsResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionConstructionResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionConstructionResponse.cs index 17f9248cf..928a6a778 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionConstructionResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionConstructionResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionDetailsOptIns.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionDetailsOptIns.cs index cee9bf035..1cd2c7bb7 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionDetailsOptIns.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionDetailsOptIns.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -107,8 +107,9 @@ public partial class TransactionDetailsOptIns : IEquatableif set to `true`, events inside receipt object is returned. (default to false). /// (true by default) if set to `true`, transaction receipt output is returned. (default to true). /// if set to `true`, all affected global entities by given transaction are returned. (default to false). + /// if set to `true`, manifest instructions for user transactions are returned. (default to false). /// if set to `true`, returns the fungible and non-fungible balance changes. **Warning!** This opt-in might be missing for recently committed transactions, in that case a `null` value will be returned. Retry the request until non-null value is returned. (default to false). - public TransactionDetailsOptIns(bool rawHex = false, bool receiptStateChanges = false, bool receiptFeeSummary = false, bool receiptFeeSource = false, bool receiptFeeDestination = false, bool receiptCostingParameters = false, bool receiptEvents = false, bool receiptOutput = true, bool affectedGlobalEntities = false, bool balanceChanges = false) + public TransactionDetailsOptIns(bool rawHex = false, bool receiptStateChanges = false, bool receiptFeeSummary = false, bool receiptFeeSource = false, bool receiptFeeDestination = false, bool receiptCostingParameters = false, bool receiptEvents = false, bool receiptOutput = true, bool affectedGlobalEntities = false, bool manifestInstructions = false, bool balanceChanges = false) { this.RawHex = rawHex; this.ReceiptStateChanges = receiptStateChanges; @@ -119,6 +120,7 @@ public TransactionDetailsOptIns(bool rawHex = false, bool receiptStateChanges = this.ReceiptEvents = receiptEvents; this.ReceiptOutput = receiptOutput; this.AffectedGlobalEntities = affectedGlobalEntities; + this.ManifestInstructions = manifestInstructions; this.BalanceChanges = balanceChanges; } @@ -185,6 +187,13 @@ public TransactionDetailsOptIns(bool rawHex = false, bool receiptStateChanges = [DataMember(Name = "affected_global_entities", EmitDefaultValue = true)] public bool AffectedGlobalEntities { get; set; } + /// + /// if set to `true`, manifest instructions for user transactions are returned. + /// + /// if set to `true`, manifest instructions for user transactions are returned. + [DataMember(Name = "manifest_instructions", EmitDefaultValue = true)] + public bool ManifestInstructions { get; set; } + /// /// if set to `true`, returns the fungible and non-fungible balance changes. **Warning!** This opt-in might be missing for recently committed transactions, in that case a `null` value will be returned. Retry the request until non-null value is returned. /// @@ -209,6 +218,7 @@ public override string ToString() sb.Append(" ReceiptEvents: ").Append(ReceiptEvents).Append("\n"); sb.Append(" ReceiptOutput: ").Append(ReceiptOutput).Append("\n"); sb.Append(" AffectedGlobalEntities: ").Append(AffectedGlobalEntities).Append("\n"); + sb.Append(" ManifestInstructions: ").Append(ManifestInstructions).Append("\n"); sb.Append(" BalanceChanges: ").Append(BalanceChanges).Append("\n"); sb.Append("}\n"); return sb.ToString(); @@ -281,6 +291,10 @@ public bool Equals(TransactionDetailsOptIns input) this.AffectedGlobalEntities == input.AffectedGlobalEntities || this.AffectedGlobalEntities.Equals(input.AffectedGlobalEntities) ) && + ( + this.ManifestInstructions == input.ManifestInstructions || + this.ManifestInstructions.Equals(input.ManifestInstructions) + ) && ( this.BalanceChanges == input.BalanceChanges || this.BalanceChanges.Equals(input.BalanceChanges) @@ -305,6 +319,7 @@ public override int GetHashCode() hashCode = (hashCode * 59) + this.ReceiptEvents.GetHashCode(); hashCode = (hashCode * 59) + this.ReceiptOutput.GetHashCode(); hashCode = (hashCode * 59) + this.AffectedGlobalEntities.GetHashCode(); + hashCode = (hashCode * 59) + this.ManifestInstructions.GetHashCode(); hashCode = (hashCode * 59) + this.BalanceChanges.GetHashCode(); return hashCode; } diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleBalanceChanges.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleBalanceChanges.cs index 7eb88a6ac..5e1a1a52d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleBalanceChanges.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleBalanceChanges.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChangeType.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChangeType.cs index b890af96a..970b14132 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChangeType.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChangeType.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChanges.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChanges.cs index 5bcec80eb..7255606bf 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChanges.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionFungibleFeeBalanceChanges.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionIntentStatus.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionIntentStatus.cs index 48546026d..6086b877a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionIntentStatus.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionIntentStatus.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNonFungibleBalanceChanges.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNonFungibleBalanceChanges.cs index 602f218fb..290df4a19 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNonFungibleBalanceChanges.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNonFungibleBalanceChanges.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNotFoundError.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNotFoundError.cs index 528b1e5ff..75fa6586d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNotFoundError.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionNotFoundError.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadGatewayHandlingStatus.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadGatewayHandlingStatus.cs index 371acbc19..7f0992ecb 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadGatewayHandlingStatus.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadGatewayHandlingStatus.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadStatus.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadStatus.cs index 4a65dafaa..3b75dbd28 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadStatus.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPayloadStatus.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequest.cs index be31e729b..68f88d4b4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequestFlags.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequestFlags.cs index 49b7859ae..40d36c98d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequestFlags.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewRequestFlags.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponse.cs index 312a26af8..9dae314f9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponseLogsInner.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponseLogsInner.cs index d13c1ecf2..b41b6bcef 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponseLogsInner.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionPreviewResponseLogsInner.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionReceipt.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionReceipt.cs index e56e33358..50ddaac3d 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionReceipt.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionReceipt.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatus.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatus.cs index 7b04386cd..b563059f6 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatus.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatus.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequest.cs index 3ecf6d9b0..61d6e6e16 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequestAllOf.cs index 1b3ae3a93..5a39c7162 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponse.cs index 0b659dcf5..579cb48f9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -121,8 +121,9 @@ protected TransactionStatusResponse() { } /// An additional description to clarify the intent status. (required). /// knownPayloads (required). /// If the intent was committed, this gives the state version when this intent was committed. . + /// The epoch number at which the transaction is guaranteed to get permanently rejected by the Network due to exceeded epoch range defined when submitting transaction.. /// The most relevant error message received, due to a rejection or commit as failure. Please note that presence of an error message doesn't imply that the intent will definitely reject or fail. This could represent a temporary error (such as out of fees), or an error with a payload which doesn't end up being committed. . - public TransactionStatusResponse(LedgerState ledgerState = default(LedgerState), TransactionStatus status = default(TransactionStatus), TransactionIntentStatus intentStatus = default(TransactionIntentStatus), string intentStatusDescription = default(string), List knownPayloads = default(List), long? committedStateVersion = default(long?), string errorMessage = default(string)) + public TransactionStatusResponse(LedgerState ledgerState = default(LedgerState), TransactionStatus status = default(TransactionStatus), TransactionIntentStatus intentStatus = default(TransactionIntentStatus), string intentStatusDescription = default(string), List knownPayloads = default(List), long? committedStateVersion = default(long?), long? permanentlyRejectsAtEpoch = default(long?), string errorMessage = default(string)) { // to ensure "ledgerState" is required (not null) if (ledgerState == null) @@ -145,6 +146,7 @@ protected TransactionStatusResponse() { } } this.KnownPayloads = knownPayloads; this.CommittedStateVersion = committedStateVersion; + this.PermanentlyRejectsAtEpoch = permanentlyRejectsAtEpoch; this.ErrorMessage = errorMessage; } @@ -174,6 +176,13 @@ protected TransactionStatusResponse() { } [DataMember(Name = "committed_state_version", EmitDefaultValue = true)] public long? CommittedStateVersion { get; set; } + /// + /// The epoch number at which the transaction is guaranteed to get permanently rejected by the Network due to exceeded epoch range defined when submitting transaction. + /// + /// The epoch number at which the transaction is guaranteed to get permanently rejected by the Network due to exceeded epoch range defined when submitting transaction. + [DataMember(Name = "permanently_rejects_at_epoch", EmitDefaultValue = true)] + public long? PermanentlyRejectsAtEpoch { get; set; } + /// /// The most relevant error message received, due to a rejection or commit as failure. Please note that presence of an error message doesn't imply that the intent will definitely reject or fail. This could represent a temporary error (such as out of fees), or an error with a payload which doesn't end up being committed. /// @@ -195,6 +204,7 @@ public override string ToString() sb.Append(" IntentStatusDescription: ").Append(IntentStatusDescription).Append("\n"); sb.Append(" KnownPayloads: ").Append(KnownPayloads).Append("\n"); sb.Append(" CommittedStateVersion: ").Append(CommittedStateVersion).Append("\n"); + sb.Append(" PermanentlyRejectsAtEpoch: ").Append(PermanentlyRejectsAtEpoch).Append("\n"); sb.Append(" ErrorMessage: ").Append(ErrorMessage).Append("\n"); sb.Append("}\n"); return sb.ToString(); @@ -260,6 +270,11 @@ public bool Equals(TransactionStatusResponse input) (this.CommittedStateVersion != null && this.CommittedStateVersion.Equals(input.CommittedStateVersion)) ) && + ( + this.PermanentlyRejectsAtEpoch == input.PermanentlyRejectsAtEpoch || + (this.PermanentlyRejectsAtEpoch != null && + this.PermanentlyRejectsAtEpoch.Equals(input.PermanentlyRejectsAtEpoch)) + ) && ( this.ErrorMessage == input.ErrorMessage || (this.ErrorMessage != null && @@ -294,6 +309,10 @@ public override int GetHashCode() { hashCode = (hashCode * 59) + this.CommittedStateVersion.GetHashCode(); } + if (this.PermanentlyRejectsAtEpoch != null) + { + hashCode = (hashCode * 59) + this.PermanentlyRejectsAtEpoch.GetHashCode(); + } if (this.ErrorMessage != null) { hashCode = (hashCode * 59) + this.ErrorMessage.GetHashCode(); diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseAllOf.cs index 3e48e1e1a..42c543765 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ @@ -120,8 +120,9 @@ protected TransactionStatusResponseAllOf() { } /// An additional description to clarify the intent status. (required). /// knownPayloads (required). /// If the intent was committed, this gives the state version when this intent was committed. . + /// The epoch number at which the transaction is guaranteed to get permanently rejected by the Network due to exceeded epoch range defined when submitting transaction.. /// The most relevant error message received, due to a rejection or commit as failure. Please note that presence of an error message doesn't imply that the intent will definitely reject or fail. This could represent a temporary error (such as out of fees), or an error with a payload which doesn't end up being committed. . - public TransactionStatusResponseAllOf(TransactionStatus status = default(TransactionStatus), TransactionIntentStatus intentStatus = default(TransactionIntentStatus), string intentStatusDescription = default(string), List knownPayloads = default(List), long? committedStateVersion = default(long?), string errorMessage = default(string)) + public TransactionStatusResponseAllOf(TransactionStatus status = default(TransactionStatus), TransactionIntentStatus intentStatus = default(TransactionIntentStatus), string intentStatusDescription = default(string), List knownPayloads = default(List), long? committedStateVersion = default(long?), long? permanentlyRejectsAtEpoch = default(long?), string errorMessage = default(string)) { this.Status = status; this.IntentStatus = intentStatus; @@ -138,6 +139,7 @@ protected TransactionStatusResponseAllOf() { } } this.KnownPayloads = knownPayloads; this.CommittedStateVersion = committedStateVersion; + this.PermanentlyRejectsAtEpoch = permanentlyRejectsAtEpoch; this.ErrorMessage = errorMessage; } @@ -161,6 +163,13 @@ protected TransactionStatusResponseAllOf() { } [DataMember(Name = "committed_state_version", EmitDefaultValue = true)] public long? CommittedStateVersion { get; set; } + /// + /// The epoch number at which the transaction is guaranteed to get permanently rejected by the Network due to exceeded epoch range defined when submitting transaction. + /// + /// The epoch number at which the transaction is guaranteed to get permanently rejected by the Network due to exceeded epoch range defined when submitting transaction. + [DataMember(Name = "permanently_rejects_at_epoch", EmitDefaultValue = true)] + public long? PermanentlyRejectsAtEpoch { get; set; } + /// /// The most relevant error message received, due to a rejection or commit as failure. Please note that presence of an error message doesn't imply that the intent will definitely reject or fail. This could represent a temporary error (such as out of fees), or an error with a payload which doesn't end up being committed. /// @@ -181,6 +190,7 @@ public override string ToString() sb.Append(" IntentStatusDescription: ").Append(IntentStatusDescription).Append("\n"); sb.Append(" KnownPayloads: ").Append(KnownPayloads).Append("\n"); sb.Append(" CommittedStateVersion: ").Append(CommittedStateVersion).Append("\n"); + sb.Append(" PermanentlyRejectsAtEpoch: ").Append(PermanentlyRejectsAtEpoch).Append("\n"); sb.Append(" ErrorMessage: ").Append(ErrorMessage).Append("\n"); sb.Append("}\n"); return sb.ToString(); @@ -241,6 +251,11 @@ public bool Equals(TransactionStatusResponseAllOf input) (this.CommittedStateVersion != null && this.CommittedStateVersion.Equals(input.CommittedStateVersion)) ) && + ( + this.PermanentlyRejectsAtEpoch == input.PermanentlyRejectsAtEpoch || + (this.PermanentlyRejectsAtEpoch != null && + this.PermanentlyRejectsAtEpoch.Equals(input.PermanentlyRejectsAtEpoch)) + ) && ( this.ErrorMessage == input.ErrorMessage || (this.ErrorMessage != null && @@ -271,6 +286,10 @@ public override int GetHashCode() { hashCode = (hashCode * 59) + this.CommittedStateVersion.GetHashCode(); } + if (this.PermanentlyRejectsAtEpoch != null) + { + hashCode = (hashCode * 59) + this.PermanentlyRejectsAtEpoch.GetHashCode(); + } if (this.ErrorMessage != null) { hashCode = (hashCode * 59) + this.ErrorMessage.GetHashCode(); diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseKnownPayloadItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseKnownPayloadItem.cs index 6ab04a975..78e50f41e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseKnownPayloadItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionStatusResponseKnownPayloadItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitRequest.cs index ab0495451..d57dfe376 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitResponse.cs index e0cdf1710..4090ba84a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/TransactionSubmitResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidationErrorsAtPath.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidationErrorsAtPath.cs index 0a34f135d..95989b95b 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidationErrorsAtPath.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidationErrorsAtPath.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollection.cs index 70b25ad39..85767fb98 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionAllOf.cs index feb534a87..5ef1ef002 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItem.cs index 0ebef4817..d07597e80 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemActiveInEpoch.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemActiveInEpoch.cs index df5b0a0c2..1df8942f4 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemActiveInEpoch.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemActiveInEpoch.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactor.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactor.cs index f0521679a..f72866ce2 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactor.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactor.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorCurrent.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorCurrent.cs index 4b7de2408..5985974a1 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorCurrent.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorCurrent.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorPending.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorPending.cs index 23db1b874..25889431e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorPending.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorCollectionItemEffectiveFeeFactorPending.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollection.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollection.cs index 9ad708de5..6b108e648 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollection.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollection.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollectionItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollectionItem.cs index 887bfd2e0..0aaa3d43e 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollectionItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorUptimeCollectionItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorVaultItem.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorVaultItem.cs index c4f020a67..74e1ce51a 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorVaultItem.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorVaultItem.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequest.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequest.cs index 22e4c272e..9094da4a0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequest.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequest.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequestAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequestAllOf.cs index 149865c85..ac25a45d0 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequestAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeRequestAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponse.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponse.cs index 0495b47d5..bc1f1eb0c 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponse.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponse.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponseAllOf.cs b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponseAllOf.cs index 58cc7f57d..34be7cab9 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponseAllOf.cs +++ b/src/RadixDlt.NetworkGateway.GatewayApiSdk/generated/Model/ValidatorsUptimeResponseAllOf.cs @@ -67,7 +67,7 @@ * * This API is exposed by the Babylon Radix Gateway to enable clients to efficiently query current and historic state on the RadixDLT ledger, and intelligently handle transaction submission. It is designed for use by wallets and explorers, and for light queries from front-end dApps. For exchange/asset integrations, back-end dApp integrations, or simple use cases, you should consider using the Core API on a Node. A Gateway is only needed for reading historic snapshots of ledger states or a more robust set-up. The Gateway API is implemented by the [Network Gateway](https://github.com/radixdlt/babylon-gateway), which is configured to read from [full node(s)](https://github.com/radixdlt/babylon-node) to extract and index data from the network. This document is an API reference documentation, visit [User Guide](https://docs.radixdlt.com/) to learn more about how to run a Gateway of your own. ## Migration guide Please see [the latest release notes](https://github.com/radixdlt/babylon-gateway/releases). ## Integration and forward compatibility guarantees All responses may have additional fields added at any release, so clients are advised to use JSON parsers which ignore unknown fields on JSON objects. When the Radix protocol is updated, new functionality may be added, and so discriminated unions returned by the API may need to be updated to have new variants added, corresponding to the updated data. Clients may need to update in advance to be able to handle these new variants when a protocol update comes out. On the very rare occasions we need to make breaking changes to the API, these will be warned in advance with deprecation notices on previous versions. These deprecation notices will include a safe migration path. Deprecation notes or breaking changes will be flagged clearly in release notes for new versions of the Gateway. The Gateway DB schema is not subject to any compatibility guarantees, and may be changed at any release. DB changes will be flagged in the release notes so clients doing custom DB integrations can prepare. * - * The version of the OpenAPI document: v1.3.0 + * The version of the OpenAPI document: v1.4.0 * Generated by: https://github.com/openapitools/openapi-generator.git */ diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/CommonDbContext.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/CommonDbContext.cs index bab3fa8f9..b0fcbc390 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/CommonDbContext.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/CommonDbContext.cs @@ -80,8 +80,6 @@ internal abstract class CommonDbContext : DbContext { private const string DiscriminatorColumnName = "discriminator"; - public DbSet NetworkConfiguration => Set(); - /// /// Gets LedgerTransactions. /// @@ -139,7 +137,9 @@ internal abstract class CommonDbContext : DbContext public DbSet EntityRoleAssignmentsAggregateHistory => Set(); - public DbSet ComponentMethodRoyaltyEntryHistory => Set(); + public DbSet ComponentEntityMethodRoyaltyEntryHistory => Set(); + + public DbSet ComponentEntityMethodRoyaltyAggregateHistory => Set(); public DbSet PackageBlueprintHistory => Set(); @@ -149,6 +149,8 @@ internal abstract class CommonDbContext : DbContext public DbSet KeyValueStoreEntryHistory => Set(); + public DbSet KeyValueStoreAggregateHistory => Set(); + public DbSet ValidatorEmissionStatistics => Set(); public DbSet NonFungibleSchemaHistory => Set(); @@ -169,6 +171,7 @@ protected override void OnModelCreating(ModelBuilder modelBuilder) modelBuilder.HasPostgresEnum(); modelBuilder.HasPostgresEnum(); modelBuilder.HasPostgresEnum(); + modelBuilder.HasPostgresEnum(); modelBuilder.HasPostgresEnum(); modelBuilder.HasPostgresEnum(); modelBuilder.HasPostgresEnum(); @@ -246,6 +249,7 @@ private static void HookupTransactions(ModelBuilder modelBuilder) .HasValue(LedgerTransactionMarkerType.Event) .HasValue(LedgerTransactionMarkerType.Origin) .HasValue(LedgerTransactionMarkerType.ManifestAddress) + .HasValue(LedgerTransactionMarkerType.ManifestClass) .HasValue(LedgerTransactionMarkerType.AffectedGlobalEntity); modelBuilder @@ -271,6 +275,11 @@ private static void HookupTransactions(ModelBuilder modelBuilder) .Entity() .HasIndex(e => new { e.EntityId, e.StateVersion }) .HasFilter("discriminator = 'affected_global_entity'"); + + modelBuilder + .Entity() + .HasIndex(e => new { TransactionType = e.LedgerTransactionManifestClass, e.IsMostSpecific, e.StateVersion }) + .HasFilter("discriminator = 'manifest_class'"); } private static void HookupPendingTransactions(ModelBuilder modelBuilder) @@ -443,6 +452,10 @@ private static void HookupHistory(ModelBuilder modelBuilder) .Entity() .HasIndex(e => new { e.EntityId, e.MethodName, e.FromStateVersion }); + modelBuilder + .Entity() + .HasIndex(e => new { e.EntityId, e.FromStateVersion }); + modelBuilder .Entity() .HasIndex(e => new { e.ResourceEntityId, e.FromStateVersion }); @@ -512,6 +525,10 @@ private static void HookupHistory(ModelBuilder modelBuilder) .Entity() .HasIndex(e => new { e.KeyValueStoreEntityId, e.Key, e.FromStateVersion }); + modelBuilder + .Entity() + .HasIndex(e => new { e.KeyValueStoreEntityId, e.FromStateVersion }); + modelBuilder .Entity() .HasIndex(e => new { e.KeyValueStoreEntityId, e.FromStateVersion }); @@ -525,6 +542,7 @@ private static void HookupStatistics(ModelBuilder modelBuilder) { modelBuilder .Entity() - .HasIndex(e => new { e.ValidatorEntityId, e.EpochNumber }); + .HasIndex(e => new { e.ValidatorEntityId, e.EpochNumber }) + .IncludeProperties(e => new { e.ProposalsMade, e.ProposalsMissed }); } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/CustomTypes.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/CustomTypes.cs index d86c1b449..7c3734a2b 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/CustomTypes.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/CustomTypes.cs @@ -97,6 +97,7 @@ public static void EnsureConfigured() NpgsqlConnection.GlobalTypeMapper.MapEnum(); NpgsqlConnection.GlobalTypeMapper.MapEnum(); NpgsqlConnection.GlobalTypeMapper.MapEnum(); + NpgsqlConnection.GlobalTypeMapper.MapEnum(); NpgsqlConnection.GlobalTypeMapper.MapEnum(); NpgsqlConnection.GlobalTypeMapper.MapEnum(); NpgsqlConnection.GlobalTypeMapper.MapEnum(); diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/DataAggregatorBuilderExtensions.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/DataAggregatorBuilderExtensions.cs index d7e757b95..e1ac9adc9 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/DataAggregatorBuilderExtensions.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/DataAggregatorBuilderExtensions.cs @@ -90,7 +90,6 @@ public static DataAggregatorBuilder AddPostgresPersistenceCore(this DataAggregat .AddSingleton() .AddSingleton() .AddSingleton() - .AddSingleton() .AddSingleton() .AddSingleton() .AddSingleton() diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/DbQueryExtensions.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/DbQueryExtensions.cs index 8dbdc4b04..14870d216 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/DbQueryExtensions.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/DbQueryExtensions.cs @@ -88,37 +88,35 @@ public static IQueryable GetTopLedgerTransaction( } /// - /// Returns most recently committed ledger transaction at or before given state version. + /// Returns ledger transaction committed at given state version. /// /// /// A LedgerTransaction row contains large blobs, so you must SELECT the fields you need after using this, and not pull down the whole /// ledger transaction row, to avoid possible performance issues. /// - public static IQueryable GetLatestLedgerTransactionBeforeStateVersion(this TDbContext dbContext, long beforeStateVersion) + public static IQueryable GetLatestLedgerTransactionAtStateVersion(this TDbContext dbContext, long stateVersion) where TDbContext : CommonDbContext { return dbContext .LedgerTransactions - .Where(lt => lt.StateVersion <= beforeStateVersion) - .OrderByDescending(lt => lt.StateVersion) + .Where(lt => lt.StateVersion == stateVersion) .Take(1) .AnnotateMetricName(); } /// - /// Returns the first committed ledger transaction at or after given state version. + /// Returns ledger transaction committed at given epoch and round. /// /// /// A LedgerTransaction row contains large blobs, so you must SELECT the fields you need after using this, and not pull down the whole /// ledger transaction row, to avoid possible performance issues. /// - public static IQueryable GetFirstLedgerTransactionAfterStateVersion(this TDbContext dbContext, long afterStateVersion) + public static IQueryable GetLedgerTransactionAtEpochAndRound(this TDbContext dbContext, long epoch, long round) where TDbContext : CommonDbContext { return dbContext .LedgerTransactions - .Where(lt => lt.StateVersion >= afterStateVersion) - .OrderBy(lt => lt.StateVersion) + .Where(lt => lt.Epoch == epoch && lt.RoundInEpoch == round && lt.IndexInRound == 0) .Take(1) .AnnotateMetricName(); } @@ -160,21 +158,4 @@ public static IQueryable GetFirstLedgerTransactionAfterTimest .Take(1) .AnnotateMetricName(); } - - /// - /// Returns ledger transaction committed at given epoch and round. - /// - /// - /// A LedgerTransaction row contains large blobs, so you must SELECT the fields you need after using this, and not pull down the whole - /// ledger transaction row, to avoid possible performance issues. - /// - public static IQueryable GetLedgerTransactionAtEpochAndRound(this TDbContext dbContext, long epoch, long round) - where TDbContext : CommonDbContext - { - return dbContext - .LedgerTransactions - .Where(lt => lt.Epoch == epoch && lt.RoundInEpoch == round && lt.IndexInRound == 0) - .Take(1) - .AnnotateMetricName(); - } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/GatewayApiBuilderExtensions.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/GatewayApiBuilderExtensions.cs index b00fcf8dc..d732f8c19 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/GatewayApiBuilderExtensions.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/GatewayApiBuilderExtensions.cs @@ -79,7 +79,6 @@ public static GatewayApiBuilder AddPostgresPersistence(this GatewayApiBuilder bu { return builder .AddPostgresPersistenceCore() - .AddPostgresPersistenceInitializers() .AddPostgresPersistenceHealthChecks(); } @@ -90,6 +89,7 @@ public static GatewayApiBuilder AddPostgresPersistenceCore(this GatewayApiBuilde .AddScoped() .AddScoped() .AddScoped() + .AddScoped() .AddScoped() .AddScoped() .AddScoped() @@ -97,9 +97,7 @@ public static GatewayApiBuilder AddPostgresPersistenceCore(this GatewayApiBuilde .AddScoped() .AddScoped() .AddScoped() - .AddScoped() .AddScoped() - .AddScoped() .AddSingleton(); CustomTypes.EnsureConfigured(); @@ -134,14 +132,6 @@ public static GatewayApiBuilder AddPostgresPersistenceCore(this GatewayApiBuilde return builder; } - public static GatewayApiBuilder AddPostgresPersistenceInitializers(this GatewayApiBuilder builder) - { - builder.Services - .AddHostedService(); - - return builder; - } - public static GatewayApiBuilder AddPostgresPersistenceHealthChecks(this GatewayApiBuilder builder) { builder diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/GatewayModelExtensions.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/GatewayModelExtensions.cs index c74c26d15..c64d30f56 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/GatewayModelExtensions.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/GatewayModelExtensions.cs @@ -83,6 +83,22 @@ namespace RadixDlt.NetworkGateway.PostgresIntegration; internal static class GatewayModelExtensions { + public static GatewayModel.ManifestClass ToGatewayModel(this LedgerTransactionManifestClass input) + { + return input switch + { + LedgerTransactionManifestClass.General => GatewayModel.ManifestClass.General, + LedgerTransactionManifestClass.Transfer => GatewayModel.ManifestClass.Transfer, + LedgerTransactionManifestClass.ValidatorStake => GatewayModel.ManifestClass.ValidatorStake, + LedgerTransactionManifestClass.ValidatorUnstake => GatewayModel.ManifestClass.ValidatorUnstake, + LedgerTransactionManifestClass.ValidatorClaim => GatewayModel.ManifestClass.ValidatorClaim, + LedgerTransactionManifestClass.AccountDepositSettingsUpdate => GatewayModel.ManifestClass.AccountDepositSettingsUpdate, + LedgerTransactionManifestClass.PoolContribution => GatewayModel.ManifestClass.PoolContribution, + LedgerTransactionManifestClass.PoolRedemption => GatewayModel.ManifestClass.PoolRedemption, + _ => throw new ArgumentOutOfRangeException(nameof(input), input, null), + }; + } + public static GatewayModel.NonFungibleIdType ToGatewayModel(this NonFungibleIdType nonFungibleIdType) { return nonFungibleIdType switch @@ -118,6 +134,8 @@ public static GatewayModel.CommittedTransactionInfo ToGatewayModel( string? intentHash = null; string? rawHex = null; JRaw? message = null; + string? manifestInstructions = null; + List? manifestClasses = null; if (lt is UserLedgerTransaction ult) { @@ -125,6 +143,8 @@ public static GatewayModel.CommittedTransactionInfo ToGatewayModel( intentHash = ult.IntentHash; rawHex = optIns.RawHex ? ult.RawPayload.ToHex() : null; message = ult.Message != null ? new JRaw(ult.Message) : null; + manifestInstructions = optIns.ManifestInstructions ? ult.ManifestInstructions : null; + manifestClasses = ult.ManifestClasses.Select(mc => mc.ToGatewayModel()).ToList(); } var receipt = new GatewayModel.TransactionReceipt @@ -156,7 +176,9 @@ public static GatewayModel.CommittedTransactionInfo ToGatewayModel( rawHex: rawHex, receipt: receipt, message: message, - balanceChanges: optIns.BalanceChanges ? transactionBalanceChanges : null + balanceChanges: optIns.BalanceChanges ? transactionBalanceChanges : null, + manifestInstructions: manifestInstructions, + manifestClasses: manifestClasses ); } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ComponentMethodRoyaltyProcessor.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ComponentMethodRoyaltyProcessor.cs new file mode 100644 index 000000000..8825de205 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ComponentMethodRoyaltyProcessor.cs @@ -0,0 +1,282 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using NpgsqlTypes; +using RadixDlt.NetworkGateway.PostgresIntegration.Models; +using System.Collections.Generic; +using System.Linq; +using System.Threading.Tasks; +using CoreModel = RadixDlt.CoreApiSdk.Model; + +namespace RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; + +internal record struct ComponentMethodRoyaltyEntryDbLookup(long EntityId, string MethodName); + +internal record struct ComponentMethodRoyaltyChangePointerLookup(long EntityId, long StateVersion); + +internal record ComponentMethodRoyaltyChangePointer(ReferencedEntity ReferencedEntity) +{ + public IList Entries { get; } = new List(); +} + +internal class ComponentMethodRoyaltyProcessor +{ + private readonly ProcessorContext _context; + + private Dictionary _changePointers = new(); + private List _changeOrder = new(); + + private Dictionary _mostRecentAggregates = new(); + private Dictionary _mostRecentEntries = new(); + + private List _aggregatesToAdd = new(); + private List _entriesToAdd = new(); + + public ComponentMethodRoyaltyProcessor(ProcessorContext context) + { + _context = context; + } + + public void VisitUpsert(CoreModel.Substate substateData, ReferencedEntity referencedEntity, long stateVersion) + { + if (substateData is CoreModel.RoyaltyModuleMethodRoyaltyEntrySubstate methodRoyaltyEntry) + { + _changePointers + .GetOrAdd(new ComponentMethodRoyaltyChangePointerLookup(referencedEntity.DatabaseId, stateVersion), lookup => + { + _changeOrder.Add(lookup); + + return new ComponentMethodRoyaltyChangePointer(referencedEntity); + }) + .Entries.Add(methodRoyaltyEntry); + } + } + + public void ProcessChanges() + { + foreach (var lookup in _changeOrder) + { + var change = _changePointers[lookup]; + + ComponentMethodRoyaltyAggregateHistory aggregate; + + if (!_mostRecentAggregates.TryGetValue(lookup.EntityId, out var previousAggregate) || previousAggregate.FromStateVersion != lookup.StateVersion) + { + aggregate = new ComponentMethodRoyaltyAggregateHistory + { + Id = _context.Sequences.ComponentMethodRoyaltyAggregateHistorySequence++, + FromStateVersion = lookup.StateVersion, + EntityId = lookup.EntityId, + EntryIds = new List(), + }; + + if (previousAggregate != null) + { + aggregate.EntryIds.AddRange(previousAggregate.EntryIds); + } + + _aggregatesToAdd.Add(aggregate); + _mostRecentAggregates[lookup.EntityId] = aggregate; + } + else + { + aggregate = previousAggregate; + } + + foreach (var entry in change.Entries) + { + var entryLookup = new ComponentMethodRoyaltyEntryDbLookup(lookup.EntityId, entry.Key.MethodName); + var entryHistory = new ComponentMethodRoyaltyEntryHistory + { + Id = _context.Sequences.ComponentMethodRoyaltyEntryHistorySequence++, + FromStateVersion = lookup.StateVersion, + EntityId = lookup.EntityId, + MethodName = entry.Key.MethodName, + RoyaltyAmount = entry.Value?.ToJson(), + IsLocked = entry.IsLocked, + }; + + _entriesToAdd.Add(entryHistory); + + if (_mostRecentEntries.TryGetValue(entryLookup, out var previousEntry)) + { + var currentPosition = aggregate.EntryIds.IndexOf(previousEntry.Id); + + if (currentPosition != -1) + { + aggregate.EntryIds.RemoveAt(currentPosition); + } + } + + // TODO introduce entry.IsDeleted extension method + if (entry.Value != null) + { + aggregate.EntryIds.Insert(0, entryHistory.Id); + } + + _mostRecentEntries[entryLookup] = entryHistory; + } + } + } + + public async Task LoadMostRecent() + { + _mostRecentEntries = await MostRecentComponentMethodRoyaltyEntryHistory(); + _mostRecentAggregates = await MostRecentComponentMethodRoyaltyAggregateHistory(); + } + + public async Task SaveEntities() + { + var rowsInserted = 0; + + rowsInserted += await CopyComponentMethodRoyaltyEntryHistory(); + rowsInserted += await CopyComponentMethodRoyaltyAggregateHistory(); + + return rowsInserted; + } + + private Task> MostRecentComponentMethodRoyaltyEntryHistory() + { + var lookupSet = new HashSet(); + + foreach (var change in _changePointers.Values) + { + foreach (var entry in change.Entries) + { + lookupSet.Add(new ComponentMethodRoyaltyEntryDbLookup(change.ReferencedEntity.DatabaseId, entry.Key.MethodName)); + } + } + + if (!lookupSet.Unzip(x => x.EntityId, x => x.MethodName, out var entityIds, out var methodNames)) + { + return Task.FromResult(new Dictionary()); + } + + return _context.ReadHelper.MostRecent( + @$" +WITH variables (entity_id, method_name) AS ( + SELECT UNNEST({entityIds}), UNNEST({methodNames}) +) +SELECT cmreh.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM component_method_royalty_entry_history + WHERE entity_id = variables.entity_id AND method_name = variables.method_name + ORDER BY from_state_version DESC + LIMIT 1 +) cmreh ON true;", + e => new ComponentMethodRoyaltyEntryDbLookup(e.EntityId, e.MethodName)); + } + + private Task> MostRecentComponentMethodRoyaltyAggregateHistory() + { + var entityIds = _changeOrder.Select(x => x.EntityId).ToHashSet().ToList(); + + if (!entityIds.Any()) + { + return Task.FromResult(new Dictionary()); + } + + return _context.ReadHelper.MostRecent( + $@" +WITH variables (entity_id) AS ( + SELECT UNNEST({entityIds}) +) +SELECT cmrah.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM component_method_royalty_aggregate_history + WHERE entity_id = variables.entity_id + ORDER BY from_state_version DESC + LIMIT 1 +) cmrah ON true;", + e => e.EntityId); + } + + private Task CopyComponentMethodRoyaltyEntryHistory() => _context.WriteHelper.Copy( + _entriesToAdd, + "COPY component_method_royalty_entry_history (id, from_state_version, entity_id, method_name, royalty_amount, is_locked) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.MethodName, NpgsqlDbType.Text, token); + await writer.WriteAsync(e.RoyaltyAmount, NpgsqlDbType.Jsonb, token); + await writer.WriteAsync(e.IsLocked, NpgsqlDbType.Boolean, token); + }); + + private Task CopyComponentMethodRoyaltyAggregateHistory() => _context.WriteHelper.Copy( + _aggregatesToAdd, + "COPY component_method_royalty_aggregate_history (id, from_state_version, entity_id, entry_ids) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.EntryIds, NpgsqlDbType.Array | NpgsqlDbType.Bigint, token); + }); +} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/EntityRoleAssignmentProcessor.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/EntityRoleAssignmentProcessor.cs new file mode 100644 index 000000000..7ebc87203 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/EntityRoleAssignmentProcessor.cs @@ -0,0 +1,330 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using NpgsqlTypes; +using RadixDlt.NetworkGateway.Abstractions.Model; +using RadixDlt.NetworkGateway.PostgresIntegration.Models; +using System; +using System.Collections.Generic; +using System.Linq; +using System.Threading.Tasks; +using CoreModel = RadixDlt.CoreApiSdk.Model; + +namespace RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; + +internal record struct RoleAssignmentEntryDbLookup(long EntityId, string KeyRole, ModuleId KeyModule); + +internal record struct RoleAssignmentsChangePointerLookup(long EntityId, long StateVersion); + +internal record RoleAssignmentsChangePointer(ReferencedEntity ReferencedEntity) +{ + public CoreModel.RoleAssignmentModuleFieldOwnerRoleSubstate? OwnerRole { get; set; } + + public List Entries { get; } = new(); +} + +internal class EntityRoleAssignmentProcessor +{ + private readonly ProcessorContext _context; + + private Dictionary _changePointers = new(); + private List _changeOrder = new(); + + private Dictionary _mostRecentAggregates = new(); + private Dictionary _mostRecentEntries = new(); + + private List _aggregatesToAdd = new(); + private List _entriesToAdd = new(); + private List _ownersToAdd = new(); + + public EntityRoleAssignmentProcessor(ProcessorContext context) + { + _context = context; + } + + public void VisitUpsert(CoreModel.Substate substateData, ReferencedEntity referencedEntity, long stateVersion) + { + if (substateData is CoreModel.RoleAssignmentModuleFieldOwnerRoleSubstate accessRulesFieldOwnerRole) + { + _changePointers + .GetOrAdd(new RoleAssignmentsChangePointerLookup(referencedEntity.DatabaseId, stateVersion), lookup => + { + _changeOrder.Add(lookup); + + return new RoleAssignmentsChangePointer(referencedEntity); + }) + .OwnerRole = accessRulesFieldOwnerRole; + } + + if (substateData is CoreModel.RoleAssignmentModuleRuleEntrySubstate roleAssignmentEntry) + { + _changePointers + .GetOrAdd(new RoleAssignmentsChangePointerLookup(referencedEntity.DatabaseId, stateVersion), lookup => + { + _changeOrder.Add(lookup); + + return new RoleAssignmentsChangePointer(referencedEntity); + }) + .Entries.Add(roleAssignmentEntry); + } + } + + public void ProcessChanges() + { + foreach (var lookup in _changeOrder) + { + var change = _changePointers[lookup]; + + EntityRoleAssignmentsOwnerRoleHistory? ownerRole = null; + + if (change.OwnerRole != null) + { + ownerRole = new EntityRoleAssignmentsOwnerRoleHistory + { + Id = _context.Sequences.EntityRoleAssignmentsOwnerRoleHistorySequence++, + FromStateVersion = lookup.StateVersion, + EntityId = lookup.EntityId, + RoleAssignments = change.OwnerRole.Value.OwnerRole.ToJson(), + }; + + _ownersToAdd.Add(ownerRole); + } + + EntityRoleAssignmentsAggregateHistory aggregate; + + if (!_mostRecentAggregates.TryGetValue(lookup.EntityId, out var previousAggregate) || previousAggregate.FromStateVersion != lookup.StateVersion) + { + aggregate = new EntityRoleAssignmentsAggregateHistory + { + Id = _context.Sequences.EntityRoleAssignmentsAggregateHistorySequence++, + FromStateVersion = lookup.StateVersion, + EntityId = lookup.EntityId, + OwnerRoleId = ownerRole?.Id ?? previousAggregate?.OwnerRoleId ?? throw new InvalidOperationException("Unable to determine OwnerRoleId"), + EntryIds = new List(), + }; + + if (previousAggregate != null) + { + aggregate.EntryIds.AddRange(previousAggregate.EntryIds); + } + + _aggregatesToAdd.Add(aggregate); + _mostRecentAggregates[lookup.EntityId] = aggregate; + } + else + { + aggregate = previousAggregate; + } + + foreach (var entry in change.Entries) + { + var entryLookup = new RoleAssignmentEntryDbLookup(lookup.EntityId, entry.Key.RoleKey, entry.Key.ObjectModuleId.ToModel()); + var entryHistory = new EntityRoleAssignmentsEntryHistory + { + Id = _context.Sequences.EntityRoleAssignmentsEntryHistorySequence++, + FromStateVersion = lookup.StateVersion, + EntityId = lookup.EntityId, + KeyRole = entry.Key.RoleKey, + KeyModule = entry.Key.ObjectModuleId.ToModel(), + RoleAssignments = entry.Value?.AccessRule.ToJson(), + IsDeleted = entry.Value == null, + }; + + _entriesToAdd.Add(entryHistory); + + if (_mostRecentEntries.TryGetValue(entryLookup, out var previousEntry)) + { + var currentPosition = aggregate.EntryIds.IndexOf(previousEntry.Id); + + if (currentPosition != -1) + { + aggregate.EntryIds.RemoveAt(currentPosition); + } + } + + // TODO introduce entry.IsDeleted extension method + if (entry.Value != null) + { + aggregate.EntryIds.Insert(0, entryHistory.Id); + } + + _mostRecentEntries[entryLookup] = entryHistory; + } + } + } + + public async Task LoadMostRecent() + { + _mostRecentEntries = await MostRecentEntityRoleAssignmentsEntryHistory(); + _mostRecentAggregates = await MostRecentEntityRoleAssignmentsAggregateHistory(); + } + + public async Task SaveEntities() + { + var rowsInserted = 0; + + rowsInserted += await CopyEntityRoleAssignmentsOwnerRoleHistory(); + rowsInserted += await CopyEntityRoleAssignmentsRulesEntryHistory(); + rowsInserted += await CopyEntityRoleAssignmentsAggregateHistory(); + + return rowsInserted; + } + + private Task> MostRecentEntityRoleAssignmentsEntryHistory() + { + var lookupSet = new HashSet(); + + foreach (var change in _changePointers.Values) + { + foreach (var entry in change.Entries) + { + lookupSet.Add(new RoleAssignmentEntryDbLookup(change.ReferencedEntity.DatabaseId, entry.Key.RoleKey, entry.Key.ObjectModuleId.ToModel())); + } + } + + if (!lookupSet.Unzip(x => x.EntityId, x => x.KeyRole, x => x.KeyModule, out var entityIds, out var keyRoles, out var keyModuleIds)) + { + return Task.FromResult(new Dictionary()); + } + + return _context.ReadHelper.MostRecent( + @$" +WITH variables (entity_id, key_role, module_id) AS ( + SELECT UNNEST({entityIds}), UNNEST({keyRoles}), UNNEST({keyModuleIds}) +) +SELECT eareh.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM entity_role_assignments_entry_history + WHERE entity_id = variables.entity_id AND key_role = variables.key_role AND key_module = variables.module_id + ORDER BY from_state_version DESC + LIMIT 1 +) eareh ON true;", + e => new RoleAssignmentEntryDbLookup(e.EntityId, e.KeyRole, e.KeyModule)); + } + + private Task> MostRecentEntityRoleAssignmentsAggregateHistory() + { + var entityIds = _changeOrder.Select(x => x.EntityId).ToHashSet().ToList(); + + if (!entityIds.Any()) + { + return Task.FromResult(new Dictionary()); + } + + return _context.ReadHelper.MostRecent( + @$" +WITH variables (entity_id) AS ( + SELECT UNNEST({entityIds}) +) +SELECT earah.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM entity_role_assignments_aggregate_history + WHERE entity_id = variables.entity_id + ORDER BY from_state_version DESC + LIMIT 1 +) earah ON true;", + e => e.EntityId); + } + + private Task CopyEntityRoleAssignmentsOwnerRoleHistory() => _context.WriteHelper.Copy( + _ownersToAdd, + "COPY entity_role_assignments_owner_role_history (id, from_state_version, entity_id, role_assignments) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.RoleAssignments, NpgsqlDbType.Jsonb, token); + }); + + private Task CopyEntityRoleAssignmentsRulesEntryHistory() => _context.WriteHelper.Copy( + _entriesToAdd, + "COPY entity_role_assignments_entry_history (id, from_state_version, entity_id, key_role, key_module, role_assignments, is_deleted) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.KeyRole, NpgsqlDbType.Text, token); + await writer.WriteAsync(e.KeyModule, "module_id", token); + await writer.WriteAsync(e.RoleAssignments, NpgsqlDbType.Jsonb, token); + await writer.WriteAsync(e.IsDeleted, NpgsqlDbType.Boolean, token); + }); + + private Task CopyEntityRoleAssignmentsAggregateHistory() => _context.WriteHelper.Copy( + _aggregatesToAdd, + "COPY entity_role_assignments_aggregate_history (id, from_state_version, entity_id, owner_role_id, entry_ids) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.OwnerRoleId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.EntryIds.ToArray(), NpgsqlDbType.Array | NpgsqlDbType.Bigint, token); + }); +} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/EntityStateProcessor.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/EntityStateProcessor.cs new file mode 100644 index 000000000..b889f664e --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/EntityStateProcessor.cs @@ -0,0 +1,224 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using NpgsqlTypes; +using RadixDlt.NetworkGateway.Abstractions; +using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.PostgresIntegration.Models; +using System; +using System.Collections.Generic; +using System.Diagnostics; +using System.Threading.Tasks; +using CoreModel = RadixDlt.CoreApiSdk.Model; + +namespace RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; + +internal class EntityStateProcessor +{ + private readonly ProcessorContext _context; + private readonly ReferencedEntityDictionary _referencedEntities; + + private List _toAdd = new(); + + public EntityStateProcessor(ProcessorContext context, ReferencedEntityDictionary referencedEntities) + { + _context = context; + _referencedEntities = referencedEntities; + } + + public void VisitUpsert(CoreModel.IUpsertedSubstate substate, ReferencedEntity referencedEntity, long stateVersion) + { + var substateData = substate.Value.SubstateData; + + if (substateData is CoreModel.GenericScryptoComponentFieldStateSubstate componentState) + { + if (substate.SystemStructure is not CoreModel.ObjectFieldStructure objectFieldStructure) + { + throw new UnreachableException($"Generic Scrypto components are expected to have ObjectFieldStructure. Got: {substate.SystemStructure.GetType()}"); + } + + var schemaDetails = objectFieldStructure.ValueSchema.GetSchemaDetails(); + + _toAdd.Add(new SborStateHistory + { + Id = _context.Sequences.StateHistorySequence++, + FromStateVersion = stateVersion, + EntityId = referencedEntity.DatabaseId, + SborState = componentState.Value.DataStruct.StructData.GetDataBytes(), + SchemaHash = schemaDetails.SchemaHash.ConvertFromHex(), + SborTypeKind = schemaDetails.SborTypeKind.ToModel(), + TypeIndex = schemaDetails.TypeIndex, + SchemaDefiningEntityId = _referencedEntities.Get((EntityAddress)schemaDetails.SchemaDefiningEntityAddress).DatabaseId, + }); + } + + if (substateData is CoreModel.ValidatorFieldStateSubstate validator) + { + _toAdd.Add(new JsonStateHistory + { + Id = _context.Sequences.StateHistorySequence++, + FromStateVersion = stateVersion, + EntityId = referencedEntity.DatabaseId, + JsonState = validator.Value.ToJson(), + }); + } + + if (substateData is CoreModel.AccountFieldStateSubstate accountFieldState) + { + _toAdd.Add(new JsonStateHistory + { + Id = _context.Sequences.StateHistorySequence++, + FromStateVersion = stateVersion, + EntityId = referencedEntity.DatabaseId, + JsonState = accountFieldState.Value.ToJson(), + }); + } + + if (substateData is CoreModel.AccessControllerFieldStateSubstate accessControllerFieldState) + { + _toAdd.Add(new JsonStateHistory + { + Id = _context.Sequences.StateHistorySequence++, + FromStateVersion = stateVersion, + EntityId = referencedEntity.DatabaseId, + JsonState = accessControllerFieldState.Value.ToJson(), + }); + } + + if (substateData is CoreModel.OneResourcePoolFieldStateSubstate oneResourcePoolFieldStateSubstate) + { + _toAdd.Add(new JsonStateHistory + { + Id = _context.Sequences.StateHistorySequence++, + FromStateVersion = stateVersion, + EntityId = referencedEntity.DatabaseId, + JsonState = oneResourcePoolFieldStateSubstate.Value.ToJson(), + }); + } + + if (substateData is CoreModel.TwoResourcePoolFieldStateSubstate twoResourcePoolFieldStateSubstate) + { + _toAdd.Add(new JsonStateHistory + { + Id = _context.Sequences.StateHistorySequence++, + FromStateVersion = stateVersion, + EntityId = referencedEntity.DatabaseId, + JsonState = twoResourcePoolFieldStateSubstate.Value.ToJson(), + }); + } + + if (substateData is CoreModel.MultiResourcePoolFieldStateSubstate multiResourcePoolFieldStateSubstate) + { + _toAdd.Add(new JsonStateHistory + { + Id = _context.Sequences.StateHistorySequence++, + FromStateVersion = stateVersion, + EntityId = referencedEntity.DatabaseId, + JsonState = multiResourcePoolFieldStateSubstate.Value.ToJson(), + }); + } + } + + public async Task SaveEntities() + { + var rowsInserted = 0; + + rowsInserted += await CopyStateHistory(); + + return rowsInserted; + } + + private Task CopyStateHistory() => _context.WriteHelper.Copy( + _toAdd, + "COPY state_history (id, from_state_version, entity_id, discriminator, json_state, sbor_state, type_index, schema_hash, sbor_type_kind, schema_defining_entity_id) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(_context.WriteHelper.GetDiscriminator(e.GetType()), "state_type", token); + + switch (e) + { + case JsonStateHistory jsonStateHistory: + await writer.WriteAsync(jsonStateHistory.JsonState, NpgsqlDbType.Jsonb, token); + await writer.WriteNullAsync(token); + await writer.WriteNullAsync(token); + await writer.WriteNullAsync(token); + await writer.WriteNullAsync(token); + await writer.WriteNullAsync(token); + break; + case SborStateHistory sborStateHistory: + await writer.WriteNullAsync(token); + await writer.WriteAsync(sborStateHistory.SborState, NpgsqlDbType.Bytea, token); + await writer.WriteAsync(sborStateHistory.TypeIndex, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(sborStateHistory.SchemaHash, NpgsqlDbType.Bytea, token); + await writer.WriteAsync(sborStateHistory.SborTypeKind, "sbor_type_kind", token); + await writer.WriteAsync(sborStateHistory.SchemaDefiningEntityId, NpgsqlDbType.Bigint, token); + break; + default: + throw new ArgumentOutOfRangeException(nameof(e), e, null); + } + }); +} diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeInitializer.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/Extensions.cs similarity index 67% rename from src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeInitializer.cs rename to src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/Extensions.cs index 27e6d8da2..32228876e 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeInitializer.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/Extensions.cs @@ -62,53 +62,86 @@ * permissions under this License. */ -using RadixDlt.NetworkGateway.Abstractions.Extensions; using System; using System.Collections.Generic; -using System.Threading; -using System.Threading.Tasks; +using System.Diagnostics.CodeAnalysis; +using System.Linq; -namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices; +namespace RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; -/// -/// A marker interface for NodeInitializers - Dependency Injection will pick each of them up to start them in the NodeWorkersRunner. -/// -public interface INodeInitializer +internal static class Extensions { - public Task Run(CancellationToken cancellationToken); -} + public static TVal GetOrAdd(this IDictionary dictionary, TKey key, Func factory) + where TKey : notnull + { + if (dictionary.TryGetValue(key, out var existingValue)) + { + return existingValue; + } -/// -/// A base class for NodeInitializers, which handles errors etc. -/// -public abstract class NodeInitializer : INodeInitializer -{ - private readonly string _nodeName; - private readonly IEnumerable _observers; + var value = factory(key); - protected NodeInitializer(string nodeName, IEnumerable observers) - { - _nodeName = nodeName; - _observers = observers; + dictionary[key] = value; + + return value; } - public async Task Run(CancellationToken cancellationToken) + public static bool Unzip( + this HashSet input, + Func out1Selector, + Func out2Selector, + [NotNullWhen(true)] out List? out1, + [NotNullWhen(true)] out List? out2) { - try + out1 = default; + out2 = default; + + if (!input.Any()) { - await Initialize(cancellationToken); + return false; } - catch (Exception ex) + + out1 = new List(input.Count); + out2 = new List(input.Count); + + foreach (var e in input) { - TrackInitializerFaultedException(cancellationToken.IsCancellationRequested, ex); - throw; + out1.Add(out1Selector(e)); + out2.Add(out2Selector(e)); } - } - protected abstract Task Initialize(CancellationToken cancellationToken); + return true; + } - protected void TrackInitializerFaultedException(bool isStopRequested, Exception ex) + public static bool Unzip( + this HashSet input, + Func out1Selector, + Func out2Selector, + Func out3Selector, + [NotNullWhen(true)] out List? out1, + [NotNullWhen(true)] out List? out2, + [NotNullWhen(true)] out List? out3) { - _observers.ForEach(x => x.TrackInitializerFaultedException(GetType(), _nodeName, isStopRequested, ex)); + out1 = default; + out2 = default; + out3 = default; + + if (!input.Any()) + { + return false; + } + + out1 = new List(input.Count); + out2 = new List(input.Count); + out3 = new List(input.Count); + + foreach (var e in input) + { + out1.Add(out1Selector(e)); + out2.Add(out2Selector(e)); + out3.Add(out3Selector(e)); + } + + return true; } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageCodeAggregator.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/KeyValueStoreAggregator.cs similarity index 54% rename from src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageCodeAggregator.cs rename to src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/KeyValueStoreAggregator.cs index ae75f1080..ee9e11d74 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageCodeAggregator.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/KeyValueStoreAggregator.cs @@ -67,116 +67,95 @@ using RadixDlt.NetworkGateway.PostgresIntegration.Models; using System.Collections.Generic; using System.Diagnostics; +using System.Linq; using CoreModel = RadixDlt.CoreApiSdk.Model; namespace RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; -internal record struct PackageCodeLookup(long PackageEntityId, ValueBytes CodeHash); +internal record struct KeyValueStoreEntryLookup(long KeyValueStoreEntityId, ValueBytes Key); -internal record PackageCodeChange(long StateVersion) -{ - public CoreModel.PackageCodeOriginalCodeEntrySubstate? PackageCodeOriginalCode { get; set; } - - public CoreModel.PackageCodeVmTypeEntrySubstate? PackageCodeVmType { get; set; } - - public bool CodeVmTypeIsDeleted { get; set; } - - public bool PackageCodeIsDeleted { get; set; } -} +internal record KeyValueStoreChange(long StateVersion, CoreModel.GenericKeyValueStoreEntrySubstate KeyValueStoreEntry); -internal static class PackageCodeAggregator +internal static class KeyValueStoreAggregator { - public static (List PackageCodeHistoryToAdd, List PackageCodeAggregateHistoryToAdd) AggregatePackageCode( - Dictionary packageCodeChanges, - Dictionary mostRecentPackageCodeHistory, - Dictionary mostRecentPackageCodeAggregateHistory, + public static (List KeyValueStoreEntryHistoryToAdd, List KeyValueStoreAggregateHistoryToAdd) AggregateKeyValueStore( + Dictionary keyValueStoreChanges, + Dictionary mostRecentKeyValueStoreEntry, + Dictionary mostRecentKeyValueStoreAggregateHistory, SequencesHolder sequences) { - var packageCodeHistoryToAdd = new List(); - var packageCodeAggregateHistoryToAdd = new List(); + var keyValueStoreEntryHistoryToAdd = new List(); + var keyValueStoreAggregateHistoryToAdd = new List(); - foreach (var change in packageCodeChanges) + foreach (var change in keyValueStoreChanges) { - var packageEntityId = change.Key.PackageEntityId; + var keyKeyValueStoreEntityId = change.Key.KeyValueStoreEntityId; var stateVersion = change.Value.StateVersion; - mostRecentPackageCodeAggregateHistory.TryGetValue(packageEntityId, out var existingPackageCodeAggregate); + mostRecentKeyValueStoreAggregateHistory.TryGetValue(keyKeyValueStoreEntityId, out var existingKeyValueStoreAggregate); - PackageCodeAggregateHistory packageCodeAggregate; + KeyValueStoreAggregateHistory keyValueStoreAggregate; - if (existingPackageCodeAggregate == null || existingPackageCodeAggregate.FromStateVersion != change.Value.StateVersion) + if (existingKeyValueStoreAggregate == null || existingKeyValueStoreAggregate.FromStateVersion != change.Value.StateVersion) { - packageCodeAggregate = new PackageCodeAggregateHistory + keyValueStoreAggregate = new KeyValueStoreAggregateHistory { - Id = sequences.PackageCodeAggregateHistorySequence++, + Id = sequences.KeyValueStoreAggregateHistorySequence++, FromStateVersion = stateVersion, - PackageEntityId = packageEntityId, - PackageCodeIds = existingPackageCodeAggregate?.PackageCodeIds ?? new List(), + KeyValueStoreEntityId = keyKeyValueStoreEntityId, + KeyValueStoreEntryIds = existingKeyValueStoreAggregate?.KeyValueStoreEntryIds.ToList() ?? new List(), }; - mostRecentPackageCodeAggregateHistory[packageEntityId] = packageCodeAggregate; - packageCodeAggregateHistoryToAdd.Add(packageCodeAggregate); + mostRecentKeyValueStoreAggregateHistory[keyKeyValueStoreEntityId] = keyValueStoreAggregate; + keyValueStoreAggregateHistoryToAdd.Add(keyValueStoreAggregate); } else { - packageCodeAggregate = existingPackageCodeAggregate; + keyValueStoreAggregate = existingKeyValueStoreAggregate; } - mostRecentPackageCodeHistory.TryGetValue(change.Key, out var existingPackageCode); + mostRecentKeyValueStoreEntry.TryGetValue(change.Key, out var existingKeyValueStoreEntry); - PackageCodeHistory packageCodeHistory; + KeyValueStoreEntryHistory keyValueStoreEntryHistory; - if (existingPackageCode != null) + if (existingKeyValueStoreEntry != null) { - var previousPackageCodeId = existingPackageCode.Id; + var previousKeyValueStoreEntryId = existingKeyValueStoreEntry.Id; - packageCodeHistory = existingPackageCode; - packageCodeHistory.Id = sequences.PackageCodeHistorySequence++; - packageCodeHistory.FromStateVersion = change.Value.StateVersion; + keyValueStoreEntryHistory = existingKeyValueStoreEntry; + keyValueStoreEntryHistory.Id = sequences.KeyValueStoreEntryHistorySequence++; + keyValueStoreEntryHistory.FromStateVersion = change.Value.StateVersion; - packageCodeAggregate.PackageCodeIds.Remove(previousPackageCodeId); + keyValueStoreAggregate.KeyValueStoreEntryIds.Remove(previousKeyValueStoreEntryId); } else { - packageCodeHistory = new PackageCodeHistory + keyValueStoreEntryHistory = new KeyValueStoreEntryHistory { - Id = sequences.PackageCodeHistorySequence++, - PackageEntityId = packageEntityId, + Id = sequences.KeyValueStoreEntryHistorySequence++, + KeyValueStoreEntityId = keyKeyValueStoreEntityId, FromStateVersion = stateVersion, - CodeHash = change.Key.CodeHash, + Key = change.Value.KeyValueStoreEntry.Key.KeyData.GetDataBytes(), }; - mostRecentPackageCodeHistory[change.Key] = packageCodeHistory; + mostRecentKeyValueStoreEntry[change.Key] = keyValueStoreEntryHistory; } - var isDeleted = change.Value.PackageCodeIsDeleted && change.Value.CodeVmTypeIsDeleted; - if (isDeleted) + if (change.Value.KeyValueStoreEntry.Value == null) { - packageCodeHistory.IsDeleted = true; - } - else if (change.Value.PackageCodeIsDeleted != change.Value.CodeVmTypeIsDeleted) - { - throw new UnreachableException( - $"Unexpected situation where PackageCode was deleted but VmType wasn't. PackageId: {change.Key.PackageEntityId}, CodeHashHex: {change.Key.CodeHash.ToHex()}, StateVersion: {change.Value.StateVersion}"); + keyValueStoreEntryHistory.IsDeleted = true; } else { - packageCodeAggregate.PackageCodeIds.Add(packageCodeHistory.Id); + keyValueStoreAggregate.KeyValueStoreEntryIds.Insert(0, keyValueStoreEntryHistory.Id); - if (change.Value.PackageCodeVmType != null) - { - packageCodeHistory.VmType = change.Value.PackageCodeVmType.Value.VmType.ToModel(); - } - - if (change.Value.PackageCodeOriginalCode != null) - { - packageCodeHistory.Code = change.Value.PackageCodeOriginalCode.Value.CodeHex.ConvertFromHex(); - } + keyValueStoreEntryHistory.Value = change.Value.KeyValueStoreEntry.Value.Data.StructData.GetDataBytes(); + keyValueStoreEntryHistory.IsLocked = change.Value.KeyValueStoreEntry.IsLocked; } - packageCodeHistoryToAdd.Add(packageCodeHistory); + keyValueStoreEntryHistoryToAdd.Add(keyValueStoreEntryHistory); } - return (packageCodeHistoryToAdd, packageCodeAggregateHistoryToAdd); + return (keyValueStoreEntryHistoryToAdd, keyValueStoreAggregateHistoryToAdd); } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ManifestAddressesExtractor.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ManifestAddressesExtractor.cs index aea1517ee..7857f87a6 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ManifestAddressesExtractor.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ManifestAddressesExtractor.cs @@ -96,31 +96,33 @@ public List All() => .ToList(); } - public static ManifestAddresses ExtractAddresses(ToolkitModel.TransactionManifest manifest) + public static ManifestAddresses ExtractAddresses(ToolkitModel.TransactionManifest manifest, byte networkId) { var allAddresses = manifest.ExtractAddresses(); - var accountsRequiringAuth = manifest.AccountsRequiringAuth().Select(x => (EntityAddress)x.AddressString()).ToList(); - var accountsWithdrawnFrom = manifest.AccountsWithdrawnFrom().Select(x => (EntityAddress)x.AddressString()).ToList(); - var accountsDepositedInto = manifest.AccountsDepositedInto().Select(x => (EntityAddress)x.AddressString()).ToList(); - var identitiesRequiringAuth = manifest.IdentitiesRequiringAuth().Select(x => (EntityAddress)x.AddressString()).ToList(); + var manifestSummary = manifest.Summary(networkId); - var packageAddresses = allAddresses.Where(x => x.Key == ToolkitModel.EntityType.GLOBAL_PACKAGE).SelectMany(x => x.Value.Select(y => (EntityAddress)y.AddressString())).ToList(); + var accountsRequiringAuth = manifestSummary.accountsRequiringAuth.Select(x => (EntityAddress)x.AddressString()).ToList(); + var accountsWithdrawnFrom = manifestSummary.accountsWithdrawnFrom.Select(x => (EntityAddress)x.AddressString()).ToList(); + var accountsDepositedInto = manifestSummary.accountsDepositedInto.Select(x => (EntityAddress)x.AddressString()).ToList(); + var identitiesRequiringAuth = manifestSummary.identitiesRequiringAuth.Select(x => (EntityAddress)x.AddressString()).ToList(); + + var packageAddresses = allAddresses.Where(x => x.Key == ToolkitModel.EntityType.GlobalPackage).SelectMany(x => x.Value.Select(y => (EntityAddress)y.AddressString())).ToList(); var componentAddresses = allAddresses - .Where(x => x.Key is ToolkitModel.EntityType.GLOBAL_GENERIC_COMPONENT or ToolkitModel.EntityType.INTERNAL_GENERIC_COMPONENT) + .Where(x => x.Key is ToolkitModel.EntityType.GlobalGenericComponent or ToolkitModel.EntityType.InternalGenericComponent) .SelectMany(x => x.Value.Select(y => (EntityAddress)y.AddressString())) .ToList(); var resourceAddresses = allAddresses - .Where(x => x.Key is ToolkitModel.EntityType.GLOBAL_FUNGIBLE_RESOURCE_MANAGER or ToolkitModel.EntityType.GLOBAL_NON_FUNGIBLE_RESOURCE_MANAGER) + .Where(x => x.Key is ToolkitModel.EntityType.GlobalFungibleResourceManager or ToolkitModel.EntityType.GlobalNonFungibleResourceManager) .SelectMany(x => x.Value.Select(y => (EntityAddress)y.AddressString())) .ToList(); var accountAddresses = allAddresses - .Where(x => x.Key is ToolkitModel.EntityType.GLOBAL_ACCOUNT or ToolkitModel.EntityType.GLOBAL_VIRTUAL_ED25519_ACCOUNT - or ToolkitModel.EntityType.GLOBAL_VIRTUAL_SECP256K1_ACCOUNT) + .Where(x => x.Key is ToolkitModel.EntityType.GlobalAccount or ToolkitModel.EntityType.GlobalVirtualEd25519Account + or ToolkitModel.EntityType.GlobalVirtualSecp256k1Account) .SelectMany(x => x.Value.Select(y => (EntityAddress)y.AddressString())) .ToList(); var identityAddresses = allAddresses - .Where(x => x.Key is ToolkitModel.EntityType.GLOBAL_IDENTITY or ToolkitModel.EntityType.GLOBAL_VIRTUAL_ED25519_IDENTITY or ToolkitModel.EntityType.GLOBAL_VIRTUAL_SECP256K1_IDENTITY) + .Where(x => x.Key is ToolkitModel.EntityType.GlobalIdentity or ToolkitModel.EntityType.GlobalVirtualEd25519Identity or ToolkitModel.EntityType.GlobalVirtualSecp256k1Identity) .SelectMany(x => x.Value.Select(y => (EntityAddress)y.AddressString())) .ToList(); diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageBlueprintAggregator.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageBlueprintAggregator.cs deleted file mode 100644 index 96b6dbc9e..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageBlueprintAggregator.cs +++ /dev/null @@ -1,182 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using RadixDlt.NetworkGateway.Abstractions; -using RadixDlt.NetworkGateway.PostgresIntegration.Models; -using System.Collections.Generic; -using System.Linq; -using CoreModel = RadixDlt.CoreApiSdk.Model; - -namespace RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; - -internal record struct PackageBlueprintLookup(long PackageEntityId, string Name, string Version); - -internal record PackageBlueprintChange(long StateVersion) -{ - public CoreModel.PackageBlueprintDefinitionEntrySubstate? PackageBlueprintDefinition { get; set; } - - public CoreModel.PackageBlueprintDependenciesEntrySubstate? PackageBlueprintDependencies { get; set; } - - public CoreModel.PackageBlueprintRoyaltyEntrySubstate? PackageBlueprintRoyalty { get; set; } - - public CoreModel.PackageBlueprintAuthTemplateEntrySubstate? PackageBlueprintAuthTemplate { get; set; } -} - -internal static class PackageBlueprintAggregator -{ - public static (List PackageBlueprintHistoryToAdd, List PackageBlueprintAggregateHistoryToAdd) AggregatePackageBlueprint( - Dictionary packageBlueprintChanges, - Dictionary mostRecentPackageBlueprintHistory, - Dictionary mostRecentPackageBlueprintAggregateHistory, - ReferencedEntityDictionary referencedEntities, - SequencesHolder sequences) - { - var packageBlueprintHistoryToAdd = new List(); - var packageBlueprintAggregateHistoryToAdd = new List(); - - foreach (var change in packageBlueprintChanges) - { - var packageEntityId = change.Key.PackageEntityId; - var stateVersion = change.Value.StateVersion; - mostRecentPackageBlueprintAggregateHistory.TryGetValue(packageEntityId, out var existingPackageBlueprintAggregate); - - PackageBlueprintAggregateHistory packageBlueprintAggregate; - - if (existingPackageBlueprintAggregate == null || existingPackageBlueprintAggregate.FromStateVersion != change.Value.StateVersion) - { - packageBlueprintAggregate = new PackageBlueprintAggregateHistory - { - Id = sequences.PackageBlueprintAggregateHistorySequence++, - FromStateVersion = stateVersion, - PackageEntityId = packageEntityId, - PackageBlueprintIds = existingPackageBlueprintAggregate?.PackageBlueprintIds ?? new List(), - }; - - mostRecentPackageBlueprintAggregateHistory[packageEntityId] = packageBlueprintAggregate; - packageBlueprintAggregateHistoryToAdd.Add(packageBlueprintAggregate); - } - else - { - packageBlueprintAggregate = existingPackageBlueprintAggregate; - } - - mostRecentPackageBlueprintHistory.TryGetValue(change.Key, out var existingPackageBlueprint); - - PackageBlueprintHistory packageBlueprintHistory; - - if (existingPackageBlueprint != null) - { - var previousPackageBlueprintHistoryId = existingPackageBlueprint.Id; - - packageBlueprintHistory = existingPackageBlueprint; - packageBlueprintHistory.Id = sequences.PackageBlueprintHistorySequence++; - packageBlueprintHistory.FromStateVersion = change.Value.StateVersion; - - packageBlueprintAggregate.PackageBlueprintIds.Remove(previousPackageBlueprintHistoryId); - packageBlueprintAggregate.PackageBlueprintIds.Add(packageBlueprintHistory.Id); - } - else - { - packageBlueprintHistory = new PackageBlueprintHistory - { - Id = sequences.PackageBlueprintHistorySequence++, - PackageEntityId = packageEntityId, - FromStateVersion = stateVersion, - Name = change.Key.Name, - Version = change.Key.Version, - }; - mostRecentPackageBlueprintHistory[change.Key] = packageBlueprintHistory; - - packageBlueprintAggregate.PackageBlueprintIds.Add(packageBlueprintHistory.Id); - } - - if (change.Value.PackageBlueprintDefinition != null) - { - packageBlueprintHistory.Definition = change.Value.PackageBlueprintDefinition.Value.Definition.ToJson(); - } - - if (change.Value.PackageBlueprintDependencies != null) - { - packageBlueprintHistory.DependantEntityIds = - change.Value.PackageBlueprintDependencies.Value.Dependencies.Dependencies.Select(address => referencedEntities.Get((EntityAddress)address).DatabaseId).ToList(); - } - - if (change.Value.PackageBlueprintRoyalty != null) - { - packageBlueprintHistory.RoyaltyConfig = change.Value.PackageBlueprintRoyalty.Value.RoyaltyConfig.ToJson(); - packageBlueprintHistory.RoyaltyConfigIsLocked = change.Value.PackageBlueprintRoyalty.IsLocked; - } - - if (change.Value.PackageBlueprintAuthTemplate != null) - { - packageBlueprintHistory.AuthTemplate = change.Value.PackageBlueprintAuthTemplate.Value.AuthConfig.ToJson(); - packageBlueprintHistory.AuthTemplateIsLocked = change.Value.PackageBlueprintAuthTemplate.IsLocked; - } - - packageBlueprintHistoryToAdd.Add(packageBlueprintHistory); - } - - return (packageBlueprintHistoryToAdd, packageBlueprintAggregateHistoryToAdd); - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageBlueprintProcessor.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageBlueprintProcessor.cs new file mode 100644 index 000000000..35a38d50b --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageBlueprintProcessor.cs @@ -0,0 +1,344 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using NpgsqlTypes; +using RadixDlt.NetworkGateway.Abstractions; +using RadixDlt.NetworkGateway.PostgresIntegration.Models; +using RadixDlt.NetworkGateway.PostgresIntegration.Services; +using System.Collections.Generic; +using System.Linq; +using System.Threading.Tasks; +using CoreModel = RadixDlt.CoreApiSdk.Model; + +namespace RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; + +internal record struct PackageBlueprintDbLookup(long PackageEntityId, string Name, string Version); + +internal record PackageBlueprintChangePointer(long StateVersion) +{ + public CoreModel.PackageBlueprintDefinitionEntrySubstate? PackageBlueprintDefinition { get; set; } + + public CoreModel.PackageBlueprintDependenciesEntrySubstate? PackageBlueprintDependencies { get; set; } + + public CoreModel.PackageBlueprintRoyaltyEntrySubstate? PackageBlueprintRoyalty { get; set; } + + public CoreModel.PackageBlueprintAuthTemplateEntrySubstate? PackageBlueprintAuthTemplate { get; set; } +} + +internal class PackageBlueprintProcessor +{ + private readonly ProcessorContext _context; + private readonly ReferencedEntityDictionary _referencedEntities; + + private Dictionary _changePointers = new(); + private List _changeOrder = new(); + + private Dictionary _mostRecentAggregates = new(); + private Dictionary _mostRecentEntries = new(); + + private List _aggregatesToAdd = new(); + private List _entriesToAdd = new(); + + public PackageBlueprintProcessor(ProcessorContext context, ReferencedEntityDictionary referencedEntities) + { + _context = context; + _referencedEntities = referencedEntities; + } + + public void VisitUpsert(CoreModel.Substate substateData, ReferencedEntity referencedEntity, long stateVersion) + { + if (substateData is CoreModel.PackageBlueprintDefinitionEntrySubstate packageBlueprintDefinition) + { + _changePointers + .GetOrAdd(new PackageBlueprintDbLookup(referencedEntity.DatabaseId, packageBlueprintDefinition.Key.BlueprintName, packageBlueprintDefinition.Key.BlueprintVersion), lookup => + { + _changeOrder.Add(lookup); + + return new PackageBlueprintChangePointer(stateVersion); + }) + .PackageBlueprintDefinition = packageBlueprintDefinition; + } + + if (substateData is CoreModel.PackageBlueprintDependenciesEntrySubstate packageBlueprintDependencies) + { + _changePointers + .GetOrAdd(new PackageBlueprintDbLookup(referencedEntity.DatabaseId, packageBlueprintDependencies.Key.BlueprintName, packageBlueprintDependencies.Key.BlueprintVersion), lookup => + { + _changeOrder.Add(lookup); + + return new PackageBlueprintChangePointer(stateVersion); + }) + .PackageBlueprintDependencies = packageBlueprintDependencies; + } + + if (substateData is CoreModel.PackageBlueprintRoyaltyEntrySubstate packageBlueprintRoyalty) + { + _changePointers + .GetOrAdd(new PackageBlueprintDbLookup(referencedEntity.DatabaseId, packageBlueprintRoyalty.Key.BlueprintName, packageBlueprintRoyalty.Key.BlueprintVersion), lookup => + { + _changeOrder.Add(lookup); + + return new PackageBlueprintChangePointer(stateVersion); + }) + .PackageBlueprintRoyalty = packageBlueprintRoyalty; + } + + if (substateData is CoreModel.PackageBlueprintAuthTemplateEntrySubstate packageBlueprintAuthTemplate) + { + _changePointers + .GetOrAdd(new PackageBlueprintDbLookup(referencedEntity.DatabaseId, packageBlueprintAuthTemplate.Key.BlueprintName, packageBlueprintAuthTemplate.Key.BlueprintVersion), lookup => + { + _changeOrder.Add(lookup); + + return new PackageBlueprintChangePointer(stateVersion); + }) + .PackageBlueprintAuthTemplate = packageBlueprintAuthTemplate; + } + } + + public void ProcessChanges() + { + foreach (var lookup in _changeOrder) + { + var change = _changePointers[lookup]; + + PackageBlueprintAggregateHistory aggregate; + + if (!_mostRecentAggregates.TryGetValue(lookup.PackageEntityId, out var previousAggregate) || previousAggregate.FromStateVersion != change.StateVersion) + { + aggregate = new PackageBlueprintAggregateHistory + { + Id = _context.Sequences.PackageBlueprintAggregateHistorySequence++, + FromStateVersion = change.StateVersion, + PackageEntityId = lookup.PackageEntityId, + PackageBlueprintIds = new List(), + }; + + if (previousAggregate != null) + { + aggregate.PackageBlueprintIds.AddRange(previousAggregate.PackageBlueprintIds); + } + + _mostRecentAggregates[lookup.PackageEntityId] = aggregate; + _aggregatesToAdd.Add(aggregate); + } + else + { + aggregate = previousAggregate; + } + + // TODO change all the code below and follow the existing pattern + PackageBlueprintHistory packageBlueprintHistory; + + _mostRecentEntries.TryGetValue(lookup, out var existingPackageBlueprint); + + if (existingPackageBlueprint != null) + { + var previousPackageBlueprintHistoryId = existingPackageBlueprint.Id; + + packageBlueprintHistory = existingPackageBlueprint; + packageBlueprintHistory.Id = _context.Sequences.PackageBlueprintHistorySequence++; + packageBlueprintHistory.FromStateVersion = change.StateVersion; + + aggregate.PackageBlueprintIds.Remove(previousPackageBlueprintHistoryId); + aggregate.PackageBlueprintIds.Add(packageBlueprintHistory.Id); + } + else + { + packageBlueprintHistory = new PackageBlueprintHistory + { + Id = _context.Sequences.PackageBlueprintHistorySequence++, + PackageEntityId = lookup.PackageEntityId, + FromStateVersion = change.StateVersion, + Name = lookup.Name, + Version = lookup.Version, + }; + + _mostRecentEntries[lookup] = packageBlueprintHistory; + aggregate.PackageBlueprintIds.Add(packageBlueprintHistory.Id); + } + + if (change.PackageBlueprintDefinition != null) + { + packageBlueprintHistory.Definition = change.PackageBlueprintDefinition.Value.Definition.ToJson(); + } + + if (change.PackageBlueprintDependencies != null) + { + packageBlueprintHistory.DependantEntityIds = change.PackageBlueprintDependencies.Value.Dependencies.Dependencies.Select(address => _referencedEntities.Get((EntityAddress)address).DatabaseId).ToList(); + } + + if (change.PackageBlueprintRoyalty != null) + { + packageBlueprintHistory.RoyaltyConfig = change.PackageBlueprintRoyalty.Value.RoyaltyConfig.ToJson(); + packageBlueprintHistory.RoyaltyConfigIsLocked = change.PackageBlueprintRoyalty.IsLocked; + } + + if (change.PackageBlueprintAuthTemplate != null) + { + packageBlueprintHistory.AuthTemplate = change.PackageBlueprintAuthTemplate.Value.AuthConfig.ToJson(); + packageBlueprintHistory.AuthTemplateIsLocked = change.PackageBlueprintAuthTemplate.IsLocked; + } + + _entriesToAdd.Add(packageBlueprintHistory); + } + } + + public async Task LoadMostRecent() + { + _mostRecentEntries = await MostRecentPackageCodeHistory(); + _mostRecentAggregates = await MostRecentPackageBlueprintAggregateHistory(); + } + + public async Task SaveEntities() + { + var rowsInserted = 0; + + rowsInserted += await CopyPackageBlueprintHistory(); + rowsInserted += await CopyPackageBlueprintAggregateHistory(); + + return rowsInserted; + } + + private Task> MostRecentPackageCodeHistory() + { + var lookupSet = _changeOrder.ToHashSet(); + + if (!lookupSet.Unzip(x => x.PackageEntityId, x => x.Name, x => x.Version, out var packageEntityIds, out var names, out var versions)) + { + return Task.FromResult(new Dictionary()); + } + + return _context.ReadHelper.MostRecent( + @$" +WITH variables (package_entity_id, name, version) AS ( + SELECT UNNEST({packageEntityIds}), UNNEST({names}), UNNEST({versions}) +) +SELECT pbh.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM package_blueprint_history + WHERE package_entity_id = variables.package_entity_id AND name = variables.name AND version = variables.version + ORDER BY from_state_version DESC + LIMIT 1 +) pbh ON true;", + e => new PackageBlueprintDbLookup(e.PackageEntityId, e.Name, e.Version)); + } + + private Task> MostRecentPackageBlueprintAggregateHistory() + { + var packageEntityIds = _changePointers.Keys.Select(x => x.PackageEntityId).ToHashSet().ToList(); + + if (!packageEntityIds.Any()) + { + return Task.FromResult(new Dictionary()); + } + + return _context.ReadHelper.MostRecent( + $@" +WITH variables (package_entity_id) AS ( + SELECT UNNEST({packageEntityIds}) +) +SELECT pbah.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM package_blueprint_aggregate_history + WHERE package_entity_id = variables.package_entity_id + ORDER BY from_state_version DESC + LIMIT 1 +) pbah ON true;", + e => e.PackageEntityId); + } + + private Task CopyPackageBlueprintHistory() => _context.WriteHelper.Copy( + _entriesToAdd, + "COPY package_blueprint_history (id, from_state_version, package_entity_id, name, version, definition, dependant_entity_ids, auth_template, auth_template_is_locked, royalty_config, royalty_config_is_locked) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.PackageEntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.Name, NpgsqlDbType.Text, token); + await writer.WriteAsync(e.Version, NpgsqlDbType.Text, token); + await writer.WriteAsync(e.Definition, NpgsqlDbType.Jsonb, token); + await writer.WriteNullableAsync(e.DependantEntityIds?.ToArray(), NpgsqlDbType.Array | NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.AuthTemplate, NpgsqlDbType.Jsonb, token); + await writer.WriteNullableAsync(e.AuthTemplateIsLocked, NpgsqlDbType.Boolean, token); + await writer.WriteAsync(e.RoyaltyConfig, NpgsqlDbType.Jsonb, token); + await writer.WriteNullableAsync(e.RoyaltyConfigIsLocked, NpgsqlDbType.Boolean, token); + }); + + private Task CopyPackageBlueprintAggregateHistory() => _context.WriteHelper.Copy( + _aggregatesToAdd, + "COPY package_blueprint_aggregate_history (id, from_state_version, package_entity_id, package_blueprint_ids) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.PackageEntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.PackageBlueprintIds.ToArray(), NpgsqlDbType.Array | NpgsqlDbType.Bigint, token); + }); +} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageCodeProcessor.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageCodeProcessor.cs new file mode 100644 index 000000000..f7f6e3e90 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PackageCodeProcessor.cs @@ -0,0 +1,349 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using NpgsqlTypes; +using RadixDlt.NetworkGateway.Abstractions; +using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.PostgresIntegration.Models; +using System.Collections.Generic; +using System.Diagnostics; +using System.Linq; +using System.Threading.Tasks; +using CoreModel = RadixDlt.CoreApiSdk.Model; + +namespace RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; + +internal record struct PackageCodeDbLookup(long PackageEntityId, ValueBytes CodeHash); + +internal record PackageCodeChangePointer(long StateVersion) +{ + public CoreModel.PackageCodeOriginalCodeEntrySubstate? PackageCodeOriginalCode { get; set; } + + public CoreModel.PackageCodeVmTypeEntrySubstate? PackageCodeVmType { get; set; } + + public bool CodeVmTypeIsDeleted { get; set; } + + public bool PackageCodeIsDeleted { get; set; } +} + +internal class PackageCodeProcessor +{ + private readonly ProcessorContext _context; + private readonly byte _networkId; + + private Dictionary _changePointers = new(); + private List _changeOrder = new(); + + private Dictionary _mostRecentAggregates = new(); + private Dictionary _mostRecentEntries = new(); + + private List _aggregatesToAdd = new(); + private List _entriesToAdd = new(); + + public PackageCodeProcessor(ProcessorContext context, byte networkId) + { + _context = context; + _networkId = networkId; + } + + public void VisitUpsert(CoreModel.Substate substateData, ReferencedEntity referencedEntity, long stateVersion) + { + if (substateData is CoreModel.PackageCodeOriginalCodeEntrySubstate packageCodeOriginalCode) + { + _changePointers + .GetOrAdd(new PackageCodeDbLookup(referencedEntity.DatabaseId, (ValueBytes)packageCodeOriginalCode.Key.CodeHash.ConvertFromHex()), lookup => + { + _changeOrder.Add(lookup); + + return new PackageCodeChangePointer(stateVersion); + }) + .PackageCodeOriginalCode = packageCodeOriginalCode; + } + + if (substateData is CoreModel.PackageCodeVmTypeEntrySubstate packageCodeVmType) + { + _changePointers + .GetOrAdd(new PackageCodeDbLookup(referencedEntity.DatabaseId, (ValueBytes)packageCodeVmType.Key.CodeHash.ConvertFromHex()), lookup => + { + _changeOrder.Add(lookup); + + return new PackageCodeChangePointer(stateVersion); + }) + .PackageCodeVmType = packageCodeVmType; + } + } + + public void VisitDelete(CoreModel.SubstateId substateId, ReferencedEntity referencedEntity, long stateVersion) + { + if (substateId.SubstateType == CoreModel.SubstateType.PackageCodeVmTypeEntry) + { + var keyHex = ((CoreModel.MapSubstateKey)substateId.SubstateKey).KeyHex; + var code_hash = ScryptoSborUtils.DataToProgrammaticScryptoSborValueBytes(keyHex.ConvertFromHex(), _networkId); + + _changePointers + .GetOrAdd(new PackageCodeDbLookup(referencedEntity.DatabaseId, (ValueBytes)code_hash.Hex.ConvertFromHex()), lookup => + { + _changeOrder.Add(lookup); + + return new PackageCodeChangePointer(stateVersion); + }) + .CodeVmTypeIsDeleted = true; + } + + if (substateId.SubstateType == CoreModel.SubstateType.PackageCodeOriginalCodeEntry) + { + var keyHex = ((CoreModel.MapSubstateKey)substateId.SubstateKey).KeyHex; + var code_hash = ScryptoSborUtils.DataToProgrammaticScryptoSborValueBytes(keyHex.ConvertFromHex(), _networkId); + + _changePointers + .GetOrAdd(new PackageCodeDbLookup(referencedEntity.DatabaseId, (ValueBytes)code_hash.Hex.ConvertFromHex()), lookup => + { + _changeOrder.Add(lookup); + + return new PackageCodeChangePointer(stateVersion); + }) + .PackageCodeIsDeleted = true; + } + } + + public void ProcessChanges() + { + foreach (var lookup in _changeOrder) + { + var change = _changePointers[lookup]; + + PackageCodeAggregateHistory aggregate; + + if (!_mostRecentAggregates.TryGetValue(lookup.PackageEntityId, out var previousAggregate) || previousAggregate.FromStateVersion != change.StateVersion) + { + aggregate = new PackageCodeAggregateHistory + { + Id = _context.Sequences.PackageCodeAggregateHistorySequence++, + FromStateVersion = change.StateVersion, + PackageEntityId = lookup.PackageEntityId, + PackageCodeIds = new List(), + }; + + if (previousAggregate != null) + { + aggregate.PackageCodeIds.AddRange(previousAggregate.PackageCodeIds); + } + + _aggregatesToAdd.Add(aggregate); + _mostRecentAggregates[lookup.PackageEntityId] = aggregate; + } + else + { + aggregate = previousAggregate; + } + + // TODO change all the code below and follow the existing pattern + PackageCodeHistory packageCodeHistory; + + _mostRecentEntries.TryGetValue(lookup, out var existingPackageCode); + + if (existingPackageCode != null) + { + var previousPackageCodeId = existingPackageCode.Id; + + packageCodeHistory = existingPackageCode; + packageCodeHistory.Id = _context.Sequences.PackageCodeHistorySequence++; + packageCodeHistory.FromStateVersion = change.StateVersion; + + aggregate.PackageCodeIds.Remove(previousPackageCodeId); + } + else + { + packageCodeHistory = new PackageCodeHistory + { + Id = _context.Sequences.PackageCodeHistorySequence++, + PackageEntityId = lookup.PackageEntityId, + FromStateVersion = change.StateVersion, + CodeHash = lookup.CodeHash, + }; + + _mostRecentEntries[lookup] = packageCodeHistory; + } + + var isDeleted = change.PackageCodeIsDeleted && change.CodeVmTypeIsDeleted; + if (isDeleted) + { + packageCodeHistory.IsDeleted = true; + } + else if (change.PackageCodeIsDeleted != change.CodeVmTypeIsDeleted) + { + throw new UnreachableException($"Unexpected situation where PackageCode was deleted but VmType wasn't. PackageId: {lookup.PackageEntityId}, CodeHashHex: {lookup.CodeHash.ToHex()}, StateVersion: {change.StateVersion}"); + } + else + { + aggregate.PackageCodeIds.Add(packageCodeHistory.Id); + + if (change.PackageCodeVmType != null) + { + packageCodeHistory.VmType = change.PackageCodeVmType.Value.VmType.ToModel(); + } + + if (change.PackageCodeOriginalCode != null) + { + packageCodeHistory.Code = change.PackageCodeOriginalCode.Value.CodeHex.ConvertFromHex(); + } + } + + _entriesToAdd.Add(packageCodeHistory); + } + } + + public async Task LoadMostRecent() + { + _mostRecentEntries = await MostRecentPackageCodeHistory(); + _mostRecentAggregates = await MostRecentPackageCodeAggregateHistory(); + } + + public async Task SaveEntities() + { + var rowsInserted = 0; + + rowsInserted += await CopyPackageCodeHistory(); + rowsInserted += await CopyPackageCodeAggregateHistory(); + + return rowsInserted; + } + + private Task> MostRecentPackageCodeHistory() + { + var lookupSet = _changeOrder.ToHashSet(); + + if (!lookupSet.Unzip(x => x.PackageEntityId, x => (byte[])x.CodeHash, out var packageEntityIds, out var codeHashes)) + { + return Task.FromResult(new Dictionary()); + } + + return _context.ReadHelper.MostRecent( + @$" +WITH variables (package_entity_id, code_hash) AS ( + SELECT UNNEST({packageEntityIds}), UNNEST({codeHashes}) +) +SELECT pbh.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM package_code_history + WHERE package_entity_id = variables.package_entity_id AND code_hash = variables.code_hash + ORDER BY from_state_version DESC + LIMIT 1 +) pbh ON true;", + e => new PackageCodeDbLookup(e.PackageEntityId, e.CodeHash)); + } + + private Task> MostRecentPackageCodeAggregateHistory() + { + var packageEntityIds = _changeOrder.Select(x => x.PackageEntityId).ToHashSet().ToList(); + + if (!packageEntityIds.Any()) + { + return Task.FromResult(new Dictionary()); + } + + return _context.ReadHelper.MostRecent( + $@" +WITH variables (package_entity_id) AS ( + SELECT UNNEST({packageEntityIds}) +) +SELECT pbah.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM package_code_aggregate_history + WHERE package_entity_id = variables.package_entity_id + ORDER BY from_state_version DESC + LIMIT 1 +) pbah ON true;", + e => e.PackageEntityId); + } + + private Task CopyPackageCodeHistory() => _context.WriteHelper.Copy( + _entriesToAdd, + "COPY package_code_history (id, from_state_version, package_entity_id, code_hash, code, vm_type, is_deleted) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.PackageEntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.CodeHash, NpgsqlDbType.Bytea, token); + await writer.WriteAsync(e.Code, NpgsqlDbType.Bytea, token); + await writer.WriteAsync(e.VmType, "package_vm_type", token); + await writer.WriteAsync(e.IsDeleted, NpgsqlDbType.Boolean, token); + }); + + private Task CopyPackageCodeAggregateHistory() => _context.WriteHelper.Copy( + _aggregatesToAdd, + "COPY package_code_aggregate_history (id, from_state_version, package_entity_id, package_code_ids) FROM STDIN (FORMAT BINARY)", + async (writer, e, token) => + { + await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.PackageEntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.PackageCodeIds.ToArray(), NpgsqlDbType.Array | NpgsqlDbType.Bigint, token); + }); +} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PostgresLedgerExtenderService.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PostgresLedgerExtenderService.cs index b2040a6db..c14de858e 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PostgresLedgerExtenderService.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/PostgresLedgerExtenderService.cs @@ -68,6 +68,7 @@ using RadixDlt.NetworkGateway.Abstractions; using RadixDlt.NetworkGateway.Abstractions.Extensions; using RadixDlt.NetworkGateway.Abstractions.Model; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.Abstractions.Numerics; using RadixDlt.NetworkGateway.DataAggregator; using RadixDlt.NetworkGateway.DataAggregator.Services; @@ -125,11 +126,6 @@ public async Task CommitTransactions(ConsistentLedgerE TransactionConsistencyValidator.AssertLatestTransactionConsistent(ledgerExtension.LatestTransactionSummary.StateVersion, topOfLedgerSummary.StateVersion); - if (topOfLedgerSummary.StateVersion == 0) - { - await EnsureDbLedgerIsInitialized(token); - } - var extendLedgerReport = await ProcessTransactions(dbContext, ledgerExtension, token); await tx.CommitAsync(token); @@ -216,6 +212,7 @@ UPDATE pending_transactions private async Task ProcessTransactions(ReadWriteDbContext dbContext, ConsistentLedgerExtension ledgerExtension, CancellationToken token) { + var networkConfiguration = await _networkConfigurationProvider.GetNetworkConfiguration(); var rowsInserted = 0; var rowsUpdated = 0; var dbReadDuration = TimeSpan.Zero; @@ -224,9 +221,10 @@ private async Task ProcessTransactions(ReadWriteDbContext db var referencedEntities = new ReferencedEntityDictionary(); var childToParentEntities = new Dictionary(); var manifestExtractedAddresses = new Dictionary(); + var manifestClasses = new Dictionary>(); - var readHelper = new ReadHelper(dbContext, _observers); - var writeHelper = new WriteHelper(dbContext, _observers); + var readHelper = new ReadHelper(dbContext, _observers, token); + var writeHelper = new WriteHelper(dbContext, _observers, token); var lastTransactionSummary = ledgerExtension.LatestTransactionSummary; @@ -284,9 +282,10 @@ private async Task ProcessTransactions(ReadWriteDbContext db var coreInstructions = userLedgerTransaction.NotarizedTransaction.SignedIntent.Intent.Instructions; var coreBlobs = userLedgerTransaction.NotarizedTransaction.SignedIntent.Intent.BlobsHex; - using var manifestInstructions = ToolkitModel.Instructions.FromString(coreInstructions, _networkConfigurationProvider.GetNetworkId()); + using var manifestInstructions = ToolkitModel.Instructions.FromString(coreInstructions, networkConfiguration.Id); using var toolkitManifest = new ToolkitModel.TransactionManifest(manifestInstructions, coreBlobs.Values.Select(x => x.ConvertFromHex()).ToArray()); - var extractedAddresses = ManifestAddressesExtractor.ExtractAddresses(toolkitManifest); + + var extractedAddresses = ManifestAddressesExtractor.ExtractAddresses(toolkitManifest, networkConfiguration.Id); foreach (var address in extractedAddresses.All()) { @@ -294,6 +293,25 @@ private async Task ProcessTransactions(ReadWriteDbContext db } manifestExtractedAddresses[stateVersion] = extractedAddresses; + + var manifestSummary = toolkitManifest.Summary(networkConfiguration.Id); + + for (var i = 0; i < manifestSummary.classification.Length; ++i) + { + var manifestClass = manifestSummary.classification[i].ToModel(); + + manifestClasses + .GetOrAdd(stateVersion, _ => new List()) + .Add(manifestClass); + + ledgerTransactionMarkersToAdd.Add(new ManifestClassMarker + { + Id = sequences.LedgerTransactionMarkerSequence++, + StateVersion = stateVersion, + LedgerTransactionManifestClass = manifestClass, + IsMostSpecific = i == 0, + }); + } } if (committedTransaction.LedgerTransaction is CoreModel.RoundUpdateLedgerTransaction rult) @@ -406,6 +424,21 @@ private async Task ProcessTransactions(ReadWriteDbContext db case CoreModel.ObjectTypeInfoDetails objectDetails: referencedEntity.PostResolveConfigure((ComponentEntity e) => { + e.AssignedModuleIds = objectDetails + .ModuleVersions + .Select(x => + { + return x.Module switch + { + CoreModel.AttachedModuleId.Metadata => ModuleId.Metadata, + CoreModel.AttachedModuleId.Royalty => ModuleId.Royalty, + CoreModel.AttachedModuleId.RoleAssignment => ModuleId.RoleAssignment, + _ => throw new ArgumentOutOfRangeException(nameof(x.Module), x.Module, "Unexpected value of AssignedModule"), + }; + }) + .OrderBy(x => x) + .ToList(); + e.PackageId = referencedEntities.Get((EntityAddress)objectDetails.BlueprintInfo.PackageAddress).DatabaseId; e.BlueprintName = objectDetails.BlueprintInfo.BlueprintName; e.BlueprintVersion = objectDetails.BlueprintInfo.BlueprintVersion; @@ -503,6 +536,8 @@ private async Task ProcessTransactions(ReadWriteDbContext db SignedIntentHash = ult.NotarizedTransaction.SignedIntent.HashBech32m, Message = ult.NotarizedTransaction.SignedIntent.Intent.Message?.ToJson(), RawPayload = ult.NotarizedTransaction.GetPayloadBytes(), + ManifestInstructions = ult.NotarizedTransaction.SignedIntent.Intent.Instructions, + ManifestClasses = manifestClasses.TryGetValue(stateVersion, out var mc) ? mc.ToArray() : Array.Empty(), }, CoreModel.RoundUpdateLedgerTransaction => new RoundUpdateLedgerTransaction(), CoreModel.FlashLedgerTransaction => new FlashLedgerTransaction(), @@ -530,6 +565,7 @@ private async Task ProcessTransactions(ReadWriteDbContext db ledgerTransaction.ReceiptOutput = committedTransaction.Receipt.Output != null ? JsonConvert.SerializeObject(committedTransaction.Receipt.Output) : null; ledgerTransaction.ReceiptNextEpoch = committedTransaction.Receipt.NextEpoch?.ToJson(); ledgerTransaction.ReceiptCostingParameters = committedTransaction.Receipt.CostingParameters.ToJson(); + ledgerTransaction.ReceiptFeeSource = committedTransaction.Receipt.FeeSource?.ToJson(); ledgerTransaction.ReceiptFeeDestination = committedTransaction.Receipt.FeeDestination?.ToJson(); ledgerTransaction.BalanceChanges = committedTransaction.BalanceChanges?.ToJson(); ledgerTransactionsToAdd.Add(ledgerTransaction); @@ -702,23 +738,23 @@ private async Task ProcessTransactions(ReadWriteDbContext db var metadataChanges = new List(); var resourceSupplyChanges = new List(); var validatorSetChanges = new List(); - var stateToAdd = new List(); var vaultHistoryToAdd = new List(); - var keyValueStoreEntryHistoryToAdd = new List(); - var componentMethodRoyaltiesToAdd = new List(); var schemaHistoryToAdd = new List(); var nonFungibleSchemaHistoryToAdd = new List(); var keyValueStoreSchemaHistoryToAdd = new List(); var validatorKeyHistoryToAdd = new Dictionary(); // TODO follow Pointer+ordered List pattern to ensure proper order of ingestion var accountDefaultDepositRuleHistoryToAdd = new List(); var accountResourcePreferenceRuleHistoryToAdd = new List(); - var roleAssignmentsChangePointers = new Dictionary(); - var roleAssignmentChanges = new List(); - var packageCodeChanges = new Dictionary(); - var packageBlueprintChanges = new Dictionary(); - + var keyValueStoreChanges = new Dictionary(); var validatorEmissionStatisticsToAdd = new List(); + var processorContext = new ProcessorContext(sequences, readHelper, writeHelper, token); + var entityStateProcessor = new EntityStateProcessor(processorContext, referencedEntities); + var componentMethodRoyaltyProcessor = new ComponentMethodRoyaltyProcessor(processorContext); + var entityRoleAssignmentProcessor = new EntityRoleAssignmentProcessor(processorContext); + var packageCodeProcessor = new PackageCodeProcessor(processorContext, networkConfiguration.Id); + var packageBlueprintProcessor = new PackageBlueprintProcessor(processorContext, referencedEntities); + // step: scan all substates & events to figure out changes { var sw = Stopwatch.StartNew(); @@ -816,40 +852,13 @@ private async Task ProcessTransactions(ReadWriteDbContext db stateVersion)); } - if (substateData is CoreModel.GenericScryptoComponentFieldStateSubstate componentState) - { - if (substate.SystemStructure is not CoreModel.ObjectFieldStructure objectFieldStructure) - { - throw new UnreachableException($"Generic Scrypto components are expected to have ObjectFieldStructure. Got: {substate.SystemStructure.GetType()}"); - } - - var schemaDetails = objectFieldStructure.ValueSchema.GetSchemaDetails(); - - stateToAdd.Add(new SborStateHistory - { - Id = sequences.StateHistorySequence++, - FromStateVersion = stateVersion, - EntityId = referencedEntities.Get((EntityAddress)substateId.EntityAddress).DatabaseId, - SborState = componentState.Value.DataStruct.StructData.GetDataBytes(), - SchemaHash = schemaDetails.SchemaHash.ConvertFromHex(), - SborTypeKind = schemaDetails.SborTypeKind.ToModel(), - TypeIndex = schemaDetails.TypeIndex, - SchemaDefiningEntityId = referencedEntities.Get((EntityAddress)schemaDetails.SchemaDefiningEntityAddress).DatabaseId, - }); - } - if (substateData is CoreModel.GenericKeyValueStoreEntrySubstate genericKeyValueStoreEntry) { - keyValueStoreEntryHistoryToAdd.Add(new KeyValueStoreEntryHistory - { - Id = sequences.KeyValueStoreEntryHistorySequence++, - FromStateVersion = stateVersion, - KeyValueStoreEntityId = referencedEntity.DatabaseId, - Key = genericKeyValueStoreEntry.Key.KeyData.GetDataBytes(), - Value = genericKeyValueStoreEntry.Value?.Data.StructData.GetDataBytes(), - IsDeleted = genericKeyValueStoreEntry.Value == null, - IsLocked = genericKeyValueStoreEntry.IsLocked, - }); + keyValueStoreChanges + .GetOrAdd( + new KeyValueStoreEntryLookup(referencedEntity.DatabaseId, (ValueBytes)genericKeyValueStoreEntry.Key.KeyData.GetDataBytes()), + _ => new KeyValueStoreChange(stateVersion, genericKeyValueStoreEntry) + ); } if (substateData is CoreModel.ValidatorFieldStateSubstate validator) @@ -865,14 +874,6 @@ private async Task ProcessTransactions(ReadWriteDbContext db KeyType = lookup.PublicKeyType, Key = lookup.PublicKey, }; - - stateToAdd.Add(new JsonStateHistory - { - Id = sequences.StateHistorySequence++, - FromStateVersion = stateVersion, - EntityId = referencedEntities.Get((EntityAddress)substateId.EntityAddress).DatabaseId, - JsonState = validator.Value.ToJson(), - }); } if (substateData is CoreModel.ConsensusManagerFieldStateSubstate consensusManagerFieldStateSubstate) @@ -908,14 +909,6 @@ private async Task ProcessTransactions(ReadWriteDbContext db AccountEntityId = referencedEntity.DatabaseId, DefaultDepositRule = accountFieldState.Value.DefaultDepositRule.ToModel(), }); - - stateToAdd.Add(new JsonStateHistory - { - Id = sequences.StateHistorySequence++, - FromStateVersion = stateVersion, - EntityId = referencedEntities.Get((EntityAddress)substateId.EntityAddress).DatabaseId, - JsonState = accountFieldState.Value.ToJson(), - }); } if (substateData is CoreModel.AccountResourcePreferenceEntrySubstate accountDepositRule) @@ -931,91 +924,6 @@ private async Task ProcessTransactions(ReadWriteDbContext db }); } - if (substateData is CoreModel.RoleAssignmentModuleFieldOwnerRoleSubstate accessRulesFieldOwnerRole) - { - roleAssignmentsChangePointers - .GetOrAdd(new RoleAssignmentsChangePointerLookup(referencedEntity.DatabaseId, stateVersion), lookup => - { - roleAssignmentChanges.Add(lookup); - - return new RoleAssignmentsChangePointer(referencedEntity, stateVersion); - }) - .OwnerRole = accessRulesFieldOwnerRole; - } - - if (substateData is CoreModel.RoleAssignmentModuleRuleEntrySubstate roleAssignmentEntry) - { - roleAssignmentsChangePointers - .GetOrAdd(new RoleAssignmentsChangePointerLookup(referencedEntity.DatabaseId, stateVersion), lookup => - { - roleAssignmentChanges.Add(lookup); - - return new RoleAssignmentsChangePointer(referencedEntity, stateVersion); - }) - .Entries - .Add(roleAssignmentEntry); - } - - if (substateData is CoreModel.PackageBlueprintDefinitionEntrySubstate packageBlueprintDefinition) - { - packageBlueprintChanges - .GetOrAdd( - new PackageBlueprintLookup(referencedEntity.DatabaseId, packageBlueprintDefinition.Key.BlueprintName, packageBlueprintDefinition.Key.BlueprintVersion), - _ => new PackageBlueprintChange(stateVersion) - ) - .PackageBlueprintDefinition = packageBlueprintDefinition; - } - - if (substateData is CoreModel.PackageBlueprintDependenciesEntrySubstate packageBlueprintDependencies) - { - packageBlueprintChanges - .GetOrAdd( - new PackageBlueprintLookup(referencedEntity.DatabaseId, packageBlueprintDependencies.Key.BlueprintName, packageBlueprintDependencies.Key.BlueprintVersion), - _ => new PackageBlueprintChange(stateVersion) - ) - .PackageBlueprintDependencies = packageBlueprintDependencies; - } - - if (substateData is CoreModel.PackageBlueprintRoyaltyEntrySubstate packageBlueprintRoyalty) - { - packageBlueprintChanges - .GetOrAdd( - new PackageBlueprintLookup(referencedEntity.DatabaseId, packageBlueprintRoyalty.Key.BlueprintName, packageBlueprintRoyalty.Key.BlueprintVersion), - _ => new PackageBlueprintChange(stateVersion) - ) - .PackageBlueprintRoyalty = packageBlueprintRoyalty; - } - - if (substateData is CoreModel.PackageBlueprintAuthTemplateEntrySubstate packageBlueprintAuthTemplate) - { - packageBlueprintChanges - .GetOrAdd( - new PackageBlueprintLookup(referencedEntity.DatabaseId, packageBlueprintAuthTemplate.Key.BlueprintName, packageBlueprintAuthTemplate.Key.BlueprintVersion), - _ => new PackageBlueprintChange(stateVersion) - ) - .PackageBlueprintAuthTemplate = packageBlueprintAuthTemplate; - } - - if (substateData is CoreModel.PackageCodeOriginalCodeEntrySubstate packageCodeOriginalCode) - { - packageCodeChanges - .GetOrAdd( - new PackageCodeLookup(referencedEntity.DatabaseId, (ValueBytes)packageCodeOriginalCode.Key.CodeHash.ConvertFromHex()), - _ => new PackageCodeChange(stateVersion) - ) - .PackageCodeOriginalCode = packageCodeOriginalCode; - } - - if (substateData is CoreModel.PackageCodeVmTypeEntrySubstate packageCodeVmType) - { - packageCodeChanges - .GetOrAdd( - new PackageCodeLookup(referencedEntity.DatabaseId, (ValueBytes)packageCodeVmType.Key.CodeHash.ConvertFromHex()), - _ => new PackageCodeChange(stateVersion) - ) - .PackageCodeVmType = packageCodeVmType; - } - if (substateData is CoreModel.SchemaEntrySubstate schema) { schemaHistoryToAdd.Add(new SchemaHistory @@ -1028,19 +936,6 @@ private async Task ProcessTransactions(ReadWriteDbContext db }); } - if (substateData is CoreModel.RoyaltyModuleMethodRoyaltyEntrySubstate methodRoyaltyEntry) - { - componentMethodRoyaltiesToAdd.Add(new ComponentMethodRoyaltyEntryHistory - { - Id = sequences.ComponentMethodRoyaltyEntryHistorySequence++, - FromStateVersion = stateVersion, - EntityId = referencedEntity.DatabaseId, - MethodName = methodRoyaltyEntry.Key.MethodName, - RoyaltyAmount = methodRoyaltyEntry.Value?.ToJson(), - IsLocked = methodRoyaltyEntry.IsLocked, - }); - } - if (substateData is CoreModel.TypeInfoModuleFieldTypeInfoSubstate typeInfoSubstate) { if (typeInfoSubstate.TryGetNonFungibleDataSchemaDetails(out var nonFungibleDataSchemaDetails)) @@ -1090,51 +985,13 @@ private async Task ProcessTransactions(ReadWriteDbContext db } } - if (substateData is CoreModel.AccessControllerFieldStateSubstate accessControllerFieldState) - { - stateToAdd.Add(new JsonStateHistory - { - Id = sequences.StateHistorySequence++, - FromStateVersion = stateVersion, - EntityId = referencedEntities.Get((EntityAddress)substateId.EntityAddress).DatabaseId, - JsonState = accessControllerFieldState.Value.ToJson(), - }); + entityStateProcessor.VisitUpsert(substate, referencedEntity, stateVersion); + componentMethodRoyaltyProcessor.VisitUpsert(substateData, referencedEntity, stateVersion); + entityRoleAssignmentProcessor.VisitUpsert(substateData, referencedEntity, stateVersion); + packageCodeProcessor.VisitUpsert(substateData, referencedEntity, stateVersion); + packageBlueprintProcessor.VisitUpsert(substateData, referencedEntity, stateVersion); } - if (substateData is CoreModel.OneResourcePoolFieldStateSubstate oneResourcePoolFieldStateSubstate) - { - stateToAdd.Add(new JsonStateHistory - { - Id = sequences.StateHistorySequence++, - FromStateVersion = stateVersion, - EntityId = referencedEntities.Get((EntityAddress)substateId.EntityAddress).DatabaseId, - JsonState = oneResourcePoolFieldStateSubstate.Value.ToJson(), - }); - } - - if (substateData is CoreModel.TwoResourcePoolFieldStateSubstate twoResourcePoolFieldStateSubstate) - { - stateToAdd.Add(new JsonStateHistory - { - Id = sequences.StateHistorySequence++, - FromStateVersion = stateVersion, - EntityId = referencedEntities.Get((EntityAddress)substateId.EntityAddress).DatabaseId, - JsonState = twoResourcePoolFieldStateSubstate.Value.ToJson(), - }); - } - - if (substateData is CoreModel.MultiResourcePoolFieldStateSubstate multiResourcePoolFieldStateSubstate) - { - stateToAdd.Add(new JsonStateHistory - { - Id = sequences.StateHistorySequence++, - FromStateVersion = stateVersion, - EntityId = referencedEntities.Get((EntityAddress)substateId.EntityAddress).DatabaseId, - JsonState = multiResourcePoolFieldStateSubstate.Value.ToJson(), - }); - } - } - foreach (var deletedSubstate in stateUpdates.DeletedSubstates) { var substateId = deletedSubstate.SubstateId; @@ -1149,32 +1006,8 @@ private async Task ProcessTransactions(ReadWriteDbContext db vaultSnapshots.Add(new NonFungibleVaultSnapshot(referencedEntity, resourceEntity, simpleRep, true, stateVersion)); } - if (substateId.SubstateType == CoreModel.SubstateType.PackageCodeVmTypeEntry) - { - var keyHex = ((CoreModel.MapSubstateKey)substateId.SubstateKey).KeyHex; - var code_hash = ScryptoSborUtils.DataToProgrammaticScryptoSborValueBytes(keyHex.ConvertFromHex(), _networkConfigurationProvider.GetNetworkId()); - - packageCodeChanges - .GetOrAdd( - new PackageCodeLookup(referencedEntity.DatabaseId, (ValueBytes)code_hash.Hex.ConvertFromHex()), - _ => new PackageCodeChange(stateVersion) - ) - .CodeVmTypeIsDeleted = true; - } - - if (substateId.SubstateType == CoreModel.SubstateType.PackageCodeOriginalCodeEntry) - { - var keyHex = ((CoreModel.MapSubstateKey)substateId.SubstateKey).KeyHex; - var code_hash = ScryptoSborUtils.DataToProgrammaticScryptoSborValueBytes(keyHex.ConvertFromHex(), _networkConfigurationProvider.GetNetworkId()); - - packageCodeChanges - .GetOrAdd( - new PackageCodeLookup(referencedEntity.DatabaseId, (ValueBytes)code_hash.Hex.ConvertFromHex()), - _ => new PackageCodeChange(stateVersion) - ) - .PackageCodeIsDeleted = true; + packageCodeProcessor.VisitDelete(substateId, referencedEntity, stateVersion); } - } var transaction = ledgerTransactionsToAdd.Single(x => x.StateVersion == stateVersion); @@ -1206,7 +1039,7 @@ private async Task ProcessTransactions(ReadWriteDbContext db var eventEmitterEntity = referencedEntities.Get((EntityAddress)methodEventEmitter.Entity.EntityAddress); - using var decodedEvent = EventDecoder.DecodeEvent(@event, _networkConfigurationProvider.GetNetworkId()); + using var decodedEvent = EventDecoder.DecodeEvent(@event, networkConfiguration.Id); if (EventDecoder.TryGetValidatorEmissionsAppliedEvent(decodedEvent, out var validatorUptimeEvent)) { @@ -1306,6 +1139,20 @@ private async Task ProcessTransactions(ReadWriteDbContext db } } + foreach (var address in extractedAddresses.AccountsRequiringAuth) + { + if (referencedEntities.TryGet(address, out var re)) + { + ledgerTransactionMarkersToAdd.Add(new ManifestAddressLedgerTransactionMarker + { + Id = sequences.LedgerTransactionMarkerSequence++, + StateVersion = stateVersion, + OperationType = LedgerTransactionMarkerOperationType.AccountOwnerMethodCall, + EntityId = re.DatabaseId, + }); + } + } + foreach (var address in extractedAddresses.AccountsDepositedInto) { if (referencedEntities.TryGet(address, out var re)) @@ -1351,8 +1198,6 @@ private async Task ProcessTransactions(ReadWriteDbContext db var mostRecentMetadataHistory = await readHelper.MostRecentEntityMetadataHistoryFor(metadataChanges, token); var mostRecentAggregatedMetadataHistory = await readHelper.MostRecentEntityAggregateMetadataHistoryFor(metadataChanges, token); - var mostRecentAccessRulesEntryHistory = await readHelper.MostRecentEntityRoleAssignmentsEntryHistoryFor(roleAssignmentsChangePointers.Values, token); - var mostRecentAccessRulesAggregateHistory = await readHelper.MostRecentEntityRoleAssignmentsAggregateHistoryFor(roleAssignmentChanges, token); var mostRecentEntityResourceAggregateHistory = await readHelper.MostRecentEntityResourceAggregateHistoryFor(vaultSnapshots, token); var mostRecentEntityResourceAggregatedVaultsHistory = await readHelper.MostRecentEntityResourceAggregatedVaultsHistoryFor(vaultChanges, token); var mostRecentEntityResourceVaultAggregateHistory = await readHelper.MostRecentEntityResourceVaultAggregateHistoryFor(vaultSnapshots, token); @@ -1361,10 +1206,13 @@ private async Task ProcessTransactions(ReadWriteDbContext db var mostRecentEntityNonFungibleVaultHistory = await readHelper.MostRecentEntityNonFungibleVaultHistory(vaultSnapshots.OfType().ToList(), token); var existingNonFungibleIdData = await readHelper.ExistingNonFungibleIdDataFor(nonFungibleIdChanges, vaultSnapshots.OfType().ToList(), token); var existingValidatorKeys = await readHelper.ExistingValidatorKeysFor(validatorSetChanges, token); - var mostRecentPackageBlueprintAggregateHistory = await readHelper.MostRecentPackageBlueprintAggregateHistoryFor(packageBlueprintChanges.Keys, token); - var mostRecentPackageBlueprintHistory = await readHelper.MostRecentPackageBlueprintHistoryFor(packageBlueprintChanges.Keys, token); - var mostRecentPackageCodeHistory = await readHelper.MostRecentPackageCodeHistoryFor(packageCodeChanges.Keys, token); - var mostRecentPackageCodeAggregateHistory = await readHelper.MostRecentPackageCodeAggregateHistoryFor(packageCodeChanges.Keys, token); + var mostRecentKeyValueStoreEntryHistory = await readHelper.MostRecentKeyValueStoreEntryHistoryFor(keyValueStoreChanges.Keys, token); + var mostRecentKeyValueStoreAggregateHistory = await readHelper.MostRecentKeyValueStoreAggregateHistoryFor(keyValueStoreChanges.Keys, token); + + await componentMethodRoyaltyProcessor.LoadMostRecent(); + await entityRoleAssignmentProcessor.LoadMostRecent(); + await packageCodeProcessor.LoadMostRecent(); + await packageBlueprintProcessor.LoadMostRecent(); dbReadDuration += sw.Elapsed; @@ -1373,19 +1221,13 @@ private async Task ProcessTransactions(ReadWriteDbContext db var entityResourceAggregateHistoryCandidates = new List(); var entityResourceAggregatedVaultsHistoryToAdd = new List(); var entityResourceVaultAggregateHistoryCandidates = new List(); - var entityAccessRulesOwnerRoleHistoryToAdd = new List(); - var entityAccessRulesEntryHistoryToAdd = new List(); - var entityAccessRulesAggregateHistoryToAdd = new List(); var nonFungibleIdStoreHistoryToAdd = new Dictionary(); var nonFungibleIdDataToAdd = new List(); var nonFungibleIdLocationHistoryToAdd = new List(); var nonFungibleIdsMutableDataHistoryToAdd = new List(); - var (packageBlueprintHistoryToAdd, packageBlueprintAggregateHistoryToAdd) = - PackageBlueprintAggregator.AggregatePackageBlueprint(packageBlueprintChanges, mostRecentPackageBlueprintHistory, mostRecentPackageBlueprintAggregateHistory, referencedEntities, sequences); - - var (packageCodeHistoryToAdd, packageCodeAggregateHistoryToAdd) = - PackageCodeAggregator.AggregatePackageCode(packageCodeChanges, mostRecentPackageCodeHistory, mostRecentPackageCodeAggregateHistory, sequences); + var (keyValueStoreEntryHistoryToAdd, keyValueStoreAggregateHistoryToAdd) = + KeyValueStoreAggregator.AggregateKeyValueStore(keyValueStoreChanges, mostRecentKeyValueStoreEntryHistory, mostRecentKeyValueStoreAggregateHistory, sequences); foreach (var metadataChange in metadataChanges) { @@ -1447,86 +1289,10 @@ private async Task ProcessTransactions(ReadWriteDbContext db mostRecentMetadataHistory[lookup] = metadataHistory; } - foreach (var lookup in roleAssignmentChanges) - { - var accessRuleChange = roleAssignmentsChangePointers[lookup]; - - EntityRoleAssignmentsOwnerRoleHistory? ownerRole = null; - - if (accessRuleChange.OwnerRole != null) - { - ownerRole = new EntityRoleAssignmentsOwnerRoleHistory - { - Id = sequences.EntityRoleAssignmentsOwnerRoleHistorySequence++, - FromStateVersion = lookup.StateVersion, - EntityId = lookup.EntityId, - RoleAssignments = accessRuleChange.OwnerRole.Value.OwnerRole.ToJson(), - }; - - entityAccessRulesOwnerRoleHistoryToAdd.Add(ownerRole); - } - - EntityRoleAssignmentsAggregateHistory aggregate; - - if (!mostRecentAccessRulesAggregateHistory.TryGetValue(lookup.EntityId, out var previousAggregate) || previousAggregate.FromStateVersion != lookup.StateVersion) - { - aggregate = new EntityRoleAssignmentsAggregateHistory - { - Id = sequences.EntityRoleAssignmentsAggregateHistorySequence++, - FromStateVersion = lookup.StateVersion, - EntityId = lookup.EntityId, - OwnerRoleId = ownerRole?.Id ?? previousAggregate?.OwnerRoleId ?? throw new InvalidOperationException("Unable to determine OwnerRoleId"), - EntryIds = new List(), - }; - - if (previousAggregate != null) - { - aggregate.EntryIds.AddRange(previousAggregate.EntryIds); - } - - entityAccessRulesAggregateHistoryToAdd.Add(aggregate); - mostRecentAccessRulesAggregateHistory[lookup.EntityId] = aggregate; - } - else - { - aggregate = previousAggregate; - } - - foreach (var entry in accessRuleChange.Entries) - { - var entryLookup = new RoleAssignmentEntryLookup(lookup.EntityId, entry.Key.RoleKey, entry.Key.ObjectModuleId.ToModel()); - var entryHistory = new EntityRoleAssignmentsEntryHistory - { - Id = sequences.EntityRoleAssignmentsEntryHistorySequence++, - FromStateVersion = lookup.StateVersion, - EntityId = lookup.EntityId, - KeyRole = entry.Key.RoleKey, - KeyModule = entry.Key.ObjectModuleId.ToModel(), - RoleAssignments = entry.Value?.AccessRule.ToJson(), - IsDeleted = entry.Value == null, - }; - - entityAccessRulesEntryHistoryToAdd.Add(entryHistory); - - if (mostRecentAccessRulesEntryHistory.TryGetValue(entryLookup, out var previousEntry)) - { - var currentPosition = aggregate.EntryIds.IndexOf(previousEntry.Id); - - if (currentPosition != -1) - { - aggregate.EntryIds.RemoveAt(currentPosition); - } - } - - // !entry.IsDeleted - if (entry.Value != null) - { - aggregate.EntryIds.Insert(0, entryHistory.Id); - } - - mostRecentAccessRulesEntryHistory[entryLookup] = entryHistory; - } - } + componentMethodRoyaltyProcessor.ProcessChanges(); + entityRoleAssignmentProcessor.ProcessChanges(); + packageCodeProcessor.ProcessChanges(); + packageBlueprintProcessor.ProcessChanges(); foreach (var e in nonFungibleIdChanges) { @@ -1866,17 +1632,12 @@ void AggregateEntityResourceVaultInternal(long entityId, long resourceEntityId, rowsInserted += await writeHelper.CopyEntity(entitiesToAdd, token); rowsInserted += await writeHelper.CopyLedgerTransaction(ledgerTransactionsToAdd, token); rowsInserted += await writeHelper.CopyLedgerTransactionMarkers(ledgerTransactionMarkersToAdd, token); - rowsInserted += await writeHelper.CopyStateHistory(stateToAdd, token); rowsInserted += await writeHelper.CopyEntityMetadataHistory(entityMetadataHistoryToAdd, token); rowsInserted += await writeHelper.CopyEntityMetadataAggregateHistory(entityMetadataAggregateHistoryToAdd, token); - rowsInserted += await writeHelper.CopyEntityRoleAssignmentsOwnerRoleHistory(entityAccessRulesOwnerRoleHistoryToAdd, token); - rowsInserted += await writeHelper.CopyEntityRoleAssignmentsRulesEntryHistory(entityAccessRulesEntryHistoryToAdd, token); - rowsInserted += await writeHelper.CopyEntityRoleAssignmentsAggregateHistory(entityAccessRulesAggregateHistoryToAdd, token); rowsInserted += await writeHelper.CopyEntityResourceAggregatedVaultsHistory(entityResourceAggregatedVaultsHistoryToAdd, token); rowsInserted += await writeHelper.CopyEntityResourceAggregateHistory(entityResourceAggregateHistoryToAdd, token); rowsInserted += await writeHelper.CopyEntityResourceVaultAggregateHistory(entityResourceVaultAggregateHistoryToAdd, token); rowsInserted += await writeHelper.CopyEntityVaultHistory(vaultHistoryToAdd, token); - rowsInserted += await writeHelper.CopyComponentMethodRoyalties(componentMethodRoyaltiesToAdd, token); rowsInserted += await writeHelper.CopyNonFungibleIdData(nonFungibleIdDataToAdd, token); rowsInserted += await writeHelper.CopyNonFungibleIdDataHistory(nonFungibleIdsMutableDataHistoryToAdd, token); rowsInserted += await writeHelper.CopyNonFungibleIdStoreHistory(nonFungibleIdStoreHistoryToAdd.Values, token); @@ -1884,17 +1645,21 @@ void AggregateEntityResourceVaultInternal(long entityId, long resourceEntityId, rowsInserted += await writeHelper.CopyResourceEntitySupplyHistory(resourceEntitySupplyHistoryToAdd, token); rowsInserted += await writeHelper.CopyValidatorKeyHistory(validatorKeyHistoryToAdd.Values, token); rowsInserted += await writeHelper.CopyValidatorActiveSetHistory(validatorActiveSetHistoryToAdd, token); - rowsInserted += await writeHelper.CopyPackageBlueprintHistory(packageBlueprintHistoryToAdd, token); - rowsInserted += await writeHelper.CopyPackageCodeHistory(packageCodeHistoryToAdd, token); - rowsInserted += await writeHelper.CopyPackageCodeAggregateHistory(packageCodeAggregateHistoryToAdd, token); rowsInserted += await writeHelper.CopySchemaHistory(schemaHistoryToAdd, token); rowsInserted += await writeHelper.CopyKeyValueStoreEntryHistory(keyValueStoreEntryHistoryToAdd, token); + rowsInserted += await writeHelper.CopyKeyValueStoreAggregateHistory(keyValueStoreAggregateHistoryToAdd, token); rowsInserted += await writeHelper.CopyAccountDefaultDepositRuleHistory(accountDefaultDepositRuleHistoryToAdd, token); rowsInserted += await writeHelper.CopyAccountResourcePreferenceRuleHistory(accountResourcePreferenceRuleHistoryToAdd, token); rowsInserted += await writeHelper.CopyValidatorEmissionStatistics(validatorEmissionStatisticsToAdd, token); rowsInserted += await writeHelper.CopyNonFungibleDataSchemaHistory(nonFungibleSchemaHistoryToAdd, token); rowsInserted += await writeHelper.CopyKeyValueStoreSchemaHistory(keyValueStoreSchemaHistoryToAdd, token); - rowsInserted += await writeHelper.CopyPackageBlueprintAggregateHistory(packageBlueprintAggregateHistoryToAdd, token); + + rowsInserted += await entityStateProcessor.SaveEntities(); + rowsInserted += await componentMethodRoyaltyProcessor.SaveEntities(); + rowsInserted += await entityRoleAssignmentProcessor.SaveEntities(); + rowsInserted += await packageCodeProcessor.SaveEntities(); + rowsInserted += await packageBlueprintProcessor.SaveEntities(); + await writeHelper.UpdateSequences(sequences, token); dbWriteDuration += sw.Elapsed; @@ -1906,17 +1671,4 @@ void AggregateEntityResourceVaultInternal(long entityId, long resourceEntityId, return new ExtendLedgerReport(lastTransactionSummary, rowsInserted + rowsUpdated, dbReadDuration, dbWriteDuration, contentHandlingDuration); } - - private async Task EnsureDbLedgerIsInitialized(CancellationToken token) - { - var created = await _networkConfigurationProvider.SaveLedgerNetworkConfigurationToDatabaseOnInitIfNotExists(token); - - if (created) - { - _logger.LogInformation( - "Ledger initialized with network: {NetworkName}", - _networkConfigurationProvider.GetNetworkName() - ); - } - } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/DictionaryExtensions.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ProcessorContext.cs similarity index 89% rename from src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/DictionaryExtensions.cs rename to src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ProcessorContext.cs index b0c01dea0..816325f15 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/DictionaryExtensions.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ProcessorContext.cs @@ -62,25 +62,8 @@ * permissions under this License. */ -using System; -using System.Collections.Generic; +using System.Threading; namespace RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; -internal static class DictionaryExtensions -{ - public static TVal GetOrAdd(this IDictionary dictionary, TKey key, Func factory) - where TKey : notnull - { - if (dictionary.TryGetValue(key, out var existingValue)) - { - return existingValue; - } - - var value = factory(key); - - dictionary[key] = value; - - return value; - } -} +internal record ProcessorContext(SequencesHolder Sequences, ReadHelper ReadHelper, WriteHelper WriteHelper, CancellationToken Token); diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ReadHelper.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ReadHelper.cs index a7cd26b71..c7f79bf80 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ReadHelper.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/ReadHelper.cs @@ -64,6 +64,7 @@ using Dapper; using Microsoft.EntityFrameworkCore; +using Microsoft.EntityFrameworkCore.Query; using Npgsql; using NpgsqlTypes; using RadixDlt.NetworkGateway.Abstractions; @@ -71,9 +72,11 @@ using RadixDlt.NetworkGateway.Abstractions.Model; using RadixDlt.NetworkGateway.DataAggregator.Services; using RadixDlt.NetworkGateway.PostgresIntegration.Models; +using System; using System.Collections.Generic; using System.Diagnostics; using System.Linq; +using System.Runtime.CompilerServices; using System.Threading; using System.Threading.Tasks; using PublicKeyType = RadixDlt.NetworkGateway.Abstractions.Model.PublicKeyType; @@ -85,98 +88,30 @@ internal class ReadHelper private readonly ReadWriteDbContext _dbContext; private readonly NpgsqlConnection _connection; private readonly IEnumerable _observers; + private readonly CancellationToken _token; - public ReadHelper(ReadWriteDbContext dbContext, IEnumerable observers) + public ReadHelper(ReadWriteDbContext dbContext, IEnumerable observers, CancellationToken token = default) { _dbContext = dbContext; _connection = (NpgsqlConnection)dbContext.Database.GetDbConnection(); _observers = observers; + _token = token; } - public async Task> MostRecentPackageBlueprintHistoryFor(ICollection packageBlueprintLookups, CancellationToken token) + public async Task> MostRecent([NotParameterized] FormattableString sql, Func keySelector, [CallerMemberName] string stageName = "") + where TKey : notnull + where TValue : class { - if (!packageBlueprintLookups.Any()) - { - return new Dictionary(); - } - var sw = Stopwatch.GetTimestamp(); - var entityIds = new List(); - var names = new List(); - var versions = new List(); - var lookupSet = packageBlueprintLookups.ToHashSet(); - - foreach (var lookup in lookupSet) - { - entityIds.Add(lookup.PackageEntityId); - names.Add(lookup.Name); - versions.Add(lookup.Version); - } - var result = await _dbContext - .PackageBlueprintHistory - .FromSqlInterpolated(@$" -WITH variables (entity_id, name, version) AS ( - SELECT UNNEST({entityIds}), UNNEST({names}), UNNEST({versions}) -) -SELECT pbh.* -FROM variables -INNER JOIN LATERAL ( - SELECT * - FROM package_blueprint_history - WHERE package_entity_id = variables.entity_id AND name = variables.name AND version = variables.version - ORDER BY from_state_version DESC - LIMIT 1 -) pbh ON true;") + .Set() + .FromSqlInterpolated(sql) .AsNoTracking() - .AnnotateMetricName() - .ToDictionaryAsync(e => new PackageBlueprintLookup(e.PackageEntityId, e.Name, e.Version), token); + .AnnotateMetricName(stageName) + .ToDictionaryAsync(keySelector, _token); - await _observers.ForEachAsync(x => x.StageCompleted(nameof(MostRecentPackageBlueprintHistoryFor), Stopwatch.GetElapsedTime(sw), result.Count)); - - return result; - } - - public async Task> MostRecentPackageCodeHistoryFor(ICollection packageCodeChanges, CancellationToken token) - { - if (!packageCodeChanges.Any()) - { - return new Dictionary(); - } - - var sw = Stopwatch.GetTimestamp(); - - var entityIds = new List(); - var codeHashes = new List(); - var lookupSet = packageCodeChanges.ToHashSet(); - - foreach (var lookup in lookupSet) - { - entityIds.Add(lookup.PackageEntityId); - codeHashes.Add(lookup.CodeHash); - } - - var result = await _dbContext - .PackageCodeHistory - .FromSqlInterpolated(@$" -WITH variables (entity_id, code_hash) AS ( - SELECT UNNEST({entityIds}), UNNEST({codeHashes}) -) -SELECT pbh.* -FROM variables -INNER JOIN LATERAL ( - SELECT * - FROM package_code_history - WHERE package_entity_id = variables.entity_id AND code_hash = variables.code_hash - ORDER BY from_state_version DESC - LIMIT 1 -) pbh ON true;") - .AsNoTracking() - .AnnotateMetricName() - .ToDictionaryAsync(e => new PackageCodeLookup(e.PackageEntityId, e.CodeHash), token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(MostRecentPackageCodeHistoryFor), Stopwatch.GetElapsedTime(sw), result.Count)); + await _observers.ForEachAsync(x => x.StageCompleted(stageName, Stopwatch.GetElapsedTime(sw), result.Count)); return result; } @@ -228,7 +163,7 @@ LIMIT 1 return result; } - public async Task> MostRecentPackageCodeAggregateHistoryFor(ICollection packageCodeChanges, CancellationToken token) + public async Task> MostRecentPackageCodeAggregateHistoryFor(ICollection packageCodeChanges, CancellationToken token) { if (!packageCodeChanges.Any()) { @@ -262,7 +197,7 @@ LIMIT 1 return result; } - public async Task> MostRecentPackageBlueprintAggregateHistoryFor(ICollection packageBlueprintChanges, CancellationToken token) + public async Task> MostRecentPackageBlueprintAggregateHistoryFor(ICollection packageBlueprintChanges, CancellationToken token) { if (!packageBlueprintChanges.Any()) { @@ -275,18 +210,7 @@ public async Task> MostRecent var result = await _dbContext .PackageBlueprintAggregateHistory .FromSqlInterpolated(@$" -WITH variables (package_entity_id) AS ( - SELECT UNNEST({packageEntityIds}) -) -SELECT pbah.* -FROM variables -INNER JOIN LATERAL ( - SELECT * - FROM package_blueprint_aggregate_history - WHERE package_entity_id = variables.package_entity_id - ORDER BY from_state_version DESC - LIMIT 1 -) pbah ON true;") +") .AsNoTracking() .AnnotateMetricName() .ToDictionaryAsync(e => e.PackageEntityId, token); @@ -330,96 +254,6 @@ LIMIT 1 return result; } - public async Task> MostRecentEntityRoleAssignmentsEntryHistoryFor( - ICollection roleAssignmentsChangePointers, - CancellationToken token) - { - if (!roleAssignmentsChangePointers.Any()) - { - return new Dictionary(); - } - - var sw = Stopwatch.GetTimestamp(); - var entityIds = new List(); - var keyRoles = new List(); - var keyModuleIds = new List(); - var lookupSet = new HashSet(); - - foreach (var roleAssignmentsChangePointer in roleAssignmentsChangePointers) - { - foreach (var entry in roleAssignmentsChangePointer.Entries) - { - lookupSet.Add(new RoleAssignmentEntryLookup(roleAssignmentsChangePointer.ReferencedEntity.DatabaseId, entry.Key.RoleKey, entry.Key.ObjectModuleId.ToModel())); - } - } - - foreach (var lookup in lookupSet) - { - entityIds.Add(lookup.EntityId); - keyRoles.Add(lookup.KeyRole); - keyModuleIds.Add(lookup.KeyModule); - } - - var result = await _dbContext - .EntityRoleAssignmentsEntryHistory - .FromSqlInterpolated(@$" -WITH variables (entity_id, key_role, module_id) AS ( - SELECT UNNEST({entityIds}), UNNEST({keyRoles}), UNNEST({keyModuleIds}) -) -SELECT eareh.* -FROM variables -INNER JOIN LATERAL ( - SELECT * - FROM entity_role_assignments_entry_history - WHERE entity_id = variables.entity_id AND key_role = variables.key_role AND key_module = variables.module_id - ORDER BY from_state_version DESC - LIMIT 1 -) eareh ON true;") - .AsNoTracking() - .AnnotateMetricName() - .ToDictionaryAsync(e => new RoleAssignmentEntryLookup(e.EntityId, e.KeyRole, e.KeyModule), token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(MostRecentEntityRoleAssignmentsEntryHistoryFor), Stopwatch.GetElapsedTime(sw), result.Count)); - - return result; - } - - public async Task> MostRecentEntityRoleAssignmentsAggregateHistoryFor( - List roleAssignmentChanges, - CancellationToken token) - { - if (!roleAssignmentChanges.Any()) - { - return new Dictionary(); - } - - var sw = Stopwatch.GetTimestamp(); - var entityIds = roleAssignmentChanges.Select(x => x.EntityId).Distinct().ToList(); - - var result = await _dbContext - .EntityRoleAssignmentsAggregateHistory - .FromSqlInterpolated(@$" -WITH variables (entity_id) AS ( - SELECT UNNEST({entityIds}) -) -SELECT earah.* -FROM variables -INNER JOIN LATERAL ( - SELECT * - FROM entity_role_assignments_aggregate_history - WHERE entity_id = variables.entity_id - ORDER BY from_state_version DESC - LIMIT 1 -) earah ON true;") - .AsNoTracking() - .AnnotateMetricName() - .ToDictionaryAsync(e => e.EntityId, token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(MostRecentEntityRoleAssignmentsAggregateHistoryFor), Stopwatch.GetElapsedTime(sw), result.Count)); - - return result; - } - public async Task> MostRecentEntityResourceAggregateHistoryFor(List vaultSnapshots, CancellationToken token) { if (!vaultSnapshots.Any()) @@ -733,6 +567,82 @@ SELECT UNNEST({resourceEntityIds}), UNNEST({nonFungibleIds}) return result; } + public async Task> MostRecentKeyValueStoreEntryHistoryFor(ICollection keyValueStoreLookups, CancellationToken token) + { + if (!keyValueStoreLookups.Any()) + { + return new Dictionary(); + } + + var sw = Stopwatch.GetTimestamp(); + + var keyValueStoreEntityIds = new List(); + var keys = new List(); + + foreach (var lookup in keyValueStoreLookups) + { + keyValueStoreEntityIds.Add(lookup.KeyValueStoreEntityId); + keys.Add(lookup.Key); + } + + var result = await _dbContext + .KeyValueStoreEntryHistory + .FromSqlInterpolated(@$" +WITH variables (key_value_store_entity_id, key) AS ( + SELECT UNNEST({keyValueStoreEntityIds}), UNNEST({keys}) +) +SELECT kvseh.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM key_value_store_entry_history + WHERE key_value_store_entity_id = variables.key_value_store_entity_id AND key = variables.key + ORDER BY from_state_version DESC + LIMIT 1 +) kvseh ON true;") + .AsNoTracking() + .AnnotateMetricName() + .ToDictionaryAsync(e => new KeyValueStoreEntryLookup(e.KeyValueStoreEntityId, (ValueBytes)e.Key), token); + + await _observers.ForEachAsync(x => x.StageCompleted(nameof(MostRecentKeyValueStoreEntryHistoryFor), Stopwatch.GetElapsedTime(sw), result.Count)); + + return result; + } + + public async Task> MostRecentKeyValueStoreAggregateHistoryFor(ICollection keyValueStoreLookups, CancellationToken token) + { + if (!keyValueStoreLookups.Any()) + { + return new Dictionary(); + } + + var sw = Stopwatch.GetTimestamp(); + var packageEntityIds = keyValueStoreLookups.Select(x => x.KeyValueStoreEntityId).Distinct().ToList(); + + var result = await _dbContext + .KeyValueStoreAggregateHistory + .FromSqlInterpolated(@$" +WITH variables (key_value_store_entity_id) AS ( + SELECT UNNEST({packageEntityIds}) +) +SELECT kvsah.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM key_value_store_aggregate_history + WHERE key_value_store_entity_id = variables.key_value_store_entity_id + ORDER BY from_state_version DESC + LIMIT 1 +) kvsah ON true;") + .AsNoTracking() + .AnnotateMetricName() + .ToDictionaryAsync(e => e.KeyValueStoreEntityId, token); + + await _observers.ForEachAsync(x => x.StageCompleted(nameof(MostRecentKeyValueStoreAggregateHistoryFor), Stopwatch.GetElapsedTime(sw), result.Count)); + + return result; + } + public async Task> ExistingValidatorKeysFor(List validatorKeyLookups, CancellationToken token) { if (!validatorKeyLookups.Any()) @@ -804,6 +714,7 @@ public async Task LoadSequences(CancellationToken token) nextval('entity_role_assignments_entry_history_id_seq') AS EntityRoleAssignmentsEntryHistorySequence, nextval('entity_role_assignments_owner_role_history_id_seq') AS EntityRoleAssignmentsOwnerRoleHistorySequence, nextval('component_method_royalty_entry_history_id_seq') AS ComponentMethodRoyaltyEntryHistorySequence, + nextval('component_method_royalty_aggregate_history_id_seq') AS ComponentMethodRoyaltyAggregateHistorySequence, nextval('resource_entity_supply_history_id_seq') AS ResourceEntitySupplyHistorySequence, nextval('non_fungible_id_data_id_seq') AS NonFungibleIdDataSequence, nextval('non_fungible_id_data_history_id_seq') AS NonFungibleIdDataHistorySequence, @@ -820,7 +731,9 @@ public async Task LoadSequences(CancellationToken token) nextval('non_fungible_schema_history_id_seq') AS NonFungibleSchemaHistorySequence, nextval('key_value_store_schema_history_id_seq') AS KeyValueSchemaHistorySequence, nextval('package_blueprint_aggregate_history_id_seq') AS PackageBlueprintAggregateHistorySequence, - nextval('package_code_aggregate_history_id_seq') AS PackageCodeAggregateHistorySequence", + nextval('package_code_aggregate_history_id_seq') AS PackageCodeAggregateHistorySequence, + nextval('key_value_store_aggregate_history_id_seq') AS KeyValueStoreAggregateHistorySequence +", cancellationToken: token); var result = await _connection.QueryFirstAsync(cd); diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/Records.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/Records.cs index 713cad701..d7fef6da8 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/Records.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/Records.cs @@ -118,14 +118,3 @@ internal record struct NonFungibleStoreLookup(long NonFungibleEntityId, long Sta internal record struct NonFungibleIdLookup(long ResourceEntityId, string NonFungibleId); internal record struct ValidatorKeyLookup(long ValidatorEntityId, PublicKeyType PublicKeyType, ValueBytes PublicKey); - -internal record struct RoleAssignmentsChangePointerLookup(long EntityId, long StateVersion); - -internal record struct RoleAssignmentEntryLookup(long EntityId, string KeyRole, ModuleId KeyModule); - -internal record RoleAssignmentsChangePointer(ReferencedEntity ReferencedEntity, long StateVersion) -{ - public CoreModel.RoleAssignmentModuleFieldOwnerRoleSubstate? OwnerRole { get; set; } - - public IList Entries { get; } = new List(); -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/SequencesHolder.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/SequencesHolder.cs index 39038a907..810af98b5 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/SequencesHolder.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/SequencesHolder.cs @@ -94,6 +94,8 @@ internal class SequencesHolder public long ComponentMethodRoyaltyEntryHistorySequence { get; set; } + public long ComponentMethodRoyaltyAggregateHistorySequence { get; set; } + public long ResourceEntitySupplyHistorySequence { get; set; } public long NonFungibleIdDataSequence { get; set; } @@ -127,4 +129,6 @@ internal class SequencesHolder public long PackageBlueprintAggregateHistorySequence { get; set; } public long PackageCodeAggregateHistorySequence { get; set; } + + public long KeyValueStoreAggregateHistorySequence { get; set; } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/WriteHelper.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/WriteHelper.cs index 63086801f..4de453f40 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/WriteHelper.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/LedgerExtension/WriteHelper.cs @@ -76,6 +76,7 @@ using System.Collections.Generic; using System.Diagnostics; using System.Linq; +using System.Runtime.CompilerServices; using System.Threading; using System.Threading.Tasks; @@ -86,12 +87,38 @@ internal class WriteHelper private readonly NpgsqlConnection _connection; private readonly IModel _model; private readonly IEnumerable _observers; + private readonly CancellationToken _token; - public WriteHelper(ReadWriteDbContext dbContext, IEnumerable observers) + public WriteHelper(ReadWriteDbContext dbContext, IEnumerable observers, CancellationToken token = default) { _connection = (NpgsqlConnection)dbContext.Database.GetDbConnection(); _model = dbContext.Model; _observers = observers; + _token = token; + } + + public async Task Copy(ICollection entities, string copy, Func callback, [CallerMemberName] string stageName = "") + { + if (!entities.Any()) + { + return 0; + } + + var sw = Stopwatch.GetTimestamp(); + + await using var writer = await _connection.BeginBinaryImportAsync(copy, _token); + + foreach (var e in entities) + { + await writer.StartRowAsync(_token); + await callback(writer, e, _token); + } + + await writer.CompleteAsync(_token); + + await _observers.ForEachAsync(x => x.StageCompleted(stageName, Stopwatch.GetElapsedTime(sw), entities.Count)); + + return entities.Count; } public async Task CopyEntity(ICollection entities, CancellationToken token) @@ -104,7 +131,7 @@ public async Task CopyEntity(ICollection entities, CancellationToke var sw = Stopwatch.GetTimestamp(); await using var writer = await _connection.BeginBinaryImportAsync( - "COPY entities (id, from_state_version, address, is_global, ancestor_ids, parent_ancestor_id, owner_ancestor_id, global_ancestor_id, correlated_entities, discriminator, package_id, blueprint_name, blueprint_version, divisibility, non_fungible_id_type, stake_vault_entity_id, pending_xrd_withdraw_vault_entity_id, locked_owner_stake_unit_vault_entity_id, pending_owner_stake_unit_unlock_vault_entity_id, resource_entity_id, royalty_vault_of_entity_id) FROM STDIN (FORMAT BINARY)", + "COPY entities (id, from_state_version, address, is_global, ancestor_ids, parent_ancestor_id, owner_ancestor_id, global_ancestor_id, correlated_entities, discriminator, package_id, blueprint_name, blueprint_version, assigned_module_ids, divisibility, non_fungible_id_type, stake_vault_entity_id, pending_xrd_withdraw_vault_entity_id, locked_owner_stake_unit_vault_entity_id, pending_owner_stake_unit_unlock_vault_entity_id, resource_entity_id, royalty_vault_of_entity_id) FROM STDIN (FORMAT BINARY)", token); foreach (var e in entities) @@ -128,12 +155,14 @@ public async Task CopyEntity(ICollection entities, CancellationToke await writer.WriteAsync(ce.PackageId, NpgsqlDbType.Bigint, token); await writer.WriteAsync(ce.BlueprintName, NpgsqlDbType.Text, token); await writer.WriteAsync(ce.BlueprintVersion, NpgsqlDbType.Text, token); + await writer.WriteAsync(ce.AssignedModuleIds, "module_id[]", token); } else { await writer.WriteNullAsync(token); await writer.WriteNullAsync(token); await writer.WriteNullAsync(token); + await writer.WriteNullAsync(token); } if (e is GlobalFungibleResourceEntity frme) @@ -203,7 +232,7 @@ public async Task CopyLedgerTransaction(ICollection enti var sw = Stopwatch.GetTimestamp(); await using var writer = await _connection.BeginBinaryImportAsync( - "COPY ledger_transactions (state_version, transaction_tree_hash, receipt_tree_hash, state_tree_hash, epoch, round_in_epoch, index_in_epoch, index_in_round, fee_paid, tip_paid, affected_global_entities, round_timestamp, created_timestamp, normalized_round_timestamp, receipt_state_updates, receipt_status, receipt_fee_summary, receipt_fee_source, receipt_fee_destination, receipt_costing_parameters, receipt_error_message, receipt_output, receipt_next_epoch, receipt_event_emitters, receipt_event_names, receipt_event_sbors, receipt_event_schema_entity_ids, receipt_event_schema_hashes, receipt_event_type_indexes, receipt_event_sbor_type_kinds, discriminator, payload_hash, intent_hash, signed_intent_hash, message, raw_payload, balance_changes) FROM STDIN (FORMAT BINARY)", + "COPY ledger_transactions (state_version, transaction_tree_hash, receipt_tree_hash, state_tree_hash, epoch, round_in_epoch, index_in_epoch, index_in_round, fee_paid, tip_paid, affected_global_entities, round_timestamp, created_timestamp, normalized_round_timestamp, balance_changes, receipt_state_updates, receipt_status, receipt_fee_summary, receipt_fee_source, receipt_fee_destination, receipt_costing_parameters, receipt_error_message, receipt_output, receipt_next_epoch, receipt_event_emitters, receipt_event_names, receipt_event_sbors, receipt_event_schema_entity_ids, receipt_event_schema_hashes, receipt_event_type_indexes, receipt_event_sbor_type_kinds, discriminator, payload_hash, intent_hash, signed_intent_hash, message, raw_payload, manifest_instructions, manifest_classes) FROM STDIN (FORMAT BINARY)", token); foreach (var lt in entities) @@ -225,6 +254,7 @@ public async Task CopyLedgerTransaction(ICollection enti await writer.WriteAsync(lt.RoundTimestamp, NpgsqlDbType.TimestampTz, token); await writer.WriteAsync(lt.CreatedTimestamp, NpgsqlDbType.TimestampTz, token); await writer.WriteAsync(lt.NormalizedRoundTimestamp, NpgsqlDbType.TimestampTz, token); + await writer.WriteAsync(lt.BalanceChanges, NpgsqlDbType.Jsonb, token); await writer.WriteAsync(lt.EngineReceipt.StateUpdates, NpgsqlDbType.Jsonb, token); await writer.WriteAsync(lt.EngineReceipt.Status, "ledger_transaction_status", token); @@ -254,6 +284,8 @@ public async Task CopyLedgerTransaction(ICollection enti await writer.WriteNullAsync(token); await writer.WriteNullAsync(token); await writer.WriteNullAsync(token); + await writer.WriteNullAsync(token); + await writer.WriteNullAsync(token); break; case UserLedgerTransaction ult: await writer.WriteAsync(ult.PayloadHash, NpgsqlDbType.Text, token); @@ -261,12 +293,12 @@ public async Task CopyLedgerTransaction(ICollection enti await writer.WriteAsync(ult.SignedIntentHash, NpgsqlDbType.Text, token); await writer.WriteAsync(ult.Message, NpgsqlDbType.Jsonb, token); await writer.WriteAsync(ult.RawPayload, NpgsqlDbType.Bytea, token); + await writer.WriteAsync(ult.ManifestInstructions, NpgsqlDbType.Text, token); + await writer.WriteAsync(ult.ManifestClasses, "ledger_transaction_manifest_class[]", token); break; default: throw new ArgumentOutOfRangeException(nameof(lt), lt, null); } - - await writer.WriteAsync(lt.BalanceChanges, NpgsqlDbType.Jsonb, token); } await writer.CompleteAsync(token); @@ -287,7 +319,7 @@ public async Task CopyLedgerTransactionMarkers(ICollection CopyEntityMetadataHistory(ICollection CopyPackageBlueprintAggregateHistory(ICollection entities, CancellationToken token) - { - if (!entities.Any()) - { - return 0; - } - - var sw = Stopwatch.GetTimestamp(); - - await using var writer = await _connection.BeginBinaryImportAsync("COPY package_blueprint_aggregate_history (id, from_state_version, package_entity_id, package_blueprint_ids) FROM STDIN (FORMAT BINARY)", token); - - foreach (var e in entities) - { - await writer.StartRowAsync(token); - await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.PackageEntityId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.PackageBlueprintIds.ToArray(), NpgsqlDbType.Array | NpgsqlDbType.Bigint, token); - } - - await writer.CompleteAsync(token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyEntityMetadataAggregateHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); - - return entities.Count; - } - - public async Task CopyPackageCodeAggregateHistory(ICollection entities, CancellationToken token) - { - if (!entities.Any()) - { - return 0; - } - - var sw = Stopwatch.GetTimestamp(); - - await using var writer = await _connection.BeginBinaryImportAsync("COPY package_code_aggregate_history (id, from_state_version, package_entity_id, package_code_ids) FROM STDIN (FORMAT BINARY)", token); - - foreach (var e in entities) - { - await writer.StartRowAsync(token); - await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.PackageEntityId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.PackageCodeIds.ToArray(), NpgsqlDbType.Array | NpgsqlDbType.Bigint, token); - } - - await writer.CompleteAsync(token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyEntityMetadataAggregateHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); - - return entities.Count; - } - public async Task CopyEntityMetadataAggregateHistory(ICollection entities, CancellationToken token) { if (!entities.Any()) @@ -457,145 +453,6 @@ public async Task CopyEntityMetadataAggregateHistory(ICollection CopyEntityRoleAssignmentsOwnerRoleHistory(List entities, CancellationToken token) - { - if (!entities.Any()) - { - return 0; - } - - var sw = Stopwatch.GetTimestamp(); - - await using var writer = - await _connection.BeginBinaryImportAsync("COPY entity_role_assignments_owner_role_history (id, from_state_version, entity_id, role_assignments) FROM STDIN (FORMAT BINARY)", token); - - foreach (var e in entities) - { - await writer.StartRowAsync(token); - await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.RoleAssignments, NpgsqlDbType.Jsonb, token); - } - - await writer.CompleteAsync(token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyEntityRoleAssignmentsOwnerRoleHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); - - return entities.Count; - } - - public async Task CopyEntityRoleAssignmentsRulesEntryHistory(List entities, CancellationToken token) - { - if (!entities.Any()) - { - return 0; - } - - var sw = Stopwatch.GetTimestamp(); - - await using var writer = - await _connection.BeginBinaryImportAsync( - "COPY entity_role_assignments_entry_history (id, from_state_version, entity_id, key_role, key_module, role_assignments, is_deleted) FROM STDIN (FORMAT BINARY)", token); - - foreach (var e in entities) - { - await writer.StartRowAsync(token); - await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.KeyRole, NpgsqlDbType.Text, token); - await writer.WriteAsync(e.KeyModule, "module_id", token); - await writer.WriteAsync(e.RoleAssignments, NpgsqlDbType.Jsonb, token); - await writer.WriteAsync(e.IsDeleted, NpgsqlDbType.Boolean, token); - } - - await writer.CompleteAsync(token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyEntityRoleAssignmentsRulesEntryHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); - - return entities.Count; - } - - public async Task CopyEntityRoleAssignmentsAggregateHistory(List entities, CancellationToken token) - { - if (!entities.Any()) - { - return 0; - } - - var sw = Stopwatch.GetTimestamp(); - - await using var writer = - await _connection.BeginBinaryImportAsync("COPY entity_role_assignments_aggregate_history (id, from_state_version, entity_id, owner_role_id, entry_ids) FROM STDIN (FORMAT BINARY)", token); - - foreach (var e in entities) - { - await writer.StartRowAsync(token); - await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.OwnerRoleId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.EntryIds.ToArray(), NpgsqlDbType.Array | NpgsqlDbType.Bigint, token); - } - - await writer.CompleteAsync(token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyEntityRoleAssignmentsAggregateHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); - - return entities.Count; - } - - public async Task CopyStateHistory(ICollection entities, CancellationToken token) - { - if (!entities.Any()) - { - return 0; - } - - var sw = Stopwatch.GetTimestamp(); - - await using var writer = - await _connection.BeginBinaryImportAsync( - "COPY state_history (id, from_state_version, entity_id, discriminator, json_state, sbor_state, type_index, schema_hash, sbor_type_kind, schema_defining_entity_id) FROM STDIN (FORMAT BINARY)", - token); - - foreach (var e in entities) - { - await writer.StartRowAsync(token); - await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(GetDiscriminator(e.GetType()), "state_type", token); - - switch (e) - { - case JsonStateHistory jsonStateHistory: - await writer.WriteAsync(jsonStateHistory.JsonState, NpgsqlDbType.Jsonb, token); - await writer.WriteNullAsync(token); - await writer.WriteNullAsync(token); - await writer.WriteNullAsync(token); - await writer.WriteNullAsync(token); - await writer.WriteNullAsync(token); - break; - case SborStateHistory sborStateHistory: - await writer.WriteNullAsync(token); - await writer.WriteAsync(sborStateHistory.SborState, NpgsqlDbType.Bytea, token); - await writer.WriteAsync(sborStateHistory.TypeIndex, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(sborStateHistory.SchemaHash, NpgsqlDbType.Bytea, token); - await writer.WriteAsync(sborStateHistory.SborTypeKind, "sbor_type_kind", token); - await writer.WriteAsync(sborStateHistory.SchemaDefiningEntityId, NpgsqlDbType.Bigint, token); - break; - } - } - - await writer.CompleteAsync(token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyStateHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); - - return entities.Count; - } - public async Task CopyValidatorKeyHistory(ICollection entities, CancellationToken token) { if (!entities.Any()) @@ -838,37 +695,6 @@ await _connection.BeginBinaryImportAsync( return entities.Count; } - public async Task CopyComponentMethodRoyalties(List entities, CancellationToken token) - { - if (!entities.Any()) - { - return 0; - } - - var sw = Stopwatch.GetTimestamp(); - - await using var writer = - await _connection.BeginBinaryImportAsync( - "COPY component_method_royalty_entry_history (id, from_state_version, entity_id, method_name, royalty_amount, is_locked) FROM STDIN (FORMAT BINARY)", token); - - foreach (var e in entities) - { - await writer.StartRowAsync(token); - await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.MethodName, NpgsqlDbType.Text, token); - await writer.WriteAsync(e.RoyaltyAmount, NpgsqlDbType.Jsonb, token); - await writer.WriteAsync(e.IsLocked, NpgsqlDbType.Boolean, token); - } - - await writer.CompleteAsync(token); - - await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyComponentMethodRoyalties), Stopwatch.GetElapsedTime(sw), entities.Count)); - - return entities.Count; - } - public async Task CopyAccountDefaultDepositRuleHistory(List entities, CancellationToken token) { if (!entities.Any()) @@ -1077,7 +903,7 @@ public async Task CopyNonFungibleIdLocationHistory(List CopyPackageBlueprintHistory(ICollection entities, CancellationToken token) + public async Task CopySchemaHistory(ICollection entities, CancellationToken token) { if (!entities.Any()) { @@ -1087,64 +913,26 @@ public async Task CopyPackageBlueprintHistory(ICollection x.StageCompleted(nameof(CopyPackageBlueprintHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); - - return entities.Count; - } - - public async Task CopyPackageCodeHistory(ICollection entities, CancellationToken token) - { - if (!entities.Any()) - { - return 0; - } - - var sw = Stopwatch.GetTimestamp(); - - await using var writer = await _connection.BeginBinaryImportAsync("COPY package_code_history (id, from_state_version, package_entity_id, code_hash, code, vm_type, is_deleted) FROM STDIN (FORMAT BINARY)", token); + await _connection.BeginBinaryImportAsync("COPY schema_history (id, from_state_version, entity_id, schema_hash, schema) FROM STDIN (FORMAT BINARY)", token); foreach (var e in entities) { await writer.StartRowAsync(token); await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.PackageEntityId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.CodeHash, NpgsqlDbType.Bytea, token); - await writer.WriteAsync(e.Code, NpgsqlDbType.Bytea, token); - await writer.WriteAsync(e.VmType, "package_vm_type", token); - await writer.WriteAsync(e.IsDeleted, NpgsqlDbType.Boolean, token); + await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.SchemaHash, NpgsqlDbType.Bytea, token); + await writer.WriteAsync(e.Schema, NpgsqlDbType.Bytea, token); } await writer.CompleteAsync(token); - await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyPackageCodeHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); + await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopySchemaHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); return entities.Count; } - public async Task CopySchemaHistory(ICollection entities, CancellationToken token) + public async Task CopyKeyValueStoreEntryHistory(List entities, CancellationToken token) { if (!entities.Any()) { @@ -1154,26 +942,29 @@ public async Task CopySchemaHistory(ICollection entities, Ca var sw = Stopwatch.GetTimestamp(); await using var writer = - await _connection.BeginBinaryImportAsync("COPY schema_history (id, from_state_version, entity_id, schema_hash, schema) FROM STDIN (FORMAT BINARY)", token); + await _connection.BeginBinaryImportAsync( + "COPY key_value_store_entry_history (id, from_state_version, key_value_store_entity_id, key, value, is_deleted, is_locked) FROM STDIN (FORMAT BINARY)", token); foreach (var e in entities) { await writer.StartRowAsync(token); await writer.WriteAsync(e.Id, NpgsqlDbType.Bigint, token); await writer.WriteAsync(e.FromStateVersion, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.EntityId, NpgsqlDbType.Bigint, token); - await writer.WriteAsync(e.SchemaHash, NpgsqlDbType.Bytea, token); - await writer.WriteAsync(e.Schema, NpgsqlDbType.Bytea, token); + await writer.WriteAsync(e.KeyValueStoreEntityId, NpgsqlDbType.Bigint, token); + await writer.WriteAsync(e.Key.ToArray(), NpgsqlDbType.Bytea, token); + await writer.WriteNullableAsync(e.Value?.ToArray(), NpgsqlDbType.Bytea, token); + await writer.WriteAsync(e.IsDeleted, NpgsqlDbType.Boolean, token); + await writer.WriteAsync(e.IsLocked, NpgsqlDbType.Boolean, token); } await writer.CompleteAsync(token); - await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopySchemaHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); + await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyKeyValueStoreEntryHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); return entities.Count; } - public async Task CopyKeyValueStoreEntryHistory(List entities, CancellationToken token) + public async Task CopyKeyValueStoreAggregateHistory(ICollection entities, CancellationToken token) { if (!entities.Any()) { @@ -1182,9 +973,7 @@ public async Task CopyKeyValueStoreEntryHistory(List x.StageCompleted(nameof(CopyKeyValueStoreEntryHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); + await _observers.ForEachAsync(x => x.StageCompleted(nameof(CopyEntityMetadataAggregateHistory), Stopwatch.GetElapsedTime(sw), entities.Count)); return entities.Count; } @@ -1295,6 +1081,7 @@ public async Task UpdateSequences(SequencesHolder sequences, CancellationToken t setval('entity_role_assignments_entry_history_id_seq', @entityRoleAssignmentsEntryHistorySequence), setval('entity_role_assignments_owner_role_history_id_seq', @entityRoleAssignmentsOwnerRoleHistorySequence), setval('component_method_royalty_entry_history_id_seq', @componentMethodRoyaltyEntryHistorySequence), + setval('component_method_royalty_aggregate_history_id_seq', @componentMethodRoyaltyAggregateHistorySequence), setval('resource_entity_supply_history_id_seq', @resourceEntitySupplyHistorySequence), setval('non_fungible_id_data_id_seq', @nonFungibleIdDataSequence), setval('non_fungible_id_data_history_id_seq', @nonFungibleIdDataHistorySequence), @@ -1311,7 +1098,8 @@ public async Task UpdateSequences(SequencesHolder sequences, CancellationToken t setval('non_fungible_schema_history_id_seq', @NonFungibleSchemaHistorySequence), setval('key_value_store_schema_history_id_seq', @KeyValueSchemaHistorySequence), setval('package_blueprint_aggregate_history_id_seq', @packageBlueprintAggregateHistorySequence), - setval('package_code_aggregate_history_id_seq', @PackageCodeAggregateHistorySequence) + setval('package_code_aggregate_history_id_seq', @PackageCodeAggregateHistorySequence), + setval('key_value_store_aggregate_history_id_seq', @KeyValueStoreAggregateHistorySequence) ", parameters: new { @@ -1329,6 +1117,7 @@ public async Task UpdateSequences(SequencesHolder sequences, CancellationToken t entityRoleAssignmentsEntryHistorySequence = sequences.EntityRoleAssignmentsEntryHistorySequence, entityRoleAssignmentsOwnerRoleHistorySequence = sequences.EntityRoleAssignmentsOwnerRoleHistorySequence, componentMethodRoyaltyEntryHistorySequence = sequences.ComponentMethodRoyaltyEntryHistorySequence, + componentMethodRoyaltyAggregateHistorySequence = sequences.ComponentMethodRoyaltyAggregateHistorySequence, resourceEntitySupplyHistorySequence = sequences.ResourceEntitySupplyHistorySequence, nonFungibleIdDataSequence = sequences.NonFungibleIdDataSequence, nonFungibleIdDataHistorySequence = sequences.NonFungibleIdDataHistorySequence, @@ -1346,6 +1135,7 @@ public async Task UpdateSequences(SequencesHolder sequences, CancellationToken t keyValueSchemaHistorySequence = sequences.KeyValueSchemaHistorySequence, packageBlueprintAggregateHistorySequence = sequences.PackageBlueprintAggregateHistorySequence, packageCodeAggregateHistorySequence = sequences.PackageCodeAggregateHistorySequence, + keyValueStoreAggregateHistorySequence = sequences.KeyValueStoreAggregateHistorySequence, }, cancellationToken: token); @@ -1354,7 +1144,7 @@ public async Task UpdateSequences(SequencesHolder sequences, CancellationToken t await _observers.ForEachAsync(x => x.StageCompleted(nameof(UpdateSequences), Stopwatch.GetElapsedTime(sw), null)); } - private T GetDiscriminator(Type type) + internal T GetDiscriminator(Type type) { if (_model.FindEntityType(type)?.GetDiscriminatorValue() is not T discriminator) { diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20230922041840_InitialCreate.Designer.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20230922041840_InitialCreate.Designer.cs deleted file mode 100644 index fe5b63ade..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20230922041840_InitialCreate.Designer.cs +++ /dev/null @@ -1,2378 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -// -using System; -using System.Collections.Generic; -using System.Numerics; -using Microsoft.EntityFrameworkCore; -using Microsoft.EntityFrameworkCore.Infrastructure; -using Microsoft.EntityFrameworkCore.Migrations; -using Microsoft.EntityFrameworkCore.Storage.ValueConversion; -using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata; -using RadixDlt.NetworkGateway.Abstractions.Addressing; -using RadixDlt.NetworkGateway.Abstractions.Model; -using RadixDlt.NetworkGateway.PostgresIntegration; -using RadixDlt.NetworkGateway.PostgresIntegration.Models; - -#nullable disable - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations -{ - [DbContext(typeof(MigrationsDbContext))] - [Migration("20230922041840_InitialCreate")] - partial class InitialCreate - { - /// - protected override void BuildTargetModel(ModelBuilder modelBuilder) - { -#pragma warning disable 612, 618 - modelBuilder - .HasAnnotation("ProductVersion", "7.0.11") - .HasAnnotation("Relational:MaxIdentifierLength", 63); - - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_default_deposit_rule", new[] { "accept", "reject", "allow_existing" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_resource_preference_rule", new[] { "allowed", "disallowed" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "entity_type", new[] { "global_consensus_manager", "global_fungible_resource", "global_non_fungible_resource", "global_generic_component", "internal_generic_component", "global_account_component", "global_package", "internal_key_value_store", "internal_fungible_vault", "internal_non_fungible_vault", "global_validator", "global_access_controller", "global_identity", "global_one_resource_pool", "global_two_resource_pool", "global_multi_resource_pool", "global_transaction_tracker" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_event_type", new[] { "withdrawal", "deposit" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_operation_type", new[] { "resource_in_use", "account_deposited_into", "account_withdrawn_from" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_origin_type", new[] { "user", "epoch_change" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_type", new[] { "origin", "event", "manifest_address", "affected_global_entity" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_status", new[] { "succeeded", "failed" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_type", new[] { "genesis", "user", "round_update" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "module_id", new[] { "main", "metadata", "royalty", "role_assignment" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "non_fungible_id_type", new[] { "string", "integer", "bytes", "ruid" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "package_vm_type", new[] { "native", "scrypto_v1" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_intent_ledger_status", new[] { "unknown", "committed", "commit_pending", "permanent_rejection", "possible_to_commit", "likely_but_not_certain_rejection" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_payload_ledger_status", new[] { "unknown", "committed", "commit_pending", "clashing_commit", "permanently_rejected", "transiently_accepted", "transiently_rejected" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "public_key_type", new[] { "ecdsa_secp256k1", "eddsa_ed25519" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "resource_type", new[] { "fungible", "non_fungible" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "sbor_type_kind", new[] { "well_known", "schema_local" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "state_type", new[] { "json", "sbor" }); - NpgsqlModelBuilderExtensions.UseIdentityByDefaultColumns(modelBuilder); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountDefaultDepositRuleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AccountEntityId") - .HasColumnType("bigint") - .HasColumnName("account_entity_id"); - - b.Property("DefaultDepositRule") - .HasColumnType("account_default_deposit_rule") - .HasColumnName("default_deposit_rule"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.HasKey("Id"); - - b.HasIndex("AccountEntityId", "FromStateVersion"); - - b.ToTable("account_default_deposit_rule_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountResourcePreferenceRuleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AccountEntityId") - .HasColumnType("bigint") - .HasColumnName("account_entity_id"); - - b.Property("AccountResourcePreferenceRule") - .HasColumnType("account_resource_preference_rule") - .HasColumnName("account_resource_preference_rule"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("AccountEntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("account_resource_preference_rule_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("MethodName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("method_name"); - - b.Property("RoyaltyAmount") - .HasColumnType("jsonb") - .HasColumnName("royalty_amount"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.HasIndex("EntityId", "MethodName", "FromStateVersion"); - - b.ToTable("component_method_royalty_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Address") - .IsRequired() - .HasColumnType("text") - .HasColumnName("address"); - - b.Property>("AncestorIds") - .HasColumnType("bigint[]") - .HasColumnName("ancestor_ids"); - - b.Property>("CorrelatedEntities") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("correlated_entities"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("GlobalAncestorId") - .HasColumnType("bigint") - .HasColumnName("global_ancestor_id"); - - b.Property("IsGlobal") - .HasColumnType("boolean") - .HasColumnName("is_global"); - - b.Property("OwnerAncestorId") - .HasColumnType("bigint") - .HasColumnName("owner_ancestor_id"); - - b.Property("ParentAncestorId") - .HasColumnType("bigint") - .HasColumnName("parent_ancestor_id"); - - b.Property("discriminator") - .HasColumnType("entity_type"); - - b.HasKey("Id"); - - b.HasIndex("Address") - .IsUnique(); - - b.HasIndex("FromStateVersion") - .HasFilter("discriminator = 'global_validator'"); - - b.ToTable("entities"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("MetadataIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("metadata_ids"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_metadata_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("Key") - .IsRequired() - .HasColumnType("text") - .HasColumnName("key"); - - b.Property("Value") - .HasColumnType("bytea") - .HasColumnName("value"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "Key", "FromStateVersion"); - - b.ToTable("entity_metadata_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("FungibleResourceEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("fungible_resource_entity_ids"); - - b.Property>("FungibleResourceSignificantUpdateStateVersions") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("fungible_resource_significant_update_state_versions"); - - b.Property>("NonFungibleResourceEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_resource_entity_ids"); - - b.Property>("NonFungibleResourceSignificantUpdateStateVersions") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_resource_significant_update_state_versions"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_resource_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("discriminator") - .HasColumnType("resource_type"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceVaultAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property>("VaultEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("vault_entity_ids"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("entity_resource_vault_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property>("EntryIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("entry_ids"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("OwnerRoleId") - .HasColumnType("bigint") - .HasColumnName("owner_role_id"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_role_assignments_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("KeyModule") - .HasColumnType("module_id") - .HasColumnName("key_module"); - - b.Property("KeyRole") - .IsRequired() - .HasColumnType("text") - .HasColumnName("key_role"); - - b.Property("RoleAssignments") - .HasColumnType("jsonb") - .HasColumnName("role_assignments"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "KeyRole", "KeyModule", "FromStateVersion"); - - b.ToTable("entity_role_assignments_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsOwnerRoleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("RoleAssignments") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("role_assignments"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_role_assignments_owner_role_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("GlobalEntityId") - .HasColumnType("bigint") - .HasColumnName("global_entity_id"); - - b.Property("OwnerEntityId") - .HasColumnType("bigint") - .HasColumnName("owner_entity_id"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("VaultEntityId") - .HasColumnType("bigint") - .HasColumnName("vault_entity_id"); - - b.Property("discriminator") - .HasColumnType("resource_type"); - - b.HasKey("Id"); - - b.HasIndex("GlobalEntityId", "FromStateVersion") - .HasFilter("is_royalty_vault = true"); - - b.HasIndex("OwnerEntityId", "FromStateVersion") - .HasFilter("is_royalty_vault = true"); - - b.HasIndex("VaultEntityId", "FromStateVersion") - .HasFilter("discriminator = 'non_fungible'"); - - b.HasIndex("GlobalEntityId", "VaultEntityId", "FromStateVersion"); - - b.HasIndex("Id", "ResourceEntityId", "FromStateVersion"); - - b.HasIndex("OwnerEntityId", "VaultEntityId", "FromStateVersion"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("Key") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key"); - - b.Property("KeyValueStoreEntityId") - .HasColumnType("bigint") - .HasColumnName("key_value_store_entity_id"); - - b.Property("Value") - .HasColumnType("bytea") - .HasColumnName("value"); - - b.HasKey("Id"); - - b.HasIndex("KeyValueStoreEntityId", "Key", "FromStateVersion"); - - b.ToTable("key_value_store_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreSchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("KeySborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("key_sbor_type_kind"); - - b.Property("KeySchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("key_schema_defining_entity_id"); - - b.Property("KeySchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key_schema_hash"); - - b.Property("KeyTypeIndex") - .HasColumnType("bigint") - .HasColumnName("key_type_index"); - - b.Property("KeyValueStoreEntityId") - .HasColumnType("bigint") - .HasColumnName("key_value_store_entity_id"); - - b.Property("ValueSborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("value_sbor_type_kind"); - - b.Property("ValueSchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("value_schema_defining_entity_id"); - - b.Property("ValueSchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("value_schema_hash"); - - b.Property("ValueTypeIndex") - .HasColumnType("bigint") - .HasColumnName("value_type_index"); - - b.HasKey("Id"); - - b.HasIndex("KeyValueStoreEntityId", "FromStateVersion"); - - b.ToTable("key_value_store_schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction", b => - { - b.Property("StateVersion") - .HasColumnType("bigint") - .HasColumnName("state_version"); - - b.Property("AffectedGlobalEntities") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("affected_global_entities"); - - b.Property("CreatedTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("created_timestamp"); - - b.Property("Epoch") - .HasColumnType("bigint") - .HasColumnName("epoch"); - - b.Property("FeePaid") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("fee_paid"); - - b.Property("IndexInEpoch") - .HasColumnType("bigint") - .HasColumnName("index_in_epoch"); - - b.Property("IndexInRound") - .HasColumnType("bigint") - .HasColumnName("index_in_round"); - - b.Property("NormalizedRoundTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("normalized_round_timestamp"); - - b.Property("RoundInEpoch") - .HasColumnType("bigint") - .HasColumnName("round_in_epoch"); - - b.Property("RoundTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("round_timestamp"); - - b.Property("TipPaid") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("tip_paid"); - - b.Property("discriminator") - .HasColumnType("ledger_transaction_type"); - - b.HasKey("StateVersion"); - - b.HasIndex("RoundTimestamp"); - - b.HasIndex("Epoch", "RoundInEpoch") - .IsUnique() - .HasFilter("index_in_round = 0"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("StateVersion") - .HasColumnType("bigint") - .HasColumnName("state_version"); - - b.Property("discriminator") - .HasColumnType("ledger_transaction_marker_type"); - - b.HasKey("Id"); - - b.HasIndex("StateVersion"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NetworkConfiguration", b => - { - b.Property("Id") - .HasColumnType("integer") - .HasColumnName("id"); - - b.Property("AddressTypeDefinitions") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("address_type_definitions"); - - b.Property("GenesisEpoch") - .HasColumnType("bigint") - .HasColumnName("genesis_epoch"); - - b.Property("GenesisRound") - .HasColumnType("bigint") - .HasColumnName("genesis_round"); - - b.Property("HrpDefinition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("hrp_definition"); - - b.Property("NetworkId") - .HasColumnType("smallint") - .HasColumnName("network_id"); - - b.Property("NetworkName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("network_name"); - - b.Property("WellKnownAddresses") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("well_known_addresses"); - - b.HasKey("Id"); - - b.ToTable("network_configuration"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdData", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("NonFungibleId") - .IsRequired() - .HasColumnType("text") - .HasColumnName("non_fungible_id"); - - b.Property("NonFungibleResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleResourceEntityId", "FromStateVersion"); - - b.HasIndex("NonFungibleResourceEntityId", "NonFungibleId", "FromStateVersion") - .IsUnique(); - - b.ToTable("non_fungible_id_data"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdDataHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Data") - .HasColumnType("bytea") - .HasColumnName("data"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("NonFungibleIdDataId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_id_data_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleIdDataId", "FromStateVersion"); - - b.ToTable("non_fungible_id_data_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdLocationHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("NonFungibleIdDataId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_id_data_id"); - - b.Property("VaultEntityId") - .HasColumnType("bigint") - .HasColumnName("vault_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleIdDataId", "FromStateVersion"); - - b.ToTable("non_fungible_id_location_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdStoreHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("NonFungibleIdDataIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_id_data_ids"); - - b.Property("NonFungibleResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleResourceEntityId", "FromStateVersion"); - - b.ToTable("non_fungible_id_store_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleSchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("SborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("sbor_type_kind"); - - b.Property("SchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("schema_defining_entity_id"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.Property("TypeIndex") - .HasColumnType("bigint") - .HasColumnName("type_index"); - - b.HasKey("Id"); - - b.HasIndex("ResourceEntityId", "FromStateVersion"); - - b.ToTable("non_fungible_schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageBlueprintHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AuthTemplate") - .HasColumnType("jsonb") - .HasColumnName("auth_template"); - - b.Property("AuthTemplateIsLocked") - .HasColumnType("boolean") - .HasColumnName("auth_template_is_locked"); - - b.Property("Definition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("definition"); - - b.Property>("DependantEntityIds") - .HasColumnType("bigint[]") - .HasColumnName("dependant_entity_ids"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Name") - .IsRequired() - .HasColumnType("text") - .HasColumnName("name"); - - b.Property("PackageEntityId") - .HasColumnType("bigint") - .HasColumnName("package_entity_id"); - - b.Property("RoyaltyConfig") - .HasColumnType("jsonb") - .HasColumnName("royalty_config"); - - b.Property("RoyaltyConfigIsLocked") - .HasColumnType("boolean") - .HasColumnName("royalty_config_is_locked"); - - b.Property("Version") - .IsRequired() - .HasColumnType("text") - .HasColumnName("version"); - - b.HasKey("Id"); - - b.HasIndex("PackageEntityId", "FromStateVersion"); - - b.HasIndex("PackageEntityId", "Name", "Version", "FromStateVersion"); - - b.ToTable("package_blueprint_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageCodeHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Code") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("code"); - - b.Property("CodeHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("code_hash"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("PackageEntityId") - .HasColumnType("bigint") - .HasColumnName("package_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("PackageEntityId", "FromStateVersion"); - - b.ToTable("package_code_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EndEpochExclusive") - .HasColumnType("numeric(20,0)") - .HasColumnName("end_epoch_exclusive"); - - b.Property("IntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("intent_hash"); - - b.Property("PayloadHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("payload_hash"); - - b.Property("PayloadId") - .HasColumnType("bigint") - .HasColumnName("payload_id"); - - b.Property("VersionControl") - .IsConcurrencyToken() - .ValueGeneratedOnAddOrUpdate() - .HasColumnType("xid") - .HasColumnName("xmin"); - - b.HasKey("Id"); - - b.HasIndex("IntentHash"); - - b.HasIndex("PayloadHash") - .IsUnique(); - - b.HasIndex("PayloadId"); - - b.ToTable("pending_transactions"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("NotarizedTransactionBlob") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("notarized_transaction_blob"); - - b.HasKey("Id"); - - b.ToTable("pending_transaction_payloads"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ResourceEntitySupplyHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("TotalBurned") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_burned"); - - b.Property("TotalMinted") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_minted"); - - b.Property("TotalSupply") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_supply"); - - b.HasKey("Id"); - - b.HasIndex("ResourceEntityId", "FromStateVersion"); - - b.ToTable("resource_entity_supply_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Schema") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.HasIndex("SchemaHash", "FromStateVersion"); - - b.ToTable("schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("discriminator") - .HasColumnType("state_type"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("state_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Epoch") - .HasColumnType("bigint") - .HasColumnName("epoch"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Stake") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("stake"); - - b.Property("ValidatorPublicKeyHistoryId") - .HasColumnType("bigint") - .HasColumnName("validator_public_key_history_id"); - - b.HasKey("Id"); - - b.HasIndex("Epoch"); - - b.HasIndex("FromStateVersion"); - - b.HasIndex("ValidatorPublicKeyHistoryId"); - - b.ToTable("validator_active_set_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorEmissionStatistics", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EpochNumber") - .HasColumnType("bigint") - .HasColumnName("epoch_number"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ProposalsMade") - .HasColumnType("bigint") - .HasColumnName("proposals_made"); - - b.Property("ProposalsMissed") - .HasColumnType("bigint") - .HasColumnName("proposals_missed"); - - b.Property("ValidatorEntityId") - .HasColumnType("bigint") - .HasColumnName("validator_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("ValidatorEntityId", "EpochNumber"); - - b.ToTable("validator_emission_statistics"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Key") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key"); - - b.Property("KeyType") - .HasColumnType("public_key_type") - .HasColumnName("key_type"); - - b.Property("ValidatorEntityId") - .HasColumnType("bigint") - .HasColumnName("validator_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("ValidatorEntityId", "FromStateVersion"); - - b.HasIndex("ValidatorEntityId", "KeyType", "Key"); - - b.ToTable("validator_public_key_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccessControllerEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalAccessController); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccountEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalAccountComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalConsensusManager", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalConsensusManager); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalFungibleResourceEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("Divisibility") - .HasColumnType("integer") - .HasColumnName("divisibility"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalFungibleResource); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalGenericComponentEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalGenericComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalIdentityEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalIdentity); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalMultiResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalMultiResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalNonFungibleResourceEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("NonFungibleIdType") - .HasColumnType("non_fungible_id_type") - .HasColumnName("non_fungible_id_type"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalNonFungibleResource); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalOneResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalOneResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalPackageEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("VmType") - .HasColumnType("package_vm_type") - .HasColumnName("vm_type"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalPackage); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTransactionTrackerEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalTransactionTracker); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTwoResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalTwoResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalValidatorEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("LockedOwnerStakeUnitVault") - .HasColumnType("bigint") - .HasColumnName("locked_owner_stake_unit_vault_entity_id"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("PendingOwnerStakeUnitUnlockVault") - .HasColumnType("bigint") - .HasColumnName("pending_owner_stake_unit_unlock_vault_entity_id"); - - b.Property("PendingXrdWithdrawVault") - .HasColumnType("bigint") - .HasColumnName("pending_xrd_withdraw_vault_entity_id"); - - b.Property("StakeVaultEntityId") - .HasColumnType("bigint") - .HasColumnName("stake_vault_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalValidator); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalFungibleVaultEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("ResourceEntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("RoyaltyVaultOfEntityId") - .HasColumnType("bigint") - .HasColumnName("royalty_vault_of_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalFungibleVault); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalGenericComponentEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalGenericComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalKeyValueStoreEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalKeyValueStore); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalNonFungibleVaultEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("ResourceEntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalNonFungibleVault); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleResourceAggregatedVaultsHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); - - b.Property("Balance") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("balance"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator().HasValue(ResourceType.Fungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleResourceAggregatedVaultsHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); - - b.Property("TotalCount") - .HasColumnType("bigint") - .HasColumnName("total_count"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator().HasValue(ResourceType.NonFungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleVaultHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); - - b.Property("Balance") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("balance"); - - b.Property("IsRoyaltyVault") - .HasColumnType("boolean") - .HasColumnName("is_royalty_vault"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator().HasValue(ResourceType.Fungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleVaultHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); - - b.Property>("NonFungibleIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_ids"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator().HasValue(ResourceType.NonFungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GenesisLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.Genesis); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.RoundUpdateLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.RoundUpdate); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.UserLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.Property("IntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("intent_hash"); - - b.Property("Message") - .HasColumnType("jsonb") - .HasColumnName("message"); - - b.Property("PayloadHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("payload_hash"); - - b.Property("RawPayload") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("raw_payload"); - - b.Property("SignedIntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("signed_intent_hash"); - - b.HasIndex("IntentHash") - .HasFilter("intent_hash IS NOT NULL"); - - NpgsqlIndexBuilderExtensions.HasMethod(b.HasIndex("IntentHash"), "hash"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.User); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AffectedGlobalEntityTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.HasIndex("EntityId", "StateVersion") - .HasFilter("discriminator = 'affected_global_entity'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.AffectedGlobalEntity); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EventLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("EventType") - .HasColumnType("ledger_transaction_marker_event_type") - .HasColumnName("event_type"); - - b.Property("Quantity") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("quantity"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.HasIndex("EventType", "EntityId", "StateVersion") - .HasFilter("discriminator = 'event'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Event); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ManifestAddressLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("OperationType") - .HasColumnType("ledger_transaction_marker_operation_type") - .HasColumnName("operation_type"); - - b.HasIndex("OperationType", "EntityId", "StateVersion") - .HasFilter("discriminator = 'manifest_address'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestAddress); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.OriginLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("OriginType") - .HasColumnType("ledger_transaction_marker_origin_type") - .HasColumnName("origin_type"); - - b.HasIndex("OriginType", "StateVersion") - .HasFilter("discriminator = 'origin'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Origin); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.JsonStateHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); - - b.Property("JsonState") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("json_state"); - - b.ToTable("state_history"); - - b.HasDiscriminator().HasValue(StateType.Json); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SborStateHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); - - b.Property("SborState") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("sbor_state"); - - b.Property("SborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("sbor_type_kind"); - - b.Property("SchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("schema_defining_entity_id"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.Property("TypeIndex") - .HasColumnType("bigint") - .HasColumnName("type_index"); - - b.ToTable("state_history"); - - b.HasDiscriminator().HasValue(StateType.Sbor); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction", b => - { - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerHashes", "LedgerHashes", b1 => - { - b1.Property("LedgerTransactionStateVersion") - .HasColumnType("bigint"); - - b1.Property("ReceiptTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("receipt_tree_hash"); - - b1.Property("StateTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("state_tree_hash"); - - b1.Property("TransactionTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("transaction_tree_hash"); - - b1.HasKey("LedgerTransactionStateVersion"); - - b1.ToTable("ledger_transactions"); - - b1.WithOwner() - .HasForeignKey("LedgerTransactionStateVersion"); - }); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.TransactionReceipt", "EngineReceipt", b1 => - { - b1.Property("LedgerTransactionStateVersion") - .HasColumnType("bigint"); - - b1.Property("CostingParameters") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_costing_parameters"); - - b1.Property("ErrorMessage") - .HasColumnType("text") - .HasColumnName("receipt_error_message"); - - b1.Property("FeeDestination") - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_destination"); - - b1.Property("FeeSource") - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_source"); - - b1.Property("FeeSummary") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_summary"); - - b1.Property("NextEpoch") - .HasColumnType("jsonb") - .HasColumnName("receipt_next_epoch"); - - b1.Property("Output") - .HasColumnType("jsonb") - .HasColumnName("receipt_output"); - - b1.Property("StateUpdates") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_state_updates"); - - b1.Property("Status") - .HasColumnType("ledger_transaction_status") - .HasColumnName("receipt_status"); - - b1.HasKey("LedgerTransactionStateVersion"); - - b1.ToTable("ledger_transactions"); - - b1.WithOwner() - .HasForeignKey("LedgerTransactionStateVersion"); - - b1.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.ReceiptEvents", "Events", b2 => - { - b2.Property("TransactionReceiptLedgerTransactionStateVersion") - .HasColumnType("bigint"); - - b2.Property("Emitters") - .IsRequired() - .HasColumnType("jsonb[]") - .HasColumnName("receipt_event_emitters"); - - b2.Property("Names") - .IsRequired() - .HasColumnType("text[]") - .HasColumnName("receipt_event_names"); - - b2.Property("SborTypeKinds") - .IsRequired() - .HasColumnType("sbor_type_kind[]") - .HasColumnName("receipt_event_sbor_type_kinds"); - - b2.Property("Sbors") - .IsRequired() - .HasColumnType("bytea[]") - .HasColumnName("receipt_event_sbors"); - - b2.Property("SchemaEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("receipt_event_schema_entity_ids"); - - b2.Property("SchemaHashes") - .IsRequired() - .HasColumnType("bytea[]") - .HasColumnName("receipt_event_schema_hashes"); - - b2.Property("TypeIndexes") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("receipt_event_type_indexes"); - - b2.HasKey("TransactionReceiptLedgerTransactionStateVersion"); - - b2.ToTable("ledger_transactions"); - - b2.WithOwner() - .HasForeignKey("TransactionReceiptLedgerTransactionStateVersion"); - }); - - b1.Navigation("Events") - .IsRequired(); - }); - - b.Navigation("EngineReceipt") - .IsRequired(); - - b.Navigation("LedgerHashes") - .IsRequired(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", "Payload") - .WithMany() - .HasForeignKey("PayloadId") - .OnDelete(DeleteBehavior.Cascade) - .IsRequired(); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionGatewayHandling", "GatewayHandling", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("AttemptedSubmissionToNodesCount") - .HasColumnType("integer") - .HasColumnName("node_submission_count"); - - b1.Property("FirstSubmittedToGatewayTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("first_submitted_to_gateway_timestamp"); - - b1.Property("HandlingStatusReason") - .HasColumnType("text") - .HasColumnName("handling_status_reason"); - - b1.Property("ResubmitFromTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("resubmit_from_timestamp"); - - b1.HasKey("PendingTransactionId"); - - b1.HasIndex("FirstSubmittedToGatewayTimestamp"); - - b1.HasIndex("ResubmitFromTimestamp"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionLedgerDetails", "LedgerDetails", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("CommitTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("commit_timestamp"); - - b1.Property("InitialRejectionReason") - .HasColumnType("text") - .HasColumnName("initial_rejection_reason"); - - b1.Property("IntentLedgerStatus") - .HasColumnType("pending_transaction_intent_ledger_status") - .HasColumnName("intent_status"); - - b1.Property("LatestRejectionReason") - .HasColumnType("text") - .HasColumnName("latest_rejection_reason"); - - b1.Property("LatestRejectionTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("latest_rejection_timestamp"); - - b1.Property("PayloadLedgerStatus") - .HasColumnType("pending_transaction_payload_ledger_status") - .HasColumnName("payload_status"); - - b1.HasKey("PendingTransactionId"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionNetworkDetails", "NetworkDetails", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("LastSubmitErrorTitle") - .HasColumnType("text") - .HasColumnName("last_submit_error"); - - b1.Property("LatestNodeSubmissionTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("latest_node_submission_timestamp"); - - b1.Property("LatestNodeSubmissionWasAccepted") - .HasColumnType("boolean") - .HasColumnName("latest_node_submission_was_accepted"); - - b1.Property("LatestSubmittedToNodeName") - .HasColumnType("text") - .HasColumnName("latest_submitted_to_node_name"); - - b1.HasKey("PendingTransactionId"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.Navigation("GatewayHandling") - .IsRequired(); - - b.Navigation("LedgerDetails") - .IsRequired(); - - b.Navigation("NetworkDetails") - .IsRequired(); - - b.Navigation("Payload"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => - { - b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", "PublicKey") - .WithMany() - .HasForeignKey("ValidatorPublicKeyHistoryId") - .OnDelete(DeleteBehavior.Cascade) - .IsRequired(); - - b.Navigation("PublicKey"); - }); -#pragma warning restore 612, 618 - } - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231101101154_InversePendingTransactionPayloadRelationship.Designer.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231101101154_InversePendingTransactionPayloadRelationship.Designer.cs deleted file mode 100644 index a7c89111b..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231101101154_InversePendingTransactionPayloadRelationship.Designer.cs +++ /dev/null @@ -1,2339 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -// -using System; -using System.Collections.Generic; -using System.Numerics; -using Microsoft.EntityFrameworkCore; -using Microsoft.EntityFrameworkCore.Infrastructure; -using Microsoft.EntityFrameworkCore.Migrations; -using Microsoft.EntityFrameworkCore.Storage.ValueConversion; -using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata; -using RadixDlt.NetworkGateway.Abstractions.Addressing; -using RadixDlt.NetworkGateway.Abstractions.Model; -using RadixDlt.NetworkGateway.PostgresIntegration; -using RadixDlt.NetworkGateway.PostgresIntegration.Models; - -#nullable disable - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations -{ - [DbContext(typeof(MigrationsDbContext))] - [Migration("20231101101154_InversePendingTransactionPayloadRelationship")] - partial class InversePendingTransactionPayloadRelationship - { - /// - protected override void BuildTargetModel(ModelBuilder modelBuilder) - { -#pragma warning disable 612, 618 - modelBuilder - .HasAnnotation("ProductVersion", "7.0.11") - .HasAnnotation("Relational:MaxIdentifierLength", 63); - - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_default_deposit_rule", new[] { "accept", "reject", "allow_existing" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_resource_preference_rule", new[] { "allowed", "disallowed" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "entity_type", new[] { "global_consensus_manager", "global_fungible_resource", "global_non_fungible_resource", "global_generic_component", "internal_generic_component", "global_account_component", "global_package", "internal_key_value_store", "internal_fungible_vault", "internal_non_fungible_vault", "global_validator", "global_access_controller", "global_identity", "global_one_resource_pool", "global_two_resource_pool", "global_multi_resource_pool", "global_transaction_tracker" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_event_type", new[] { "withdrawal", "deposit" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_operation_type", new[] { "resource_in_use", "account_deposited_into", "account_withdrawn_from" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_origin_type", new[] { "user", "epoch_change" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_type", new[] { "origin", "event", "manifest_address", "affected_global_entity" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_status", new[] { "succeeded", "failed" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_type", new[] { "genesis", "user", "round_update" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "module_id", new[] { "main", "metadata", "royalty", "role_assignment" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "non_fungible_id_type", new[] { "string", "integer", "bytes", "ruid" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "package_vm_type", new[] { "native", "scrypto_v1" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_intent_ledger_status", new[] { "unknown", "committed", "commit_pending", "permanent_rejection", "possible_to_commit", "likely_but_not_certain_rejection" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_payload_ledger_status", new[] { "unknown", "committed", "commit_pending", "clashing_commit", "permanently_rejected", "transiently_accepted", "transiently_rejected" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "public_key_type", new[] { "ecdsa_secp256k1", "eddsa_ed25519" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "resource_type", new[] { "fungible", "non_fungible" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "sbor_type_kind", new[] { "well_known", "schema_local" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "state_type", new[] { "json", "sbor" }); - NpgsqlModelBuilderExtensions.UseIdentityByDefaultColumns(modelBuilder); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountDefaultDepositRuleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AccountEntityId") - .HasColumnType("bigint") - .HasColumnName("account_entity_id"); - - b.Property("DefaultDepositRule") - .HasColumnType("account_default_deposit_rule") - .HasColumnName("default_deposit_rule"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.HasKey("Id"); - - b.HasIndex("AccountEntityId", "FromStateVersion"); - - b.ToTable("account_default_deposit_rule_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountResourcePreferenceRuleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AccountEntityId") - .HasColumnType("bigint") - .HasColumnName("account_entity_id"); - - b.Property("AccountResourcePreferenceRule") - .HasColumnType("account_resource_preference_rule") - .HasColumnName("account_resource_preference_rule"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("AccountEntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("account_resource_preference_rule_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("MethodName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("method_name"); - - b.Property("RoyaltyAmount") - .HasColumnType("jsonb") - .HasColumnName("royalty_amount"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.HasIndex("EntityId", "MethodName", "FromStateVersion"); - - b.ToTable("component_method_royalty_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Address") - .IsRequired() - .HasColumnType("text") - .HasColumnName("address"); - - b.Property>("AncestorIds") - .HasColumnType("bigint[]") - .HasColumnName("ancestor_ids"); - - b.Property>("CorrelatedEntities") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("correlated_entities"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("GlobalAncestorId") - .HasColumnType("bigint") - .HasColumnName("global_ancestor_id"); - - b.Property("IsGlobal") - .HasColumnType("boolean") - .HasColumnName("is_global"); - - b.Property("OwnerAncestorId") - .HasColumnType("bigint") - .HasColumnName("owner_ancestor_id"); - - b.Property("ParentAncestorId") - .HasColumnType("bigint") - .HasColumnName("parent_ancestor_id"); - - b.Property("discriminator") - .HasColumnType("entity_type"); - - b.HasKey("Id"); - - b.HasIndex("Address") - .IsUnique(); - - b.HasIndex("FromStateVersion") - .HasFilter("discriminator = 'global_validator'"); - - b.ToTable("entities"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("MetadataIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("metadata_ids"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_metadata_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("Key") - .IsRequired() - .HasColumnType("text") - .HasColumnName("key"); - - b.Property("Value") - .HasColumnType("bytea") - .HasColumnName("value"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "Key", "FromStateVersion"); - - b.ToTable("entity_metadata_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("FungibleResourceEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("fungible_resource_entity_ids"); - - b.Property>("FungibleResourceSignificantUpdateStateVersions") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("fungible_resource_significant_update_state_versions"); - - b.Property>("NonFungibleResourceEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_resource_entity_ids"); - - b.Property>("NonFungibleResourceSignificantUpdateStateVersions") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_resource_significant_update_state_versions"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_resource_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("discriminator") - .HasColumnType("resource_type"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceVaultAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property>("VaultEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("vault_entity_ids"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("entity_resource_vault_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property>("EntryIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("entry_ids"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("OwnerRoleId") - .HasColumnType("bigint") - .HasColumnName("owner_role_id"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_role_assignments_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("KeyModule") - .HasColumnType("module_id") - .HasColumnName("key_module"); - - b.Property("KeyRole") - .IsRequired() - .HasColumnType("text") - .HasColumnName("key_role"); - - b.Property("RoleAssignments") - .HasColumnType("jsonb") - .HasColumnName("role_assignments"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "KeyRole", "KeyModule", "FromStateVersion"); - - b.ToTable("entity_role_assignments_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsOwnerRoleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("RoleAssignments") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("role_assignments"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_role_assignments_owner_role_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("GlobalEntityId") - .HasColumnType("bigint") - .HasColumnName("global_entity_id"); - - b.Property("OwnerEntityId") - .HasColumnType("bigint") - .HasColumnName("owner_entity_id"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("VaultEntityId") - .HasColumnType("bigint") - .HasColumnName("vault_entity_id"); - - b.Property("discriminator") - .HasColumnType("resource_type"); - - b.HasKey("Id"); - - b.HasIndex("GlobalEntityId", "FromStateVersion") - .HasFilter("is_royalty_vault = true"); - - b.HasIndex("OwnerEntityId", "FromStateVersion") - .HasFilter("is_royalty_vault = true"); - - b.HasIndex("VaultEntityId", "FromStateVersion") - .HasFilter("discriminator = 'non_fungible'"); - - b.HasIndex("GlobalEntityId", "VaultEntityId", "FromStateVersion"); - - b.HasIndex("Id", "ResourceEntityId", "FromStateVersion"); - - b.HasIndex("OwnerEntityId", "VaultEntityId", "FromStateVersion"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("Key") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key"); - - b.Property("KeyValueStoreEntityId") - .HasColumnType("bigint") - .HasColumnName("key_value_store_entity_id"); - - b.Property("Value") - .HasColumnType("bytea") - .HasColumnName("value"); - - b.HasKey("Id"); - - b.HasIndex("KeyValueStoreEntityId", "Key", "FromStateVersion"); - - b.ToTable("key_value_store_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreSchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("KeySborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("key_sbor_type_kind"); - - b.Property("KeySchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("key_schema_defining_entity_id"); - - b.Property("KeySchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key_schema_hash"); - - b.Property("KeyTypeIndex") - .HasColumnType("bigint") - .HasColumnName("key_type_index"); - - b.Property("KeyValueStoreEntityId") - .HasColumnType("bigint") - .HasColumnName("key_value_store_entity_id"); - - b.Property("ValueSborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("value_sbor_type_kind"); - - b.Property("ValueSchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("value_schema_defining_entity_id"); - - b.Property("ValueSchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("value_schema_hash"); - - b.Property("ValueTypeIndex") - .HasColumnType("bigint") - .HasColumnName("value_type_index"); - - b.HasKey("Id"); - - b.HasIndex("KeyValueStoreEntityId", "FromStateVersion"); - - b.ToTable("key_value_store_schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction", b => - { - b.Property("StateVersion") - .HasColumnType("bigint") - .HasColumnName("state_version"); - - b.Property("AffectedGlobalEntities") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("affected_global_entities"); - - b.Property("CreatedTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("created_timestamp"); - - b.Property("Epoch") - .HasColumnType("bigint") - .HasColumnName("epoch"); - - b.Property("FeePaid") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("fee_paid"); - - b.Property("IndexInEpoch") - .HasColumnType("bigint") - .HasColumnName("index_in_epoch"); - - b.Property("IndexInRound") - .HasColumnType("bigint") - .HasColumnName("index_in_round"); - - b.Property("NormalizedRoundTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("normalized_round_timestamp"); - - b.Property("ReceiptCostingParameters") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_costing_parameters"); - - b.Property("ReceiptErrorMessage") - .HasColumnType("text") - .HasColumnName("receipt_error_message"); - - b.Property("ReceiptEventEmitters") - .IsRequired() - .HasColumnType("jsonb[]") - .HasColumnName("receipt_event_emitters"); - - b.Property("ReceiptEventNames") - .IsRequired() - .HasColumnType("text[]") - .HasColumnName("receipt_event_names"); - - b.Property("ReceiptEventSborTypeKinds") - .IsRequired() - .HasColumnType("sbor_type_kind[]") - .HasColumnName("receipt_event_sbor_type_kinds"); - - b.Property("ReceiptEventSbors") - .IsRequired() - .HasColumnType("bytea[]") - .HasColumnName("receipt_event_sbors"); - - b.Property("ReceiptEventSchemaEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("receipt_event_schema_entity_ids"); - - b.Property("ReceiptEventSchemaHashes") - .IsRequired() - .HasColumnType("bytea[]") - .HasColumnName("receipt_event_schema_hashes"); - - b.Property("ReceiptEventTypeIndexes") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("receipt_event_type_indexes"); - - b.Property("ReceiptFeeDestination") - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_destination"); - - b.Property("ReceiptFeeSource") - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_source"); - - b.Property("ReceiptFeeSummary") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_summary"); - - b.Property("ReceiptNextEpoch") - .HasColumnType("jsonb") - .HasColumnName("receipt_next_epoch"); - - b.Property("ReceiptOutput") - .HasColumnType("jsonb") - .HasColumnName("receipt_output"); - - b.Property("ReceiptStateUpdates") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_state_updates"); - - b.Property("ReceiptStatus") - .HasColumnType("ledger_transaction_status") - .HasColumnName("receipt_status"); - - b.Property("ReceiptTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("receipt_tree_hash"); - - b.Property("RoundInEpoch") - .HasColumnType("bigint") - .HasColumnName("round_in_epoch"); - - b.Property("RoundTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("round_timestamp"); - - b.Property("StateTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("state_tree_hash"); - - b.Property("TipPaid") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("tip_paid"); - - b.Property("TransactionTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("transaction_tree_hash"); - - b.Property("discriminator") - .HasColumnType("ledger_transaction_type"); - - b.HasKey("StateVersion"); - - b.HasIndex("RoundTimestamp"); - - b.HasIndex("Epoch", "RoundInEpoch") - .IsUnique() - .HasFilter("index_in_round = 0"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("StateVersion") - .HasColumnType("bigint") - .HasColumnName("state_version"); - - b.Property("discriminator") - .HasColumnType("ledger_transaction_marker_type"); - - b.HasKey("Id"); - - b.HasIndex("StateVersion"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NetworkConfiguration", b => - { - b.Property("Id") - .HasColumnType("integer") - .HasColumnName("id"); - - b.Property("AddressTypeDefinitions") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("address_type_definitions"); - - b.Property("GenesisEpoch") - .HasColumnType("bigint") - .HasColumnName("genesis_epoch"); - - b.Property("GenesisRound") - .HasColumnType("bigint") - .HasColumnName("genesis_round"); - - b.Property("HrpDefinition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("hrp_definition"); - - b.Property("NetworkId") - .HasColumnType("smallint") - .HasColumnName("network_id"); - - b.Property("NetworkName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("network_name"); - - b.Property("WellKnownAddresses") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("well_known_addresses"); - - b.HasKey("Id"); - - b.ToTable("network_configuration"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdData", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("NonFungibleId") - .IsRequired() - .HasColumnType("text") - .HasColumnName("non_fungible_id"); - - b.Property("NonFungibleResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleResourceEntityId", "FromStateVersion"); - - b.HasIndex("NonFungibleResourceEntityId", "NonFungibleId", "FromStateVersion") - .IsUnique(); - - b.ToTable("non_fungible_id_data"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdDataHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Data") - .HasColumnType("bytea") - .HasColumnName("data"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("NonFungibleIdDataId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_id_data_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleIdDataId", "FromStateVersion"); - - b.ToTable("non_fungible_id_data_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdLocationHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("NonFungibleIdDataId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_id_data_id"); - - b.Property("VaultEntityId") - .HasColumnType("bigint") - .HasColumnName("vault_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleIdDataId", "FromStateVersion"); - - b.ToTable("non_fungible_id_location_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdStoreHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("NonFungibleIdDataIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_id_data_ids"); - - b.Property("NonFungibleResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleResourceEntityId", "FromStateVersion"); - - b.ToTable("non_fungible_id_store_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleSchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("SborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("sbor_type_kind"); - - b.Property("SchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("schema_defining_entity_id"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.Property("TypeIndex") - .HasColumnType("bigint") - .HasColumnName("type_index"); - - b.HasKey("Id"); - - b.HasIndex("ResourceEntityId", "FromStateVersion"); - - b.ToTable("non_fungible_schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageBlueprintHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AuthTemplate") - .HasColumnType("jsonb") - .HasColumnName("auth_template"); - - b.Property("AuthTemplateIsLocked") - .HasColumnType("boolean") - .HasColumnName("auth_template_is_locked"); - - b.Property("Definition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("definition"); - - b.Property>("DependantEntityIds") - .HasColumnType("bigint[]") - .HasColumnName("dependant_entity_ids"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Name") - .IsRequired() - .HasColumnType("text") - .HasColumnName("name"); - - b.Property("PackageEntityId") - .HasColumnType("bigint") - .HasColumnName("package_entity_id"); - - b.Property("RoyaltyConfig") - .HasColumnType("jsonb") - .HasColumnName("royalty_config"); - - b.Property("RoyaltyConfigIsLocked") - .HasColumnType("boolean") - .HasColumnName("royalty_config_is_locked"); - - b.Property("Version") - .IsRequired() - .HasColumnType("text") - .HasColumnName("version"); - - b.HasKey("Id"); - - b.HasIndex("PackageEntityId", "FromStateVersion"); - - b.HasIndex("PackageEntityId", "Name", "Version", "FromStateVersion"); - - b.ToTable("package_blueprint_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageCodeHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Code") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("code"); - - b.Property("CodeHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("code_hash"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("PackageEntityId") - .HasColumnType("bigint") - .HasColumnName("package_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("PackageEntityId", "FromStateVersion"); - - b.ToTable("package_code_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EndEpochExclusive") - .HasColumnType("numeric(20,0)") - .HasColumnName("end_epoch_exclusive"); - - b.Property("IntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("intent_hash"); - - b.Property("PayloadHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("payload_hash"); - - b.Property("PayloadId") - .HasColumnType("bigint") - .HasColumnName("payload_id"); - - b.Property("VersionControl") - .IsConcurrencyToken() - .ValueGeneratedOnAddOrUpdate() - .HasColumnType("xid") - .HasColumnName("xmin"); - - b.HasKey("Id"); - - b.HasIndex("IntentHash"); - - b.HasIndex("PayloadHash") - .IsUnique(); - - b.ToTable("pending_transactions"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("NotarizedTransactionBlob") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("notarized_transaction_blob"); - - b.Property("PendingTransactionId") - .HasColumnType("bigint") - .HasColumnName("pending_transaction_id"); - - b.HasKey("Id"); - - b.HasIndex("PendingTransactionId") - .IsUnique(); - - b.ToTable("pending_transaction_payloads"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ResourceEntitySupplyHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("TotalBurned") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_burned"); - - b.Property("TotalMinted") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_minted"); - - b.Property("TotalSupply") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_supply"); - - b.HasKey("Id"); - - b.HasIndex("ResourceEntityId", "FromStateVersion"); - - b.ToTable("resource_entity_supply_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Schema") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.HasIndex("SchemaHash", "FromStateVersion"); - - b.ToTable("schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("discriminator") - .HasColumnType("state_type"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("state_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Epoch") - .HasColumnType("bigint") - .HasColumnName("epoch"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Stake") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("stake"); - - b.Property("ValidatorPublicKeyHistoryId") - .HasColumnType("bigint") - .HasColumnName("validator_public_key_history_id"); - - b.HasKey("Id"); - - b.HasIndex("Epoch"); - - b.HasIndex("FromStateVersion"); - - b.HasIndex("ValidatorPublicKeyHistoryId"); - - b.ToTable("validator_active_set_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorEmissionStatistics", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EpochNumber") - .HasColumnType("bigint") - .HasColumnName("epoch_number"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ProposalsMade") - .HasColumnType("bigint") - .HasColumnName("proposals_made"); - - b.Property("ProposalsMissed") - .HasColumnType("bigint") - .HasColumnName("proposals_missed"); - - b.Property("ValidatorEntityId") - .HasColumnType("bigint") - .HasColumnName("validator_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("ValidatorEntityId", "EpochNumber"); - - b.ToTable("validator_emission_statistics"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Key") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key"); - - b.Property("KeyType") - .HasColumnType("public_key_type") - .HasColumnName("key_type"); - - b.Property("ValidatorEntityId") - .HasColumnType("bigint") - .HasColumnName("validator_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("ValidatorEntityId", "FromStateVersion"); - - b.HasIndex("ValidatorEntityId", "KeyType", "Key"); - - b.ToTable("validator_public_key_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccessControllerEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalAccessController); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccountEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalAccountComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalConsensusManager", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalConsensusManager); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalFungibleResourceEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("Divisibility") - .HasColumnType("integer") - .HasColumnName("divisibility"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalFungibleResource); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalGenericComponentEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalGenericComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalIdentityEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalIdentity); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalMultiResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalMultiResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalNonFungibleResourceEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("NonFungibleIdType") - .HasColumnType("non_fungible_id_type") - .HasColumnName("non_fungible_id_type"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalNonFungibleResource); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalOneResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalOneResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalPackageEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("VmType") - .HasColumnType("package_vm_type") - .HasColumnName("vm_type"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalPackage); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTransactionTrackerEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalTransactionTracker); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTwoResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalTwoResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalValidatorEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("LockedOwnerStakeUnitVault") - .HasColumnType("bigint") - .HasColumnName("locked_owner_stake_unit_vault_entity_id"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("PendingOwnerStakeUnitUnlockVault") - .HasColumnType("bigint") - .HasColumnName("pending_owner_stake_unit_unlock_vault_entity_id"); - - b.Property("PendingXrdWithdrawVault") - .HasColumnType("bigint") - .HasColumnName("pending_xrd_withdraw_vault_entity_id"); - - b.Property("StakeVaultEntityId") - .HasColumnType("bigint") - .HasColumnName("stake_vault_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalValidator); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalFungibleVaultEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("ResourceEntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("RoyaltyVaultOfEntityId") - .HasColumnType("bigint") - .HasColumnName("royalty_vault_of_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalFungibleVault); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalGenericComponentEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalGenericComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalKeyValueStoreEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalKeyValueStore); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalNonFungibleVaultEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("ResourceEntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalNonFungibleVault); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleResourceAggregatedVaultsHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); - - b.Property("Balance") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("balance"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator().HasValue(ResourceType.Fungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleResourceAggregatedVaultsHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); - - b.Property("TotalCount") - .HasColumnType("bigint") - .HasColumnName("total_count"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator().HasValue(ResourceType.NonFungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleVaultHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); - - b.Property("Balance") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("balance"); - - b.Property("IsRoyaltyVault") - .HasColumnType("boolean") - .HasColumnName("is_royalty_vault"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator().HasValue(ResourceType.Fungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleVaultHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); - - b.Property>("NonFungibleIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_ids"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator().HasValue(ResourceType.NonFungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GenesisLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.Genesis); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.RoundUpdateLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.RoundUpdate); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.UserLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.Property("IntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("intent_hash"); - - b.Property("Message") - .HasColumnType("jsonb") - .HasColumnName("message"); - - b.Property("PayloadHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("payload_hash"); - - b.Property("RawPayload") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("raw_payload"); - - b.Property("SignedIntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("signed_intent_hash"); - - b.HasIndex("IntentHash") - .HasFilter("intent_hash IS NOT NULL"); - - NpgsqlIndexBuilderExtensions.HasMethod(b.HasIndex("IntentHash"), "hash"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.User); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AffectedGlobalEntityTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.HasIndex("EntityId", "StateVersion") - .HasFilter("discriminator = 'affected_global_entity'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.AffectedGlobalEntity); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EventLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("EventType") - .HasColumnType("ledger_transaction_marker_event_type") - .HasColumnName("event_type"); - - b.Property("Quantity") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("quantity"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.HasIndex("EventType", "EntityId", "StateVersion") - .HasFilter("discriminator = 'event'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Event); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ManifestAddressLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("OperationType") - .HasColumnType("ledger_transaction_marker_operation_type") - .HasColumnName("operation_type"); - - b.HasIndex("OperationType", "EntityId", "StateVersion") - .HasFilter("discriminator = 'manifest_address'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestAddress); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.OriginLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("OriginType") - .HasColumnType("ledger_transaction_marker_origin_type") - .HasColumnName("origin_type"); - - b.HasIndex("OriginType", "StateVersion") - .HasFilter("discriminator = 'origin'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Origin); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.JsonStateHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); - - b.Property("JsonState") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("json_state"); - - b.ToTable("state_history"); - - b.HasDiscriminator().HasValue(StateType.Json); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SborStateHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); - - b.Property("SborState") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("sbor_state"); - - b.Property("SborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("sbor_type_kind"); - - b.Property("SchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("schema_defining_entity_id"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.Property("TypeIndex") - .HasColumnType("bigint") - .HasColumnName("type_index"); - - b.ToTable("state_history"); - - b.HasDiscriminator().HasValue(StateType.Sbor); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionGatewayHandling", "GatewayHandling", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("AttemptedSubmissionToNodesCount") - .HasColumnType("integer") - .HasColumnName("node_submission_count"); - - b1.Property("FirstSubmittedToGatewayTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("first_submitted_to_gateway_timestamp"); - - b1.Property("HandlingStatusReason") - .HasColumnType("text") - .HasColumnName("handling_status_reason"); - - b1.Property("ResubmitFromTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("resubmit_from_timestamp"); - - b1.HasKey("PendingTransactionId"); - - b1.HasIndex("FirstSubmittedToGatewayTimestamp"); - - b1.HasIndex("ResubmitFromTimestamp"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionLedgerDetails", "LedgerDetails", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("CommitTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("commit_timestamp"); - - b1.Property("InitialRejectionReason") - .HasColumnType("text") - .HasColumnName("initial_rejection_reason"); - - b1.Property("IntentLedgerStatus") - .HasColumnType("pending_transaction_intent_ledger_status") - .HasColumnName("intent_status"); - - b1.Property("LatestRejectionReason") - .HasColumnType("text") - .HasColumnName("latest_rejection_reason"); - - b1.Property("LatestRejectionTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("latest_rejection_timestamp"); - - b1.Property("PayloadLedgerStatus") - .HasColumnType("pending_transaction_payload_ledger_status") - .HasColumnName("payload_status"); - - b1.HasKey("PendingTransactionId"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionNetworkDetails", "NetworkDetails", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("LastSubmitErrorTitle") - .HasColumnType("text") - .HasColumnName("last_submit_error"); - - b1.Property("LatestNodeSubmissionTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("latest_node_submission_timestamp"); - - b1.Property("LatestNodeSubmissionWasAccepted") - .HasColumnType("boolean") - .HasColumnName("latest_node_submission_was_accepted"); - - b1.Property("LatestSubmittedToNodeName") - .HasColumnType("text") - .HasColumnName("latest_submitted_to_node_name"); - - b1.HasKey("PendingTransactionId"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.Navigation("GatewayHandling") - .IsRequired(); - - b.Navigation("LedgerDetails") - .IsRequired(); - - b.Navigation("NetworkDetails") - .IsRequired(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", b => - { - b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", "PendingTransaction") - .WithOne("Payload") - .HasForeignKey("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", "PendingTransactionId") - .OnDelete(DeleteBehavior.Cascade); - - b.Navigation("PendingTransaction"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => - { - b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", "PublicKey") - .WithMany() - .HasForeignKey("ValidatorPublicKeyHistoryId") - .OnDelete(DeleteBehavior.Cascade) - .IsRequired(); - - b.Navigation("PublicKey"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.Navigation("Payload"); - }); -#pragma warning restore 612, 618 - } - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231101101154_InversePendingTransactionPayloadRelationship.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231101101154_InversePendingTransactionPayloadRelationship.cs deleted file mode 100644 index edb828d59..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231101101154_InversePendingTransactionPayloadRelationship.cs +++ /dev/null @@ -1,156 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using Microsoft.EntityFrameworkCore.Migrations; - -#nullable disable - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations -{ - /// - public partial class InversePendingTransactionPayloadRelationship : Migration - { - /// - protected override void Up(MigrationBuilder migrationBuilder) - { - migrationBuilder.DropForeignKey( - name: "FK_pending_transactions_pending_transaction_payloads_payload_id", - table: "pending_transactions"); - - migrationBuilder.DropIndex( - name: "IX_pending_transactions_payload_id", - table: "pending_transactions"); - - migrationBuilder.AlterColumn( - name: "payload_id", - table: "pending_transactions", - type: "bigint", - nullable: true, - oldClrType: typeof(long), - oldType: "bigint"); - - migrationBuilder.AddColumn( - name: "pending_transaction_id", - table: "pending_transaction_payloads", - type: "bigint", - nullable: true); - - migrationBuilder.CreateIndex( - name: "IX_pending_transaction_payloads_pending_transaction_id", - table: "pending_transaction_payloads", - column: "pending_transaction_id", - unique: true); - - migrationBuilder.AddForeignKey( - name: "FK_pending_transaction_payloads_pending_transactions_pending_t~", - table: "pending_transaction_payloads", - column: "pending_transaction_id", - principalTable: "pending_transactions", - principalColumn: "id", - onDelete: ReferentialAction.Cascade); - - migrationBuilder.Sql("UPDATE pending_transaction_payloads ptp SET pending_transaction_id = pt.id FROM pending_transactions pt WHERE pt.payload_id = ptp.id;"); - migrationBuilder.Sql("DELETE FROM pending_transaction_payloads WHERE id IN (SELECT ptp.id FROM pending_transaction_payloads ptp LEFT JOIN pending_transactions pt ON ptp.id = pt.payload_id WHERE pt.id IS NULL);"); - } - - /// - protected override void Down(MigrationBuilder migrationBuilder) - { - migrationBuilder.DropForeignKey( - name: "FK_pending_transaction_payloads_pending_transactions_pending_t~", - table: "pending_transaction_payloads"); - - migrationBuilder.DropIndex( - name: "IX_pending_transaction_payloads_pending_transaction_id", - table: "pending_transaction_payloads"); - - migrationBuilder.DropColumn( - name: "pending_transaction_id", - table: "pending_transaction_payloads"); - - migrationBuilder.AlterColumn( - name: "payload_id", - table: "pending_transactions", - type: "bigint", - nullable: false, - defaultValue: 0L, - oldClrType: typeof(long), - oldType: "bigint", - oldNullable: true); - - migrationBuilder.CreateIndex( - name: "IX_pending_transactions_payload_id", - table: "pending_transactions", - column: "payload_id"); - - migrationBuilder.AddForeignKey( - name: "FK_pending_transactions_pending_transaction_payloads_payload_id", - table: "pending_transactions", - column: "payload_id", - principalTable: "pending_transaction_payloads", - principalColumn: "id", - onDelete: ReferentialAction.Cascade); - } - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231122094710_AddLedgerTransactionBalanceChanges.Designer.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231122094710_AddLedgerTransactionBalanceChanges.Designer.cs deleted file mode 100644 index 2518437a7..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231122094710_AddLedgerTransactionBalanceChanges.Designer.cs +++ /dev/null @@ -1,2343 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -// -using System; -using System.Collections.Generic; -using System.Numerics; -using Microsoft.EntityFrameworkCore; -using Microsoft.EntityFrameworkCore.Infrastructure; -using Microsoft.EntityFrameworkCore.Migrations; -using Microsoft.EntityFrameworkCore.Storage.ValueConversion; -using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata; -using RadixDlt.NetworkGateway.Abstractions.Addressing; -using RadixDlt.NetworkGateway.Abstractions.Model; -using RadixDlt.NetworkGateway.PostgresIntegration; -using RadixDlt.NetworkGateway.PostgresIntegration.Models; - -#nullable disable - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations -{ - [DbContext(typeof(MigrationsDbContext))] - [Migration("20231122094710_AddLedgerTransactionBalanceChanges")] - partial class AddLedgerTransactionBalanceChanges - { - /// - protected override void BuildTargetModel(ModelBuilder modelBuilder) - { -#pragma warning disable 612, 618 - modelBuilder - .HasAnnotation("ProductVersion", "7.0.11") - .HasAnnotation("Relational:MaxIdentifierLength", 63); - - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_default_deposit_rule", new[] { "accept", "reject", "allow_existing" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_resource_preference_rule", new[] { "allowed", "disallowed" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "entity_type", new[] { "global_consensus_manager", "global_fungible_resource", "global_non_fungible_resource", "global_generic_component", "internal_generic_component", "global_account_component", "global_package", "internal_key_value_store", "internal_fungible_vault", "internal_non_fungible_vault", "global_validator", "global_access_controller", "global_identity", "global_one_resource_pool", "global_two_resource_pool", "global_multi_resource_pool", "global_transaction_tracker" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_event_type", new[] { "withdrawal", "deposit" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_operation_type", new[] { "resource_in_use", "account_deposited_into", "account_withdrawn_from" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_origin_type", new[] { "user", "epoch_change" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_type", new[] { "origin", "event", "manifest_address", "affected_global_entity" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_status", new[] { "succeeded", "failed" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_type", new[] { "genesis", "user", "round_update" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "module_id", new[] { "main", "metadata", "royalty", "role_assignment" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "non_fungible_id_type", new[] { "string", "integer", "bytes", "ruid" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "package_vm_type", new[] { "native", "scrypto_v1" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_intent_ledger_status", new[] { "unknown", "committed", "commit_pending", "permanent_rejection", "possible_to_commit", "likely_but_not_certain_rejection" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_payload_ledger_status", new[] { "unknown", "committed", "commit_pending", "clashing_commit", "permanently_rejected", "transiently_accepted", "transiently_rejected" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "public_key_type", new[] { "ecdsa_secp256k1", "eddsa_ed25519" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "resource_type", new[] { "fungible", "non_fungible" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "sbor_type_kind", new[] { "well_known", "schema_local" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "state_type", new[] { "json", "sbor" }); - NpgsqlModelBuilderExtensions.UseIdentityByDefaultColumns(modelBuilder); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountDefaultDepositRuleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AccountEntityId") - .HasColumnType("bigint") - .HasColumnName("account_entity_id"); - - b.Property("DefaultDepositRule") - .HasColumnType("account_default_deposit_rule") - .HasColumnName("default_deposit_rule"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.HasKey("Id"); - - b.HasIndex("AccountEntityId", "FromStateVersion"); - - b.ToTable("account_default_deposit_rule_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountResourcePreferenceRuleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AccountEntityId") - .HasColumnType("bigint") - .HasColumnName("account_entity_id"); - - b.Property("AccountResourcePreferenceRule") - .HasColumnType("account_resource_preference_rule") - .HasColumnName("account_resource_preference_rule"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("AccountEntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("account_resource_preference_rule_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("MethodName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("method_name"); - - b.Property("RoyaltyAmount") - .HasColumnType("jsonb") - .HasColumnName("royalty_amount"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.HasIndex("EntityId", "MethodName", "FromStateVersion"); - - b.ToTable("component_method_royalty_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Address") - .IsRequired() - .HasColumnType("text") - .HasColumnName("address"); - - b.Property>("AncestorIds") - .HasColumnType("bigint[]") - .HasColumnName("ancestor_ids"); - - b.Property>("CorrelatedEntities") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("correlated_entities"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("GlobalAncestorId") - .HasColumnType("bigint") - .HasColumnName("global_ancestor_id"); - - b.Property("IsGlobal") - .HasColumnType("boolean") - .HasColumnName("is_global"); - - b.Property("OwnerAncestorId") - .HasColumnType("bigint") - .HasColumnName("owner_ancestor_id"); - - b.Property("ParentAncestorId") - .HasColumnType("bigint") - .HasColumnName("parent_ancestor_id"); - - b.Property("discriminator") - .HasColumnType("entity_type"); - - b.HasKey("Id"); - - b.HasIndex("Address") - .IsUnique(); - - b.HasIndex("FromStateVersion") - .HasFilter("discriminator = 'global_validator'"); - - b.ToTable("entities"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("MetadataIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("metadata_ids"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_metadata_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("Key") - .IsRequired() - .HasColumnType("text") - .HasColumnName("key"); - - b.Property("Value") - .HasColumnType("bytea") - .HasColumnName("value"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "Key", "FromStateVersion"); - - b.ToTable("entity_metadata_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("FungibleResourceEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("fungible_resource_entity_ids"); - - b.Property>("FungibleResourceSignificantUpdateStateVersions") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("fungible_resource_significant_update_state_versions"); - - b.Property>("NonFungibleResourceEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_resource_entity_ids"); - - b.Property>("NonFungibleResourceSignificantUpdateStateVersions") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_resource_significant_update_state_versions"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_resource_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("discriminator") - .HasColumnType("resource_type"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceVaultAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property>("VaultEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("vault_entity_ids"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("entity_resource_vault_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property>("EntryIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("entry_ids"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("OwnerRoleId") - .HasColumnType("bigint") - .HasColumnName("owner_role_id"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_role_assignments_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("KeyModule") - .HasColumnType("module_id") - .HasColumnName("key_module"); - - b.Property("KeyRole") - .IsRequired() - .HasColumnType("text") - .HasColumnName("key_role"); - - b.Property("RoleAssignments") - .HasColumnType("jsonb") - .HasColumnName("role_assignments"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "KeyRole", "KeyModule", "FromStateVersion"); - - b.ToTable("entity_role_assignments_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsOwnerRoleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("RoleAssignments") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("role_assignments"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_role_assignments_owner_role_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("GlobalEntityId") - .HasColumnType("bigint") - .HasColumnName("global_entity_id"); - - b.Property("OwnerEntityId") - .HasColumnType("bigint") - .HasColumnName("owner_entity_id"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("VaultEntityId") - .HasColumnType("bigint") - .HasColumnName("vault_entity_id"); - - b.Property("discriminator") - .HasColumnType("resource_type"); - - b.HasKey("Id"); - - b.HasIndex("GlobalEntityId", "FromStateVersion") - .HasFilter("is_royalty_vault = true"); - - b.HasIndex("OwnerEntityId", "FromStateVersion") - .HasFilter("is_royalty_vault = true"); - - b.HasIndex("VaultEntityId", "FromStateVersion") - .HasFilter("discriminator = 'non_fungible'"); - - b.HasIndex("GlobalEntityId", "VaultEntityId", "FromStateVersion"); - - b.HasIndex("Id", "ResourceEntityId", "FromStateVersion"); - - b.HasIndex("OwnerEntityId", "VaultEntityId", "FromStateVersion"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("Key") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key"); - - b.Property("KeyValueStoreEntityId") - .HasColumnType("bigint") - .HasColumnName("key_value_store_entity_id"); - - b.Property("Value") - .HasColumnType("bytea") - .HasColumnName("value"); - - b.HasKey("Id"); - - b.HasIndex("KeyValueStoreEntityId", "Key", "FromStateVersion"); - - b.ToTable("key_value_store_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreSchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("KeySborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("key_sbor_type_kind"); - - b.Property("KeySchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("key_schema_defining_entity_id"); - - b.Property("KeySchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key_schema_hash"); - - b.Property("KeyTypeIndex") - .HasColumnType("bigint") - .HasColumnName("key_type_index"); - - b.Property("KeyValueStoreEntityId") - .HasColumnType("bigint") - .HasColumnName("key_value_store_entity_id"); - - b.Property("ValueSborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("value_sbor_type_kind"); - - b.Property("ValueSchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("value_schema_defining_entity_id"); - - b.Property("ValueSchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("value_schema_hash"); - - b.Property("ValueTypeIndex") - .HasColumnType("bigint") - .HasColumnName("value_type_index"); - - b.HasKey("Id"); - - b.HasIndex("KeyValueStoreEntityId", "FromStateVersion"); - - b.ToTable("key_value_store_schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction", b => - { - b.Property("StateVersion") - .HasColumnType("bigint") - .HasColumnName("state_version"); - - b.Property("AffectedGlobalEntities") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("affected_global_entities"); - - b.Property("BalanceChanges") - .HasColumnType("jsonb") - .HasColumnName("balance_changes"); - - b.Property("CreatedTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("created_timestamp"); - - b.Property("Epoch") - .HasColumnType("bigint") - .HasColumnName("epoch"); - - b.Property("FeePaid") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("fee_paid"); - - b.Property("IndexInEpoch") - .HasColumnType("bigint") - .HasColumnName("index_in_epoch"); - - b.Property("IndexInRound") - .HasColumnType("bigint") - .HasColumnName("index_in_round"); - - b.Property("NormalizedRoundTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("normalized_round_timestamp"); - - b.Property("ReceiptCostingParameters") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_costing_parameters"); - - b.Property("ReceiptErrorMessage") - .HasColumnType("text") - .HasColumnName("receipt_error_message"); - - b.Property("ReceiptEventEmitters") - .IsRequired() - .HasColumnType("jsonb[]") - .HasColumnName("receipt_event_emitters"); - - b.Property("ReceiptEventNames") - .IsRequired() - .HasColumnType("text[]") - .HasColumnName("receipt_event_names"); - - b.Property("ReceiptEventSborTypeKinds") - .IsRequired() - .HasColumnType("sbor_type_kind[]") - .HasColumnName("receipt_event_sbor_type_kinds"); - - b.Property("ReceiptEventSbors") - .IsRequired() - .HasColumnType("bytea[]") - .HasColumnName("receipt_event_sbors"); - - b.Property("ReceiptEventSchemaEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("receipt_event_schema_entity_ids"); - - b.Property("ReceiptEventSchemaHashes") - .IsRequired() - .HasColumnType("bytea[]") - .HasColumnName("receipt_event_schema_hashes"); - - b.Property("ReceiptEventTypeIndexes") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("receipt_event_type_indexes"); - - b.Property("ReceiptFeeDestination") - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_destination"); - - b.Property("ReceiptFeeSource") - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_source"); - - b.Property("ReceiptFeeSummary") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_summary"); - - b.Property("ReceiptNextEpoch") - .HasColumnType("jsonb") - .HasColumnName("receipt_next_epoch"); - - b.Property("ReceiptOutput") - .HasColumnType("jsonb") - .HasColumnName("receipt_output"); - - b.Property("ReceiptStateUpdates") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_state_updates"); - - b.Property("ReceiptStatus") - .HasColumnType("ledger_transaction_status") - .HasColumnName("receipt_status"); - - b.Property("ReceiptTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("receipt_tree_hash"); - - b.Property("RoundInEpoch") - .HasColumnType("bigint") - .HasColumnName("round_in_epoch"); - - b.Property("RoundTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("round_timestamp"); - - b.Property("StateTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("state_tree_hash"); - - b.Property("TipPaid") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("tip_paid"); - - b.Property("TransactionTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("transaction_tree_hash"); - - b.Property("discriminator") - .HasColumnType("ledger_transaction_type"); - - b.HasKey("StateVersion"); - - b.HasIndex("RoundTimestamp"); - - b.HasIndex("Epoch", "RoundInEpoch") - .IsUnique() - .HasFilter("index_in_round = 0"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("StateVersion") - .HasColumnType("bigint") - .HasColumnName("state_version"); - - b.Property("discriminator") - .HasColumnType("ledger_transaction_marker_type"); - - b.HasKey("Id"); - - b.HasIndex("StateVersion"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NetworkConfiguration", b => - { - b.Property("Id") - .HasColumnType("integer") - .HasColumnName("id"); - - b.Property("AddressTypeDefinitions") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("address_type_definitions"); - - b.Property("GenesisEpoch") - .HasColumnType("bigint") - .HasColumnName("genesis_epoch"); - - b.Property("GenesisRound") - .HasColumnType("bigint") - .HasColumnName("genesis_round"); - - b.Property("HrpDefinition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("hrp_definition"); - - b.Property("NetworkId") - .HasColumnType("smallint") - .HasColumnName("network_id"); - - b.Property("NetworkName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("network_name"); - - b.Property("WellKnownAddresses") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("well_known_addresses"); - - b.HasKey("Id"); - - b.ToTable("network_configuration"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdData", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("NonFungibleId") - .IsRequired() - .HasColumnType("text") - .HasColumnName("non_fungible_id"); - - b.Property("NonFungibleResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleResourceEntityId", "FromStateVersion"); - - b.HasIndex("NonFungibleResourceEntityId", "NonFungibleId", "FromStateVersion") - .IsUnique(); - - b.ToTable("non_fungible_id_data"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdDataHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Data") - .HasColumnType("bytea") - .HasColumnName("data"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("NonFungibleIdDataId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_id_data_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleIdDataId", "FromStateVersion"); - - b.ToTable("non_fungible_id_data_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdLocationHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("NonFungibleIdDataId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_id_data_id"); - - b.Property("VaultEntityId") - .HasColumnType("bigint") - .HasColumnName("vault_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleIdDataId", "FromStateVersion"); - - b.ToTable("non_fungible_id_location_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdStoreHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("NonFungibleIdDataIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_id_data_ids"); - - b.Property("NonFungibleResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleResourceEntityId", "FromStateVersion"); - - b.ToTable("non_fungible_id_store_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleSchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("SborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("sbor_type_kind"); - - b.Property("SchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("schema_defining_entity_id"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.Property("TypeIndex") - .HasColumnType("bigint") - .HasColumnName("type_index"); - - b.HasKey("Id"); - - b.HasIndex("ResourceEntityId", "FromStateVersion"); - - b.ToTable("non_fungible_schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageBlueprintHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AuthTemplate") - .HasColumnType("jsonb") - .HasColumnName("auth_template"); - - b.Property("AuthTemplateIsLocked") - .HasColumnType("boolean") - .HasColumnName("auth_template_is_locked"); - - b.Property("Definition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("definition"); - - b.Property>("DependantEntityIds") - .HasColumnType("bigint[]") - .HasColumnName("dependant_entity_ids"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Name") - .IsRequired() - .HasColumnType("text") - .HasColumnName("name"); - - b.Property("PackageEntityId") - .HasColumnType("bigint") - .HasColumnName("package_entity_id"); - - b.Property("RoyaltyConfig") - .HasColumnType("jsonb") - .HasColumnName("royalty_config"); - - b.Property("RoyaltyConfigIsLocked") - .HasColumnType("boolean") - .HasColumnName("royalty_config_is_locked"); - - b.Property("Version") - .IsRequired() - .HasColumnType("text") - .HasColumnName("version"); - - b.HasKey("Id"); - - b.HasIndex("PackageEntityId", "FromStateVersion"); - - b.HasIndex("PackageEntityId", "Name", "Version", "FromStateVersion"); - - b.ToTable("package_blueprint_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageCodeHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Code") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("code"); - - b.Property("CodeHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("code_hash"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("PackageEntityId") - .HasColumnType("bigint") - .HasColumnName("package_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("PackageEntityId", "FromStateVersion"); - - b.ToTable("package_code_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EndEpochExclusive") - .HasColumnType("numeric(20,0)") - .HasColumnName("end_epoch_exclusive"); - - b.Property("IntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("intent_hash"); - - b.Property("PayloadHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("payload_hash"); - - b.Property("PayloadId") - .HasColumnType("bigint") - .HasColumnName("payload_id"); - - b.Property("VersionControl") - .IsConcurrencyToken() - .ValueGeneratedOnAddOrUpdate() - .HasColumnType("xid") - .HasColumnName("xmin"); - - b.HasKey("Id"); - - b.HasIndex("IntentHash"); - - b.HasIndex("PayloadHash") - .IsUnique(); - - b.ToTable("pending_transactions"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("NotarizedTransactionBlob") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("notarized_transaction_blob"); - - b.Property("PendingTransactionId") - .HasColumnType("bigint") - .HasColumnName("pending_transaction_id"); - - b.HasKey("Id"); - - b.HasIndex("PendingTransactionId") - .IsUnique(); - - b.ToTable("pending_transaction_payloads"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ResourceEntitySupplyHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("TotalBurned") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_burned"); - - b.Property("TotalMinted") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_minted"); - - b.Property("TotalSupply") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_supply"); - - b.HasKey("Id"); - - b.HasIndex("ResourceEntityId", "FromStateVersion"); - - b.ToTable("resource_entity_supply_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Schema") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.HasIndex("SchemaHash", "FromStateVersion"); - - b.ToTable("schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("discriminator") - .HasColumnType("state_type"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("state_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Epoch") - .HasColumnType("bigint") - .HasColumnName("epoch"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Stake") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("stake"); - - b.Property("ValidatorPublicKeyHistoryId") - .HasColumnType("bigint") - .HasColumnName("validator_public_key_history_id"); - - b.HasKey("Id"); - - b.HasIndex("Epoch"); - - b.HasIndex("FromStateVersion"); - - b.HasIndex("ValidatorPublicKeyHistoryId"); - - b.ToTable("validator_active_set_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorEmissionStatistics", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EpochNumber") - .HasColumnType("bigint") - .HasColumnName("epoch_number"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ProposalsMade") - .HasColumnType("bigint") - .HasColumnName("proposals_made"); - - b.Property("ProposalsMissed") - .HasColumnType("bigint") - .HasColumnName("proposals_missed"); - - b.Property("ValidatorEntityId") - .HasColumnType("bigint") - .HasColumnName("validator_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("ValidatorEntityId", "EpochNumber"); - - b.ToTable("validator_emission_statistics"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Key") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key"); - - b.Property("KeyType") - .HasColumnType("public_key_type") - .HasColumnName("key_type"); - - b.Property("ValidatorEntityId") - .HasColumnType("bigint") - .HasColumnName("validator_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("ValidatorEntityId", "FromStateVersion"); - - b.HasIndex("ValidatorEntityId", "KeyType", "Key"); - - b.ToTable("validator_public_key_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccessControllerEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalAccessController); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccountEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalAccountComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalConsensusManager", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalConsensusManager); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalFungibleResourceEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("Divisibility") - .HasColumnType("integer") - .HasColumnName("divisibility"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalFungibleResource); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalGenericComponentEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalGenericComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalIdentityEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalIdentity); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalMultiResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalMultiResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalNonFungibleResourceEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("NonFungibleIdType") - .HasColumnType("non_fungible_id_type") - .HasColumnName("non_fungible_id_type"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalNonFungibleResource); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalOneResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalOneResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalPackageEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("VmType") - .HasColumnType("package_vm_type") - .HasColumnName("vm_type"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalPackage); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTransactionTrackerEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalTransactionTracker); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTwoResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalTwoResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalValidatorEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("LockedOwnerStakeUnitVault") - .HasColumnType("bigint") - .HasColumnName("locked_owner_stake_unit_vault_entity_id"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("PendingOwnerStakeUnitUnlockVault") - .HasColumnType("bigint") - .HasColumnName("pending_owner_stake_unit_unlock_vault_entity_id"); - - b.Property("PendingXrdWithdrawVault") - .HasColumnType("bigint") - .HasColumnName("pending_xrd_withdraw_vault_entity_id"); - - b.Property("StakeVaultEntityId") - .HasColumnType("bigint") - .HasColumnName("stake_vault_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalValidator); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalFungibleVaultEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("ResourceEntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("RoyaltyVaultOfEntityId") - .HasColumnType("bigint") - .HasColumnName("royalty_vault_of_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalFungibleVault); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalGenericComponentEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalGenericComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalKeyValueStoreEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalKeyValueStore); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalNonFungibleVaultEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("ResourceEntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalNonFungibleVault); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleResourceAggregatedVaultsHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); - - b.Property("Balance") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("balance"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator().HasValue(ResourceType.Fungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleResourceAggregatedVaultsHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); - - b.Property("TotalCount") - .HasColumnType("bigint") - .HasColumnName("total_count"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator().HasValue(ResourceType.NonFungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleVaultHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); - - b.Property("Balance") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("balance"); - - b.Property("IsRoyaltyVault") - .HasColumnType("boolean") - .HasColumnName("is_royalty_vault"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator().HasValue(ResourceType.Fungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleVaultHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); - - b.Property>("NonFungibleIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_ids"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator().HasValue(ResourceType.NonFungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GenesisLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.Genesis); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.RoundUpdateLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.RoundUpdate); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.UserLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.Property("IntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("intent_hash"); - - b.Property("Message") - .HasColumnType("jsonb") - .HasColumnName("message"); - - b.Property("PayloadHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("payload_hash"); - - b.Property("RawPayload") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("raw_payload"); - - b.Property("SignedIntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("signed_intent_hash"); - - b.HasIndex("IntentHash") - .HasFilter("intent_hash IS NOT NULL"); - - NpgsqlIndexBuilderExtensions.HasMethod(b.HasIndex("IntentHash"), "hash"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.User); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AffectedGlobalEntityTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.HasIndex("EntityId", "StateVersion") - .HasFilter("discriminator = 'affected_global_entity'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.AffectedGlobalEntity); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EventLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("EventType") - .HasColumnType("ledger_transaction_marker_event_type") - .HasColumnName("event_type"); - - b.Property("Quantity") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("quantity"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.HasIndex("EventType", "EntityId", "StateVersion") - .HasFilter("discriminator = 'event'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Event); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ManifestAddressLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("OperationType") - .HasColumnType("ledger_transaction_marker_operation_type") - .HasColumnName("operation_type"); - - b.HasIndex("OperationType", "EntityId", "StateVersion") - .HasFilter("discriminator = 'manifest_address'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestAddress); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.OriginLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("OriginType") - .HasColumnType("ledger_transaction_marker_origin_type") - .HasColumnName("origin_type"); - - b.HasIndex("OriginType", "StateVersion") - .HasFilter("discriminator = 'origin'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Origin); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.JsonStateHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); - - b.Property("JsonState") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("json_state"); - - b.ToTable("state_history"); - - b.HasDiscriminator().HasValue(StateType.Json); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SborStateHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); - - b.Property("SborState") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("sbor_state"); - - b.Property("SborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("sbor_type_kind"); - - b.Property("SchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("schema_defining_entity_id"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.Property("TypeIndex") - .HasColumnType("bigint") - .HasColumnName("type_index"); - - b.ToTable("state_history"); - - b.HasDiscriminator().HasValue(StateType.Sbor); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionGatewayHandling", "GatewayHandling", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("AttemptedSubmissionToNodesCount") - .HasColumnType("integer") - .HasColumnName("node_submission_count"); - - b1.Property("FirstSubmittedToGatewayTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("first_submitted_to_gateway_timestamp"); - - b1.Property("HandlingStatusReason") - .HasColumnType("text") - .HasColumnName("handling_status_reason"); - - b1.Property("ResubmitFromTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("resubmit_from_timestamp"); - - b1.HasKey("PendingTransactionId"); - - b1.HasIndex("FirstSubmittedToGatewayTimestamp"); - - b1.HasIndex("ResubmitFromTimestamp"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionLedgerDetails", "LedgerDetails", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("CommitTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("commit_timestamp"); - - b1.Property("InitialRejectionReason") - .HasColumnType("text") - .HasColumnName("initial_rejection_reason"); - - b1.Property("IntentLedgerStatus") - .HasColumnType("pending_transaction_intent_ledger_status") - .HasColumnName("intent_status"); - - b1.Property("LatestRejectionReason") - .HasColumnType("text") - .HasColumnName("latest_rejection_reason"); - - b1.Property("LatestRejectionTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("latest_rejection_timestamp"); - - b1.Property("PayloadLedgerStatus") - .HasColumnType("pending_transaction_payload_ledger_status") - .HasColumnName("payload_status"); - - b1.HasKey("PendingTransactionId"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionNetworkDetails", "NetworkDetails", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("LastSubmitErrorTitle") - .HasColumnType("text") - .HasColumnName("last_submit_error"); - - b1.Property("LatestNodeSubmissionTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("latest_node_submission_timestamp"); - - b1.Property("LatestNodeSubmissionWasAccepted") - .HasColumnType("boolean") - .HasColumnName("latest_node_submission_was_accepted"); - - b1.Property("LatestSubmittedToNodeName") - .HasColumnType("text") - .HasColumnName("latest_submitted_to_node_name"); - - b1.HasKey("PendingTransactionId"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.Navigation("GatewayHandling") - .IsRequired(); - - b.Navigation("LedgerDetails") - .IsRequired(); - - b.Navigation("NetworkDetails") - .IsRequired(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", b => - { - b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", "PendingTransaction") - .WithOne("Payload") - .HasForeignKey("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", "PendingTransactionId") - .OnDelete(DeleteBehavior.Cascade); - - b.Navigation("PendingTransaction"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => - { - b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", "PublicKey") - .WithMany() - .HasForeignKey("ValidatorPublicKeyHistoryId") - .OnDelete(DeleteBehavior.Cascade) - .IsRequired(); - - b.Navigation("PublicKey"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.Navigation("Payload"); - }); -#pragma warning restore 612, 618 - } - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231130132946_AddNetworkHrpSuffixToNetworkConfiguration.Designer.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231130132946_AddNetworkHrpSuffixToNetworkConfiguration.Designer.cs deleted file mode 100644 index d2add6540..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231130132946_AddNetworkHrpSuffixToNetworkConfiguration.Designer.cs +++ /dev/null @@ -1,2344 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -// -using System; -using System.Collections.Generic; -using System.Numerics; -using Microsoft.EntityFrameworkCore; -using Microsoft.EntityFrameworkCore.Infrastructure; -using Microsoft.EntityFrameworkCore.Migrations; -using Microsoft.EntityFrameworkCore.Storage.ValueConversion; -using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata; -using RadixDlt.NetworkGateway.Abstractions.Addressing; -using RadixDlt.NetworkGateway.Abstractions.Model; -using RadixDlt.NetworkGateway.PostgresIntegration; -using RadixDlt.NetworkGateway.PostgresIntegration.Models; - -#nullable disable - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations -{ - [DbContext(typeof(MigrationsDbContext))] - [Migration("20231130132946_AddNetworkHrpSuffixToNetworkConfiguration")] - partial class AddNetworkHrpSuffixToNetworkConfiguration - { - /// - protected override void BuildTargetModel(ModelBuilder modelBuilder) - { -#pragma warning disable 612, 618 - modelBuilder - .HasAnnotation("ProductVersion", "7.0.11") - .HasAnnotation("Relational:MaxIdentifierLength", 63); - - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_default_deposit_rule", new[] { "accept", "reject", "allow_existing" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_resource_preference_rule", new[] { "allowed", "disallowed" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "entity_type", new[] { "global_consensus_manager", "global_fungible_resource", "global_non_fungible_resource", "global_generic_component", "internal_generic_component", "global_account_component", "global_package", "internal_key_value_store", "internal_fungible_vault", "internal_non_fungible_vault", "global_validator", "global_access_controller", "global_identity", "global_one_resource_pool", "global_two_resource_pool", "global_multi_resource_pool", "global_transaction_tracker" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_event_type", new[] { "withdrawal", "deposit" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_operation_type", new[] { "resource_in_use", "account_deposited_into", "account_withdrawn_from" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_origin_type", new[] { "user", "epoch_change" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_type", new[] { "origin", "event", "manifest_address", "affected_global_entity" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_status", new[] { "succeeded", "failed" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_type", new[] { "genesis", "user", "round_update" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "module_id", new[] { "main", "metadata", "royalty", "role_assignment" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "non_fungible_id_type", new[] { "string", "integer", "bytes", "ruid" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "package_vm_type", new[] { "native", "scrypto_v1" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_intent_ledger_status", new[] { "unknown", "committed", "commit_pending", "permanent_rejection", "possible_to_commit", "likely_but_not_certain_rejection" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "pending_transaction_payload_ledger_status", new[] { "unknown", "committed", "commit_pending", "clashing_commit", "permanently_rejected", "transiently_accepted", "transiently_rejected" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "public_key_type", new[] { "ecdsa_secp256k1", "eddsa_ed25519" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "resource_type", new[] { "fungible", "non_fungible" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "sbor_type_kind", new[] { "well_known", "schema_local" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "state_type", new[] { "json", "sbor" }); - NpgsqlModelBuilderExtensions.UseIdentityByDefaultColumns(modelBuilder); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountDefaultDepositRuleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AccountEntityId") - .HasColumnType("bigint") - .HasColumnName("account_entity_id"); - - b.Property("DefaultDepositRule") - .HasColumnType("account_default_deposit_rule") - .HasColumnName("default_deposit_rule"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.HasKey("Id"); - - b.HasIndex("AccountEntityId", "FromStateVersion"); - - b.ToTable("account_default_deposit_rule_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AccountResourcePreferenceRuleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AccountEntityId") - .HasColumnType("bigint") - .HasColumnName("account_entity_id"); - - b.Property("AccountResourcePreferenceRule") - .HasColumnType("account_resource_preference_rule") - .HasColumnName("account_resource_preference_rule"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("AccountEntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("account_resource_preference_rule_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("MethodName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("method_name"); - - b.Property("RoyaltyAmount") - .HasColumnType("jsonb") - .HasColumnName("royalty_amount"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.HasIndex("EntityId", "MethodName", "FromStateVersion"); - - b.ToTable("component_method_royalty_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Address") - .IsRequired() - .HasColumnType("text") - .HasColumnName("address"); - - b.Property>("AncestorIds") - .HasColumnType("bigint[]") - .HasColumnName("ancestor_ids"); - - b.Property>("CorrelatedEntities") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("correlated_entities"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("GlobalAncestorId") - .HasColumnType("bigint") - .HasColumnName("global_ancestor_id"); - - b.Property("IsGlobal") - .HasColumnType("boolean") - .HasColumnName("is_global"); - - b.Property("OwnerAncestorId") - .HasColumnType("bigint") - .HasColumnName("owner_ancestor_id"); - - b.Property("ParentAncestorId") - .HasColumnType("bigint") - .HasColumnName("parent_ancestor_id"); - - b.Property("discriminator") - .HasColumnType("entity_type"); - - b.HasKey("Id"); - - b.HasIndex("Address") - .IsUnique(); - - b.HasIndex("FromStateVersion") - .HasFilter("discriminator = 'global_validator'"); - - b.ToTable("entities"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("MetadataIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("metadata_ids"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_metadata_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityMetadataHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("Key") - .IsRequired() - .HasColumnType("text") - .HasColumnName("key"); - - b.Property("Value") - .HasColumnType("bytea") - .HasColumnName("value"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "Key", "FromStateVersion"); - - b.ToTable("entity_metadata_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("FungibleResourceEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("fungible_resource_entity_ids"); - - b.Property>("FungibleResourceSignificantUpdateStateVersions") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("fungible_resource_significant_update_state_versions"); - - b.Property>("NonFungibleResourceEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_resource_entity_ids"); - - b.Property>("NonFungibleResourceSignificantUpdateStateVersions") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_resource_significant_update_state_versions"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_resource_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("discriminator") - .HasColumnType("resource_type"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceVaultAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property>("VaultEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("vault_entity_ids"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "ResourceEntityId", "FromStateVersion"); - - b.ToTable("entity_resource_vault_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsAggregateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property>("EntryIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("entry_ids"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("OwnerRoleId") - .HasColumnType("bigint") - .HasColumnName("owner_role_id"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_role_assignments_aggregate_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("KeyModule") - .HasColumnType("module_id") - .HasColumnName("key_module"); - - b.Property("KeyRole") - .IsRequired() - .HasColumnType("text") - .HasColumnName("key_role"); - - b.Property("RoleAssignments") - .HasColumnType("jsonb") - .HasColumnName("role_assignments"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "KeyRole", "KeyModule", "FromStateVersion"); - - b.ToTable("entity_role_assignments_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityRoleAssignmentsOwnerRoleHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("RoleAssignments") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("role_assignments"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("entity_role_assignments_owner_role_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("GlobalEntityId") - .HasColumnType("bigint") - .HasColumnName("global_entity_id"); - - b.Property("OwnerEntityId") - .HasColumnType("bigint") - .HasColumnName("owner_entity_id"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("VaultEntityId") - .HasColumnType("bigint") - .HasColumnName("vault_entity_id"); - - b.Property("discriminator") - .HasColumnType("resource_type"); - - b.HasKey("Id"); - - b.HasIndex("GlobalEntityId", "FromStateVersion") - .HasFilter("is_royalty_vault = true"); - - b.HasIndex("OwnerEntityId", "FromStateVersion") - .HasFilter("is_royalty_vault = true"); - - b.HasIndex("VaultEntityId", "FromStateVersion") - .HasFilter("discriminator = 'non_fungible'"); - - b.HasIndex("GlobalEntityId", "VaultEntityId", "FromStateVersion"); - - b.HasIndex("Id", "ResourceEntityId", "FromStateVersion"); - - b.HasIndex("OwnerEntityId", "VaultEntityId", "FromStateVersion"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreEntryHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("Key") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key"); - - b.Property("KeyValueStoreEntityId") - .HasColumnType("bigint") - .HasColumnName("key_value_store_entity_id"); - - b.Property("Value") - .HasColumnType("bytea") - .HasColumnName("value"); - - b.HasKey("Id"); - - b.HasIndex("KeyValueStoreEntityId", "Key", "FromStateVersion"); - - b.ToTable("key_value_store_entry_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreSchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("KeySborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("key_sbor_type_kind"); - - b.Property("KeySchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("key_schema_defining_entity_id"); - - b.Property("KeySchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key_schema_hash"); - - b.Property("KeyTypeIndex") - .HasColumnType("bigint") - .HasColumnName("key_type_index"); - - b.Property("KeyValueStoreEntityId") - .HasColumnType("bigint") - .HasColumnName("key_value_store_entity_id"); - - b.Property("ValueSborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("value_sbor_type_kind"); - - b.Property("ValueSchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("value_schema_defining_entity_id"); - - b.Property("ValueSchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("value_schema_hash"); - - b.Property("ValueTypeIndex") - .HasColumnType("bigint") - .HasColumnName("value_type_index"); - - b.HasKey("Id"); - - b.HasIndex("KeyValueStoreEntityId", "FromStateVersion"); - - b.ToTable("key_value_store_schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction", b => - { - b.Property("StateVersion") - .HasColumnType("bigint") - .HasColumnName("state_version"); - - b.Property("AffectedGlobalEntities") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("affected_global_entities"); - - b.Property("CreatedTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("created_timestamp"); - - b.Property("Epoch") - .HasColumnType("bigint") - .HasColumnName("epoch"); - - b.Property("FeePaid") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("fee_paid"); - - b.Property("IndexInEpoch") - .HasColumnType("bigint") - .HasColumnName("index_in_epoch"); - - b.Property("IndexInRound") - .HasColumnType("bigint") - .HasColumnName("index_in_round"); - - b.Property("NormalizedRoundTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("normalized_round_timestamp"); - - b.Property("ReceiptCostingParameters") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_costing_parameters"); - - b.Property("ReceiptErrorMessage") - .HasColumnType("text") - .HasColumnName("receipt_error_message"); - - b.Property("ReceiptEventEmitters") - .IsRequired() - .HasColumnType("jsonb[]") - .HasColumnName("receipt_event_emitters"); - - b.Property("ReceiptEventNames") - .IsRequired() - .HasColumnType("text[]") - .HasColumnName("receipt_event_names"); - - b.Property("ReceiptEventSborTypeKinds") - .IsRequired() - .HasColumnType("sbor_type_kind[]") - .HasColumnName("receipt_event_sbor_type_kinds"); - - b.Property("ReceiptEventSbors") - .IsRequired() - .HasColumnType("bytea[]") - .HasColumnName("receipt_event_sbors"); - - b.Property("ReceiptEventSchemaEntityIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("receipt_event_schema_entity_ids"); - - b.Property("ReceiptEventSchemaHashes") - .IsRequired() - .HasColumnType("bytea[]") - .HasColumnName("receipt_event_schema_hashes"); - - b.Property("ReceiptEventTypeIndexes") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("receipt_event_type_indexes"); - - b.Property("ReceiptFeeDestination") - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_destination"); - - b.Property("ReceiptFeeSource") - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_source"); - - b.Property("ReceiptFeeSummary") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_fee_summary"); - - b.Property("ReceiptNextEpoch") - .HasColumnType("jsonb") - .HasColumnName("receipt_next_epoch"); - - b.Property("ReceiptOutput") - .HasColumnType("jsonb") - .HasColumnName("receipt_output"); - - b.Property("ReceiptStateUpdates") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("receipt_state_updates"); - - b.Property("ReceiptStatus") - .HasColumnType("ledger_transaction_status") - .HasColumnName("receipt_status"); - - b.Property("ReceiptTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("receipt_tree_hash"); - - b.Property("RoundInEpoch") - .HasColumnType("bigint") - .HasColumnName("round_in_epoch"); - - b.Property("RoundTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("round_timestamp"); - - b.Property("StateTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("state_tree_hash"); - - b.Property("TipPaid") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("tip_paid"); - - b.Property("TransactionTreeHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("transaction_tree_hash"); - - b.Property("discriminator") - .HasColumnType("ledger_transaction_type"); - - b.HasKey("StateVersion"); - - b.HasIndex("RoundTimestamp"); - - b.HasIndex("Epoch", "RoundInEpoch") - .IsUnique() - .HasFilter("index_in_round = 0"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("StateVersion") - .HasColumnType("bigint") - .HasColumnName("state_version"); - - b.Property("discriminator") - .HasColumnType("ledger_transaction_marker_type"); - - b.HasKey("Id"); - - b.HasIndex("StateVersion"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NetworkConfiguration", b => - { - b.Property("Id") - .HasColumnType("integer") - .HasColumnName("id"); - - b.Property("AddressTypeDefinitions") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("address_type_definitions"); - - b.Property("GenesisEpoch") - .HasColumnType("bigint") - .HasColumnName("genesis_epoch"); - - b.Property("GenesisRound") - .HasColumnType("bigint") - .HasColumnName("genesis_round"); - - b.Property("HrpDefinition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("hrp_definition"); - - b.Property("NetworkHrpSuffix") - .IsRequired() - .HasColumnType("text") - .HasColumnName("network_hrp_suffix"); - - b.Property("NetworkId") - .HasColumnType("smallint") - .HasColumnName("network_id"); - - b.Property("NetworkName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("network_name"); - - b.Property("WellKnownAddresses") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("well_known_addresses"); - - b.HasKey("Id"); - - b.ToTable("network_configuration"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdData", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("NonFungibleId") - .IsRequired() - .HasColumnType("text") - .HasColumnName("non_fungible_id"); - - b.Property("NonFungibleResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleResourceEntityId", "FromStateVersion"); - - b.HasIndex("NonFungibleResourceEntityId", "NonFungibleId", "FromStateVersion") - .IsUnique(); - - b.ToTable("non_fungible_id_data"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdDataHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Data") - .HasColumnType("bytea") - .HasColumnName("data"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("IsDeleted") - .HasColumnType("boolean") - .HasColumnName("is_deleted"); - - b.Property("IsLocked") - .HasColumnType("boolean") - .HasColumnName("is_locked"); - - b.Property("NonFungibleIdDataId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_id_data_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleIdDataId", "FromStateVersion"); - - b.ToTable("non_fungible_id_data_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdLocationHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("NonFungibleIdDataId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_id_data_id"); - - b.Property("VaultEntityId") - .HasColumnType("bigint") - .HasColumnName("vault_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleIdDataId", "FromStateVersion"); - - b.ToTable("non_fungible_id_location_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdStoreHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property>("NonFungibleIdDataIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_id_data_ids"); - - b.Property("NonFungibleResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("non_fungible_resource_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("NonFungibleResourceEntityId", "FromStateVersion"); - - b.ToTable("non_fungible_id_store_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleSchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("SborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("sbor_type_kind"); - - b.Property("SchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("schema_defining_entity_id"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.Property("TypeIndex") - .HasColumnType("bigint") - .HasColumnName("type_index"); - - b.HasKey("Id"); - - b.HasIndex("ResourceEntityId", "FromStateVersion"); - - b.ToTable("non_fungible_schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageBlueprintHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("AuthTemplate") - .HasColumnType("jsonb") - .HasColumnName("auth_template"); - - b.Property("AuthTemplateIsLocked") - .HasColumnType("boolean") - .HasColumnName("auth_template_is_locked"); - - b.Property("Definition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("definition"); - - b.Property>("DependantEntityIds") - .HasColumnType("bigint[]") - .HasColumnName("dependant_entity_ids"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Name") - .IsRequired() - .HasColumnType("text") - .HasColumnName("name"); - - b.Property("PackageEntityId") - .HasColumnType("bigint") - .HasColumnName("package_entity_id"); - - b.Property("RoyaltyConfig") - .HasColumnType("jsonb") - .HasColumnName("royalty_config"); - - b.Property("RoyaltyConfigIsLocked") - .HasColumnType("boolean") - .HasColumnName("royalty_config_is_locked"); - - b.Property("Version") - .IsRequired() - .HasColumnType("text") - .HasColumnName("version"); - - b.HasKey("Id"); - - b.HasIndex("PackageEntityId", "FromStateVersion"); - - b.HasIndex("PackageEntityId", "Name", "Version", "FromStateVersion"); - - b.ToTable("package_blueprint_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PackageCodeHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Code") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("code"); - - b.Property("CodeHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("code_hash"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("PackageEntityId") - .HasColumnType("bigint") - .HasColumnName("package_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("PackageEntityId", "FromStateVersion"); - - b.ToTable("package_code_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EndEpochExclusive") - .HasColumnType("numeric(20,0)") - .HasColumnName("end_epoch_exclusive"); - - b.Property("IntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("intent_hash"); - - b.Property("PayloadHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("payload_hash"); - - b.Property("PayloadId") - .HasColumnType("bigint") - .HasColumnName("payload_id"); - - b.Property("VersionControl") - .IsConcurrencyToken() - .ValueGeneratedOnAddOrUpdate() - .HasColumnType("xid") - .HasColumnName("xmin"); - - b.HasKey("Id"); - - b.HasIndex("IntentHash"); - - b.HasIndex("PayloadHash") - .IsUnique(); - - b.ToTable("pending_transactions"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("NotarizedTransactionBlob") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("notarized_transaction_blob"); - - b.Property("PendingTransactionId") - .HasColumnType("bigint") - .HasColumnName("pending_transaction_id"); - - b.HasKey("Id"); - - b.HasIndex("PendingTransactionId") - .IsUnique(); - - b.ToTable("pending_transaction_payloads"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ResourceEntitySupplyHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("TotalBurned") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_burned"); - - b.Property("TotalMinted") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_minted"); - - b.Property("TotalSupply") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("total_supply"); - - b.HasKey("Id"); - - b.HasIndex("ResourceEntityId", "FromStateVersion"); - - b.ToTable("resource_entity_supply_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SchemaHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Schema") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.HasIndex("SchemaHash", "FromStateVersion"); - - b.ToTable("schema_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EntityId") - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("discriminator") - .HasColumnType("state_type"); - - b.HasKey("Id"); - - b.HasIndex("EntityId", "FromStateVersion"); - - b.ToTable("state_history"); - - b.HasDiscriminator("discriminator"); - - b.UseTphMappingStrategy(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("Epoch") - .HasColumnType("bigint") - .HasColumnName("epoch"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Stake") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("stake"); - - b.Property("ValidatorPublicKeyHistoryId") - .HasColumnType("bigint") - .HasColumnName("validator_public_key_history_id"); - - b.HasKey("Id"); - - b.HasIndex("Epoch"); - - b.HasIndex("FromStateVersion"); - - b.HasIndex("ValidatorPublicKeyHistoryId"); - - b.ToTable("validator_active_set_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorEmissionStatistics", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("EpochNumber") - .HasColumnType("bigint") - .HasColumnName("epoch_number"); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("ProposalsMade") - .HasColumnType("bigint") - .HasColumnName("proposals_made"); - - b.Property("ProposalsMissed") - .HasColumnType("bigint") - .HasColumnName("proposals_missed"); - - b.Property("ValidatorEntityId") - .HasColumnType("bigint") - .HasColumnName("validator_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("ValidatorEntityId", "EpochNumber"); - - b.ToTable("validator_emission_statistics"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", b => - { - b.Property("Id") - .ValueGeneratedOnAdd() - .HasColumnType("bigint") - .HasColumnName("id"); - - NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - - b.Property("FromStateVersion") - .HasColumnType("bigint") - .HasColumnName("from_state_version"); - - b.Property("Key") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("key"); - - b.Property("KeyType") - .HasColumnType("public_key_type") - .HasColumnName("key_type"); - - b.Property("ValidatorEntityId") - .HasColumnType("bigint") - .HasColumnName("validator_entity_id"); - - b.HasKey("Id"); - - b.HasIndex("ValidatorEntityId", "FromStateVersion"); - - b.HasIndex("ValidatorEntityId", "KeyType", "Key"); - - b.ToTable("validator_public_key_history"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccessControllerEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalAccessController); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalAccountEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalAccountComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalConsensusManager", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalConsensusManager); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalFungibleResourceEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("Divisibility") - .HasColumnType("integer") - .HasColumnName("divisibility"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalFungibleResource); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalGenericComponentEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalGenericComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalIdentityEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalIdentity); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalMultiResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalMultiResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalNonFungibleResourceEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("NonFungibleIdType") - .HasColumnType("non_fungible_id_type") - .HasColumnName("non_fungible_id_type"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalNonFungibleResource); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalOneResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalOneResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalPackageEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("VmType") - .HasColumnType("package_vm_type") - .HasColumnName("vm_type"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalPackage); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTransactionTrackerEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalTransactionTracker); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalTwoResourcePoolEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalTwoResourcePool); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GlobalValidatorEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("LockedOwnerStakeUnitVault") - .HasColumnType("bigint") - .HasColumnName("locked_owner_stake_unit_vault_entity_id"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("PendingOwnerStakeUnitUnlockVault") - .HasColumnType("bigint") - .HasColumnName("pending_owner_stake_unit_unlock_vault_entity_id"); - - b.Property("PendingXrdWithdrawVault") - .HasColumnType("bigint") - .HasColumnName("pending_xrd_withdraw_vault_entity_id"); - - b.Property("StakeVaultEntityId") - .HasColumnType("bigint") - .HasColumnName("stake_vault_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.GlobalValidator); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalFungibleVaultEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("ResourceEntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.Property("RoyaltyVaultOfEntityId") - .HasColumnType("bigint") - .HasColumnName("royalty_vault_of_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalFungibleVault); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalGenericComponentEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalGenericComponent); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalKeyValueStoreEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalKeyValueStore); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.InternalNonFungibleVaultEntity", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); - - b.Property("BlueprintName") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_name"); - - b.Property("BlueprintVersion") - .IsRequired() - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("text") - .HasColumnName("blueprint_version"); - - b.Property("PackageId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("package_id"); - - b.Property("ResourceEntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.ToTable("entities"); - - b.HasDiscriminator().HasValue(EntityType.InternalNonFungibleVault); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleResourceAggregatedVaultsHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); - - b.Property("Balance") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("balance"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator().HasValue(ResourceType.Fungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleResourceAggregatedVaultsHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityResourceAggregatedVaultsHistory"); - - b.Property("TotalCount") - .HasColumnType("bigint") - .HasColumnName("total_count"); - - b.ToTable("entity_resource_aggregated_vaults_history"); - - b.HasDiscriminator().HasValue(ResourceType.NonFungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityFungibleVaultHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); - - b.Property("Balance") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("balance"); - - b.Property("IsRoyaltyVault") - .HasColumnType("boolean") - .HasColumnName("is_royalty_vault"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator().HasValue(ResourceType.Fungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityNonFungibleVaultHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.EntityVaultHistory"); - - b.Property>("NonFungibleIds") - .IsRequired() - .HasColumnType("bigint[]") - .HasColumnName("non_fungible_ids"); - - b.ToTable("entity_vault_history"); - - b.HasDiscriminator().HasValue(ResourceType.NonFungible); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.GenesisLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.Genesis); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.RoundUpdateLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.RoundUpdate); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.UserLedgerTransaction", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransaction"); - - b.Property("IntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("intent_hash"); - - b.Property("Message") - .HasColumnType("jsonb") - .HasColumnName("message"); - - b.Property("PayloadHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("payload_hash"); - - b.Property("RawPayload") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("raw_payload"); - - b.Property("SignedIntentHash") - .IsRequired() - .HasColumnType("text") - .HasColumnName("signed_intent_hash"); - - b.HasIndex("IntentHash") - .HasFilter("intent_hash IS NOT NULL"); - - NpgsqlIndexBuilderExtensions.HasMethod(b.HasIndex("IntentHash"), "hash"); - - b.ToTable("ledger_transactions"); - - b.HasDiscriminator().HasValue(LedgerTransactionType.User); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.AffectedGlobalEntityTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.HasIndex("EntityId", "StateVersion") - .HasFilter("discriminator = 'affected_global_entity'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.AffectedGlobalEntity); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.EventLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("EventType") - .HasColumnType("ledger_transaction_marker_event_type") - .HasColumnName("event_type"); - - b.Property("Quantity") - .HasPrecision(1000) - .HasColumnType("numeric") - .HasColumnName("quantity"); - - b.Property("ResourceEntityId") - .HasColumnType("bigint") - .HasColumnName("resource_entity_id"); - - b.HasIndex("EventType", "EntityId", "StateVersion") - .HasFilter("discriminator = 'event'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Event); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ManifestAddressLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("EntityId") - .ValueGeneratedOnUpdateSometimes() - .HasColumnType("bigint") - .HasColumnName("entity_id"); - - b.Property("OperationType") - .HasColumnType("ledger_transaction_marker_operation_type") - .HasColumnName("operation_type"); - - b.HasIndex("OperationType", "EntityId", "StateVersion") - .HasFilter("discriminator = 'manifest_address'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestAddress); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.OriginLedgerTransactionMarker", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); - - b.Property("OriginType") - .HasColumnType("ledger_transaction_marker_origin_type") - .HasColumnName("origin_type"); - - b.HasIndex("OriginType", "StateVersion") - .HasFilter("discriminator = 'origin'"); - - b.ToTable("ledger_transaction_markers"); - - b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.Origin); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.JsonStateHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); - - b.Property("JsonState") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("json_state"); - - b.ToTable("state_history"); - - b.HasDiscriminator().HasValue(StateType.Json); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.SborStateHistory", b => - { - b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.StateHistory"); - - b.Property("SborState") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("sbor_state"); - - b.Property("SborTypeKind") - .HasColumnType("sbor_type_kind") - .HasColumnName("sbor_type_kind"); - - b.Property("SchemaDefiningEntityId") - .HasColumnType("bigint") - .HasColumnName("schema_defining_entity_id"); - - b.Property("SchemaHash") - .IsRequired() - .HasColumnType("bytea") - .HasColumnName("schema_hash"); - - b.Property("TypeIndex") - .HasColumnType("bigint") - .HasColumnName("type_index"); - - b.ToTable("state_history"); - - b.HasDiscriminator().HasValue(StateType.Sbor); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionGatewayHandling", "GatewayHandling", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("AttemptedSubmissionToNodesCount") - .HasColumnType("integer") - .HasColumnName("node_submission_count"); - - b1.Property("FirstSubmittedToGatewayTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("first_submitted_to_gateway_timestamp"); - - b1.Property("HandlingStatusReason") - .HasColumnType("text") - .HasColumnName("handling_status_reason"); - - b1.Property("ResubmitFromTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("resubmit_from_timestamp"); - - b1.HasKey("PendingTransactionId"); - - b1.HasIndex("FirstSubmittedToGatewayTimestamp"); - - b1.HasIndex("ResubmitFromTimestamp"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionLedgerDetails", "LedgerDetails", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("CommitTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("commit_timestamp"); - - b1.Property("InitialRejectionReason") - .HasColumnType("text") - .HasColumnName("initial_rejection_reason"); - - b1.Property("IntentLedgerStatus") - .HasColumnType("pending_transaction_intent_ledger_status") - .HasColumnName("intent_status"); - - b1.Property("LatestRejectionReason") - .HasColumnType("text") - .HasColumnName("latest_rejection_reason"); - - b1.Property("LatestRejectionTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("latest_rejection_timestamp"); - - b1.Property("PayloadLedgerStatus") - .HasColumnType("pending_transaction_payload_ledger_status") - .HasColumnName("payload_status"); - - b1.HasKey("PendingTransactionId"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.OwnsOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionNetworkDetails", "NetworkDetails", b1 => - { - b1.Property("PendingTransactionId") - .HasColumnType("bigint"); - - b1.Property("LastSubmitErrorTitle") - .HasColumnType("text") - .HasColumnName("last_submit_error"); - - b1.Property("LatestNodeSubmissionTimestamp") - .HasColumnType("timestamp with time zone") - .HasColumnName("latest_node_submission_timestamp"); - - b1.Property("LatestNodeSubmissionWasAccepted") - .HasColumnType("boolean") - .HasColumnName("latest_node_submission_was_accepted"); - - b1.Property("LatestSubmittedToNodeName") - .HasColumnType("text") - .HasColumnName("latest_submitted_to_node_name"); - - b1.HasKey("PendingTransactionId"); - - b1.ToTable("pending_transactions"); - - b1.WithOwner() - .HasForeignKey("PendingTransactionId"); - }); - - b.Navigation("GatewayHandling") - .IsRequired(); - - b.Navigation("LedgerDetails") - .IsRequired(); - - b.Navigation("NetworkDetails") - .IsRequired(); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", b => - { - b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", "PendingTransaction") - .WithOne("Payload") - .HasForeignKey("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransactionPayload", "PendingTransactionId") - .OnDelete(DeleteBehavior.Cascade); - - b.Navigation("PendingTransaction"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorActiveSetHistory", b => - { - b.HasOne("RadixDlt.NetworkGateway.PostgresIntegration.Models.ValidatorPublicKeyHistory", "PublicKey") - .WithMany() - .HasForeignKey("ValidatorPublicKeyHistoryId") - .OnDelete(DeleteBehavior.Cascade) - .IsRequired(); - - b.Navigation("PublicKey"); - }); - - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.PendingTransaction", b => - { - b.Navigation("Payload"); - }); -#pragma warning restore 612, 618 - } - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231130132946_AddNetworkHrpSuffixToNetworkConfiguration.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231130132946_AddNetworkHrpSuffixToNetworkConfiguration.cs deleted file mode 100644 index 3be348cc1..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20231130132946_AddNetworkHrpSuffixToNetworkConfiguration.cs +++ /dev/null @@ -1,101 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using Microsoft.EntityFrameworkCore.Migrations; - -#nullable disable - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations -{ - /// - public partial class AddNetworkHrpSuffixToNetworkConfiguration : Migration - { - /// - protected override void Up(MigrationBuilder migrationBuilder) - { - migrationBuilder.AddColumn( - name: "network_hrp_suffix", - table: "network_configuration", - type: "text", - nullable: true, - defaultValue: null); - - migrationBuilder.Sql("update network_configuration set network_hrp_suffix = (select substring(recordset.\"HrpPrefix\"::text,'_(.+)') from network_configuration, jsonb_to_recordset(address_type_definitions) as recordset(\"HrpPrefix\" TEXT) WHERE recordset.\"HrpPrefix\" like '%account%' limit 1)"); - - migrationBuilder.AlterColumn( - name: "network_hrp_suffix", - table: "network_configuration", - type: "text", - nullable: false); - } - - /// - protected override void Down(MigrationBuilder migrationBuilder) - { - migrationBuilder.DropColumn( - name: "network_hrp_suffix", - table: "network_configuration"); - } - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240119095226_SupportProtocolUpdate.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240119095226_SupportProtocolUpdate.cs deleted file mode 100644 index 58a0a2421..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240119095226_SupportProtocolUpdate.cs +++ /dev/null @@ -1,205 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using System.Collections.Generic; -using Microsoft.EntityFrameworkCore.Migrations; -using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata; -using RadixDlt.NetworkGateway.Abstractions.Model; - -#nullable disable - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations -{ - /// - public partial class SupportProtocolUpdate : Migration - { - /// - protected override void Up(MigrationBuilder migrationBuilder) - { - // Add transaction_trakcer to well known addresses. - migrationBuilder.Sql(@"UPDATE network_configuration SET well_known_addresses = well_known_addresses || '{""TransactionTracker"": ""transactiontracker_tdx_2_1stxxxxxxxxxxtxtrakxxxxxxxxx006844685494xxxxxxxxxxzw7jp""}'::jsonb WHERE network_name = 'stokenet'"); - migrationBuilder.Sql(@"UPDATE network_configuration SET well_known_addresses = well_known_addresses || '{""TransactionTracker"": ""transactiontracker_rdx1stxxxxxxxxxxtxtrakxxxxxxxxx006844685494xxxxxxxxxtxtrak""}'::jsonb WHERE network_name = 'mainnet'"); - - // Support flash transaction type. - migrationBuilder.AlterDatabase() - .Annotation("Npgsql:Enum:ledger_transaction_type", "genesis,user,round_update,flash") - .OldAnnotation("Npgsql:Enum:ledger_transaction_type", "genesis,user,round_update"); - - // Store package vm type on package_code_history - migrationBuilder.AddColumn( - name: "vm_type", - table: "package_code_history", - type: "package_vm_type", - nullable: false, - defaultValue: PackageVmType.Native); - - migrationBuilder.AddColumn( - name: "is_deleted", - table: "package_code_history", - type: "boolean", - nullable: false, - defaultValue: false); - - migrationBuilder.Sql("update package_code_history pch set vm_type = (select vm_type from entities e where e.id = pch.package_entity_id)"); - - migrationBuilder.AlterColumn( - name: "vm_type", - table: "package_code_history", - oldDefaultValue: PackageVmType.Native, - defaultValue: null); - - migrationBuilder.AlterColumn( - name: "is_deleted", - table: "package_code_history", - oldDefaultValue: false, - defaultValue: null); - - migrationBuilder.DropColumn( - name: "vm_type", - table: "entities"); - - // Create aggregate for package blueprint. - migrationBuilder.CreateTable( - name: "package_blueprint_aggregate_history", - columns: table => new - { - id = table.Column(type: "bigint", nullable: false) - .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn), - from_state_version = table.Column(type: "bigint", nullable: false), - package_entity_id = table.Column(type: "bigint", nullable: false), - package_blueprint_ids = table.Column>(type: "bigint[]", nullable: false) - }, - constraints: table => - { - table.PrimaryKey("PK_package_blueprint_aggregate_history", x => x.id); - }); - - migrationBuilder.CreateIndex( - name: "IX_package_blueprint_aggregate_history_package_entity_id_from_~", - table: "package_blueprint_aggregate_history", - columns: new[] { "package_entity_id", "from_state_version" }); - - migrationBuilder.Sql(@" - INSERT INTO package_blueprint_aggregate_history (from_state_version, package_entity_id, package_blueprint_ids) - SELECT MIN(from_state_version) from_state_version, package_entity_id, array_agg(id order by id asc) package_blueprint_ids - FROM package_blueprint_history - GROUP BY package_entity_id"); - - // Create aggregate for package code. - migrationBuilder.CreateTable( - name: "package_code_aggregate_history", - columns: table => new - { - id = table.Column(type: "bigint", nullable: false) - .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn), - from_state_version = table.Column(type: "bigint", nullable: false), - package_entity_id = table.Column(type: "bigint", nullable: false), - package_code_ids = table.Column>(type: "bigint[]", nullable: false) - }, - constraints: table => - { - table.PrimaryKey("PK_package_code_aggregate_history", x => x.id); - }); - - migrationBuilder.CreateIndex( - name: "IX_package_code_aggregate_history_package_entity_id_from_state~", - table: "package_code_aggregate_history", - columns: new[] { "package_entity_id", "from_state_version" }); - - migrationBuilder.Sql(@" -INSERT INTO package_code_aggregate_history (from_state_version, package_entity_id, package_code_ids) -SELECT MIN(from_state_version) from_state_version, package_entity_id, array_agg(id order by id asc) package_code_ids -FROM package_code_history -GROUP BY package_entity_id"); - } - - /// - protected override void Down(MigrationBuilder migrationBuilder) - { - migrationBuilder.DropTable( - name: "package_blueprint_aggregate_history"); - - migrationBuilder.DropTable( - name: "package_code_aggregate_history"); - - migrationBuilder.DropColumn( - name: "is_deleted", - table: "package_code_history"); - - migrationBuilder.DropColumn( - name: "vm_type", - table: "package_code_history"); - - migrationBuilder.AlterDatabase() - .Annotation("Npgsql:Enum:ledger_transaction_type", "genesis,user,round_update") - .OldAnnotation("Npgsql:Enum:ledger_transaction_type", "genesis,user,round_update,flash"); - - migrationBuilder.AddColumn( - name: "vm_type", - table: "entities", - type: "package_vm_type", - nullable: true); - } - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240119095226_SupportProtocolUpdate.Designer.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240207094138_InitialCreate.Designer.cs similarity index 92% rename from src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240119095226_SupportProtocolUpdate.Designer.cs rename to src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240207094138_InitialCreate.Designer.cs index 86f49c952..e75e71ee0 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240119095226_SupportProtocolUpdate.Designer.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240207094138_InitialCreate.Designer.cs @@ -62,7 +62,7 @@ * permissions under this License. */ -// +// using System; using System.Collections.Generic; using System.Numerics; @@ -71,7 +71,6 @@ using Microsoft.EntityFrameworkCore.Migrations; using Microsoft.EntityFrameworkCore.Storage.ValueConversion; using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata; -using RadixDlt.NetworkGateway.Abstractions.Addressing; using RadixDlt.NetworkGateway.Abstractions.Model; using RadixDlt.NetworkGateway.PostgresIntegration; using RadixDlt.NetworkGateway.PostgresIntegration.Models; @@ -81,8 +80,8 @@ namespace RadixDlt.NetworkGateway.PostgresIntegration.Migrations { [DbContext(typeof(MigrationsDbContext))] - [Migration("20240119095226_SupportProtocolUpdate")] - partial class SupportProtocolUpdate + [Migration("20240207094138_InitialCreate")] + partial class InitialCreate { /// protected override void BuildTargetModel(ModelBuilder modelBuilder) @@ -95,10 +94,11 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_default_deposit_rule", new[] { "accept", "reject", "allow_existing" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_resource_preference_rule", new[] { "allowed", "disallowed" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "entity_type", new[] { "global_consensus_manager", "global_fungible_resource", "global_non_fungible_resource", "global_generic_component", "internal_generic_component", "global_account_component", "global_package", "internal_key_value_store", "internal_fungible_vault", "internal_non_fungible_vault", "global_validator", "global_access_controller", "global_identity", "global_one_resource_pool", "global_two_resource_pool", "global_multi_resource_pool", "global_transaction_tracker" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_manifest_class", new[] { "general", "transfer", "validator_stake", "validator_unstake", "validator_claim", "account_deposit_settings_update", "pool_contribution", "pool_redemption" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_event_type", new[] { "withdrawal", "deposit" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_operation_type", new[] { "resource_in_use", "account_deposited_into", "account_withdrawn_from" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_operation_type", new[] { "resource_in_use", "account_deposited_into", "account_withdrawn_from", "account_owner_method_call" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_origin_type", new[] { "user", "epoch_change" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_type", new[] { "origin", "event", "manifest_address", "affected_global_entity" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_type", new[] { "origin", "event", "manifest_address", "affected_global_entity", "manifest_class" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_status", new[] { "succeeded", "failed" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_type", new[] { "genesis", "user", "round_update", "flash" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "module_id", new[] { "main", "metadata", "royalty", "role_assignment" }); @@ -176,6 +176,35 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) b.ToTable("account_resource_preference_rule_history"); }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property>("EntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("entry_ids"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("component_method_royalty_aggregate_history"); + }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyEntryHistory", b => { b.Property("Id") @@ -617,6 +646,35 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) b.UseTphMappingStrategy(); }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("KeyValueStoreEntityId") + .HasColumnType("bigint") + .HasColumnName("key_value_store_entity_id"); + + b.Property>("KeyValueStoreEntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("key_value_store_entry_ids"); + + b.HasKey("Id"); + + b.HasIndex("KeyValueStoreEntityId", "FromStateVersion"); + + b.ToTable("key_value_store_aggregate_history"); + }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreEntryHistory", b => { b.Property("Id") @@ -903,54 +961,6 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) b.UseTphMappingStrategy(); }); - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NetworkConfiguration", b => - { - b.Property("Id") - .HasColumnType("integer") - .HasColumnName("id"); - - b.Property("AddressTypeDefinitions") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("address_type_definitions"); - - b.Property("GenesisEpoch") - .HasColumnType("bigint") - .HasColumnName("genesis_epoch"); - - b.Property("GenesisRound") - .HasColumnType("bigint") - .HasColumnName("genesis_round"); - - b.Property("HrpDefinition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("hrp_definition"); - - b.Property("NetworkHrpSuffix") - .IsRequired() - .HasColumnType("text") - .HasColumnName("network_hrp_suffix"); - - b.Property("NetworkId") - .HasColumnType("smallint") - .HasColumnName("network_id"); - - b.Property("NetworkName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("network_name"); - - b.Property("WellKnownAddresses") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("well_known_addresses"); - - b.HasKey("Id"); - - b.ToTable("network_configuration"); - }); - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdData", b => { b.Property("Id") @@ -1287,8 +1297,8 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - b.Property("EndEpochExclusive") - .HasColumnType("numeric(20,0)") + b.Property("EndEpochExclusive") + .HasColumnType("bigint") .HasColumnName("end_epoch_exclusive"); b.Property("IntentHash") @@ -1523,6 +1533,8 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) b.HasIndex("ValidatorEntityId", "EpochNumber"); + NpgsqlIndexBuilderExtensions.IncludeProperties(b.HasIndex("ValidatorEntityId", "EpochNumber"), new[] { "ProposalsMade", "ProposalsMissed" }); + b.ToTable("validator_emission_statistics"); }); @@ -1565,6 +1577,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1591,6 +1609,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1617,6 +1641,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1643,6 +1673,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1673,6 +1709,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1699,6 +1741,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1725,6 +1773,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1751,6 +1805,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1781,6 +1841,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1807,6 +1873,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1833,6 +1905,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1859,6 +1937,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1885,6 +1969,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1927,6 +2017,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1962,6 +2058,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1997,6 +2099,12 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -2119,6 +2227,16 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) .HasColumnType("text") .HasColumnName("intent_hash"); + b.Property("ManifestClasses") + .IsRequired() + .HasColumnType("ledger_transaction_manifest_class[]") + .HasColumnName("manifest_classes"); + + b.Property("ManifestInstructions") + .IsRequired() + .HasColumnType("text") + .HasColumnName("manifest_instructions"); + b.Property("Message") .HasColumnType("jsonb") .HasColumnName("message"); @@ -2216,6 +2334,26 @@ protected override void BuildTargetModel(ModelBuilder modelBuilder) b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestAddress); }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ManifestClassMarker", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); + + b.Property("IsMostSpecific") + .HasColumnType("boolean") + .HasColumnName("is_most_specific"); + + b.Property("LedgerTransactionManifestClass") + .HasColumnType("ledger_transaction_manifest_class") + .HasColumnName("manifest_class"); + + b.HasIndex("LedgerTransactionManifestClass", "IsMostSpecific", "StateVersion") + .HasFilter("discriminator = 'manifest_class'"); + + b.ToTable("ledger_transaction_markers"); + + b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestClass); + }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.OriginLedgerTransactionMarker", b => { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20230922041840_InitialCreate.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240207094138_InitialCreate.cs similarity index 90% rename from src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20230922041840_InitialCreate.cs rename to src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240207094138_InitialCreate.cs index 2825b6523..dbbe75977 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20230922041840_InitialCreate.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/20240207094138_InitialCreate.cs @@ -67,7 +67,6 @@ using System.Numerics; using Microsoft.EntityFrameworkCore.Migrations; using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata; -using RadixDlt.NetworkGateway.Abstractions.Addressing; using RadixDlt.NetworkGateway.Abstractions.Model; using RadixDlt.NetworkGateway.PostgresIntegration.Models; @@ -85,12 +84,13 @@ protected override void Up(MigrationBuilder migrationBuilder) .Annotation("Npgsql:Enum:account_default_deposit_rule", "accept,reject,allow_existing") .Annotation("Npgsql:Enum:account_resource_preference_rule", "allowed,disallowed") .Annotation("Npgsql:Enum:entity_type", "global_consensus_manager,global_fungible_resource,global_non_fungible_resource,global_generic_component,internal_generic_component,global_account_component,global_package,internal_key_value_store,internal_fungible_vault,internal_non_fungible_vault,global_validator,global_access_controller,global_identity,global_one_resource_pool,global_two_resource_pool,global_multi_resource_pool,global_transaction_tracker") + .Annotation("Npgsql:Enum:ledger_transaction_manifest_class", "general,transfer,validator_stake,validator_unstake,validator_claim,account_deposit_settings_update,pool_contribution,pool_redemption") .Annotation("Npgsql:Enum:ledger_transaction_marker_event_type", "withdrawal,deposit") - .Annotation("Npgsql:Enum:ledger_transaction_marker_operation_type", "resource_in_use,account_deposited_into,account_withdrawn_from") + .Annotation("Npgsql:Enum:ledger_transaction_marker_operation_type", "resource_in_use,account_deposited_into,account_withdrawn_from,account_owner_method_call") .Annotation("Npgsql:Enum:ledger_transaction_marker_origin_type", "user,epoch_change") - .Annotation("Npgsql:Enum:ledger_transaction_marker_type", "origin,event,manifest_address,affected_global_entity") + .Annotation("Npgsql:Enum:ledger_transaction_marker_type", "origin,event,manifest_address,affected_global_entity,manifest_class") .Annotation("Npgsql:Enum:ledger_transaction_status", "succeeded,failed") - .Annotation("Npgsql:Enum:ledger_transaction_type", "genesis,user,round_update") + .Annotation("Npgsql:Enum:ledger_transaction_type", "genesis,user,round_update,flash") .Annotation("Npgsql:Enum:module_id", "main,metadata,royalty,role_assignment") .Annotation("Npgsql:Enum:non_fungible_id_type", "string,integer,bytes,ruid") .Annotation("Npgsql:Enum:package_vm_type", "native,scrypto_v1") @@ -133,6 +133,21 @@ protected override void Up(MigrationBuilder migrationBuilder) table.PrimaryKey("PK_account_resource_preference_rule_history", x => x.id); }); + migrationBuilder.CreateTable( + name: "component_method_royalty_aggregate_history", + columns: table => new + { + id = table.Column(type: "bigint", nullable: false) + .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn), + from_state_version = table.Column(type: "bigint", nullable: false), + entity_id = table.Column(type: "bigint", nullable: false), + entry_ids = table.Column>(type: "bigint[]", nullable: false) + }, + constraints: table => + { + table.PrimaryKey("PK_component_method_royalty_aggregate_history", x => x.id); + }); + migrationBuilder.CreateTable( name: "component_method_royalty_entry_history", columns: table => new @@ -168,9 +183,9 @@ protected override void Up(MigrationBuilder migrationBuilder) package_id = table.Column(type: "bigint", nullable: true), blueprint_name = table.Column(type: "text", nullable: true), blueprint_version = table.Column(type: "text", nullable: true), + assigned_module_ids = table.Column>(type: "module_id[]", nullable: true), divisibility = table.Column(type: "integer", nullable: true), non_fungible_id_type = table.Column(type: "non_fungible_id_type", nullable: true), - vm_type = table.Column(type: "package_vm_type", nullable: true), stake_vault_entity_id = table.Column(type: "bigint", nullable: true), pending_xrd_withdraw_vault_entity_id = table.Column(type: "bigint", nullable: true), locked_owner_stake_unit_vault_entity_id = table.Column(type: "bigint", nullable: true), @@ -338,6 +353,21 @@ protected override void Up(MigrationBuilder migrationBuilder) table.PrimaryKey("PK_entity_vault_history", x => x.id); }); + migrationBuilder.CreateTable( + name: "key_value_store_aggregate_history", + columns: table => new + { + id = table.Column(type: "bigint", nullable: false) + .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn), + from_state_version = table.Column(type: "bigint", nullable: false), + key_value_store_entity_id = table.Column(type: "bigint", nullable: false), + key_value_store_entry_ids = table.Column>(type: "bigint[]", nullable: false) + }, + constraints: table => + { + table.PrimaryKey("PK_key_value_store_aggregate_history", x => x.id); + }); + migrationBuilder.CreateTable( name: "key_value_store_entry_history", columns: table => new @@ -391,6 +421,8 @@ protected override void Up(MigrationBuilder migrationBuilder) resource_entity_id = table.Column(type: "bigint", nullable: true), quantity = table.Column(type: "numeric(1000)", precision: 1000, nullable: true), operation_type = table.Column(type: "ledger_transaction_marker_operation_type", nullable: true), + manifest_class = table.Column(type: "ledger_transaction_manifest_class", nullable: true), + is_most_specific = table.Column(type: "boolean", nullable: true), origin_type = table.Column(type: "ledger_transaction_marker_origin_type", nullable: true) }, constraints: table => @@ -429,6 +461,7 @@ protected override void Up(MigrationBuilder migrationBuilder) receipt_event_schema_hashes = table.Column(type: "bytea[]", nullable: false), receipt_event_type_indexes = table.Column(type: "bigint[]", nullable: false), receipt_event_sbor_type_kinds = table.Column(type: "sbor_type_kind[]", nullable: false), + balance_changes = table.Column(type: "jsonb", nullable: true), transaction_tree_hash = table.Column(type: "text", nullable: false), receipt_tree_hash = table.Column(type: "text", nullable: false), state_tree_hash = table.Column(type: "text", nullable: false), @@ -437,31 +470,15 @@ protected override void Up(MigrationBuilder migrationBuilder) intent_hash = table.Column(type: "text", nullable: true), signed_intent_hash = table.Column(type: "text", nullable: true), message = table.Column(type: "jsonb", nullable: true), - raw_payload = table.Column(type: "bytea", nullable: true) + raw_payload = table.Column(type: "bytea", nullable: true), + manifest_instructions = table.Column(type: "text", nullable: true), + manifest_classes = table.Column(type: "ledger_transaction_manifest_class[]", nullable: true) }, constraints: table => { table.PrimaryKey("PK_ledger_transactions", x => x.state_version); }); - migrationBuilder.CreateTable( - name: "network_configuration", - columns: table => new - { - id = table.Column(type: "integer", nullable: false), - network_id = table.Column(type: "smallint", nullable: false), - network_name = table.Column(type: "text", nullable: false), - hrp_definition = table.Column(type: "jsonb", nullable: false), - well_known_addresses = table.Column(type: "jsonb", nullable: false), - address_type_definitions = table.Column(type: "jsonb", nullable: false), - genesis_epoch = table.Column(type: "bigint", nullable: false), - genesis_round = table.Column(type: "bigint", nullable: false) - }, - constraints: table => - { - table.PrimaryKey("PK_network_configuration", x => x.id); - }); - migrationBuilder.CreateTable( name: "non_fungible_id_data", columns: table => new @@ -542,6 +559,21 @@ protected override void Up(MigrationBuilder migrationBuilder) table.PrimaryKey("PK_non_fungible_schema_history", x => x.id); }); + migrationBuilder.CreateTable( + name: "package_blueprint_aggregate_history", + columns: table => new + { + id = table.Column(type: "bigint", nullable: false) + .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn), + from_state_version = table.Column(type: "bigint", nullable: false), + package_entity_id = table.Column(type: "bigint", nullable: false), + package_blueprint_ids = table.Column>(type: "bigint[]", nullable: false) + }, + constraints: table => + { + table.PrimaryKey("PK_package_blueprint_aggregate_history", x => x.id); + }); + migrationBuilder.CreateTable( name: "package_blueprint_history", columns: table => new @@ -564,6 +596,21 @@ protected override void Up(MigrationBuilder migrationBuilder) table.PrimaryKey("PK_package_blueprint_history", x => x.id); }); + migrationBuilder.CreateTable( + name: "package_code_aggregate_history", + columns: table => new + { + id = table.Column(type: "bigint", nullable: false) + .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn), + from_state_version = table.Column(type: "bigint", nullable: false), + package_entity_id = table.Column(type: "bigint", nullable: false), + package_code_ids = table.Column>(type: "bigint[]", nullable: false) + }, + constraints: table => + { + table.PrimaryKey("PK_package_code_aggregate_history", x => x.id); + }); + migrationBuilder.CreateTable( name: "package_code_history", columns: table => new @@ -573,7 +620,9 @@ protected override void Up(MigrationBuilder migrationBuilder) from_state_version = table.Column(type: "bigint", nullable: false), package_entity_id = table.Column(type: "bigint", nullable: false), code_hash = table.Column(type: "bytea", nullable: false), - code = table.Column(type: "bytea", nullable: false) + code = table.Column(type: "bytea", nullable: false), + vm_type = table.Column(type: "package_vm_type", nullable: false), + is_deleted = table.Column(type: "boolean", nullable: false) }, constraints: table => { @@ -581,16 +630,34 @@ protected override void Up(MigrationBuilder migrationBuilder) }); migrationBuilder.CreateTable( - name: "pending_transaction_payloads", + name: "pending_transactions", columns: table => new { id = table.Column(type: "bigint", nullable: false) .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn), - notarized_transaction_blob = table.Column(type: "bytea", nullable: false) + payload_hash = table.Column(type: "text", nullable: false), + intent_hash = table.Column(type: "text", nullable: false), + end_epoch_exclusive = table.Column(type: "bigint", nullable: false), + payload_id = table.Column(type: "bigint", nullable: true), + xmin = table.Column(type: "xid", rowVersion: true, nullable: false), + payload_status = table.Column(type: "pending_transaction_payload_ledger_status", nullable: false), + intent_status = table.Column(type: "pending_transaction_intent_ledger_status", nullable: false), + initial_rejection_reason = table.Column(type: "text", nullable: true), + latest_rejection_reason = table.Column(type: "text", nullable: true), + latest_rejection_timestamp = table.Column(type: "timestamp with time zone", nullable: true), + commit_timestamp = table.Column(type: "timestamp with time zone", nullable: true), + resubmit_from_timestamp = table.Column(type: "timestamp with time zone", nullable: true), + handling_status_reason = table.Column(type: "text", nullable: true), + first_submitted_to_gateway_timestamp = table.Column(type: "timestamp with time zone", nullable: false), + node_submission_count = table.Column(type: "integer", nullable: false), + latest_node_submission_timestamp = table.Column(type: "timestamp with time zone", nullable: true), + latest_submitted_to_node_name = table.Column(type: "text", nullable: true), + latest_node_submission_was_accepted = table.Column(type: "boolean", nullable: false), + last_submit_error = table.Column(type: "text", nullable: true) }, constraints: table => { - table.PrimaryKey("PK_pending_transaction_payloads", x => x.id); + table.PrimaryKey("PK_pending_transactions", x => x.id); }); migrationBuilder.CreateTable( @@ -681,38 +748,21 @@ protected override void Up(MigrationBuilder migrationBuilder) }); migrationBuilder.CreateTable( - name: "pending_transactions", + name: "pending_transaction_payloads", columns: table => new { id = table.Column(type: "bigint", nullable: false) .Annotation("Npgsql:ValueGenerationStrategy", NpgsqlValueGenerationStrategy.IdentityByDefaultColumn), - payload_hash = table.Column(type: "text", nullable: false), - intent_hash = table.Column(type: "text", nullable: false), - end_epoch_exclusive = table.Column(type: "numeric(20,0)", nullable: false), - payload_id = table.Column(type: "bigint", nullable: false), - xmin = table.Column(type: "xid", rowVersion: true, nullable: false), - payload_status = table.Column(type: "pending_transaction_payload_ledger_status", nullable: false), - intent_status = table.Column(type: "pending_transaction_intent_ledger_status", nullable: false), - initial_rejection_reason = table.Column(type: "text", nullable: true), - latest_rejection_reason = table.Column(type: "text", nullable: true), - latest_rejection_timestamp = table.Column(type: "timestamp with time zone", nullable: true), - commit_timestamp = table.Column(type: "timestamp with time zone", nullable: true), - resubmit_from_timestamp = table.Column(type: "timestamp with time zone", nullable: true), - handling_status_reason = table.Column(type: "text", nullable: true), - first_submitted_to_gateway_timestamp = table.Column(type: "timestamp with time zone", nullable: false), - node_submission_count = table.Column(type: "integer", nullable: false), - latest_node_submission_timestamp = table.Column(type: "timestamp with time zone", nullable: true), - latest_submitted_to_node_name = table.Column(type: "text", nullable: true), - latest_node_submission_was_accepted = table.Column(type: "boolean", nullable: false), - last_submit_error = table.Column(type: "text", nullable: true) + pending_transaction_id = table.Column(type: "bigint", nullable: true), + notarized_transaction_blob = table.Column(type: "bytea", nullable: false) }, constraints: table => { - table.PrimaryKey("PK_pending_transactions", x => x.id); + table.PrimaryKey("PK_pending_transaction_payloads", x => x.id); table.ForeignKey( - name: "FK_pending_transactions_pending_transaction_payloads_payload_id", - column: x => x.payload_id, - principalTable: "pending_transaction_payloads", + name: "FK_pending_transaction_payloads_pending_transactions_pending_t~", + column: x => x.pending_transaction_id, + principalTable: "pending_transactions", principalColumn: "id", onDelete: ReferentialAction.Cascade); }); @@ -749,6 +799,11 @@ protected override void Up(MigrationBuilder migrationBuilder) table: "account_resource_preference_rule_history", columns: new[] { "account_entity_id", "resource_entity_id", "from_state_version" }); + migrationBuilder.CreateIndex( + name: "IX_component_method_royalty_aggregate_history_entity_id_from_s~", + table: "component_method_royalty_aggregate_history", + columns: new[] { "entity_id", "from_state_version" }); + migrationBuilder.CreateIndex( name: "IX_component_method_royalty_entry_history_entity_id_from_state~", table: "component_method_royalty_entry_history", @@ -844,6 +899,11 @@ protected override void Up(MigrationBuilder migrationBuilder) columns: new[] { "vault_entity_id", "from_state_version" }, filter: "discriminator = 'non_fungible'"); + migrationBuilder.CreateIndex( + name: "IX_key_value_store_aggregate_history_key_value_store_entity_id~", + table: "key_value_store_aggregate_history", + columns: new[] { "key_value_store_entity_id", "from_state_version" }); + migrationBuilder.CreateIndex( name: "IX_key_value_store_entry_history_key_value_store_entity_id_key~", table: "key_value_store_entry_history", @@ -866,6 +926,12 @@ protected override void Up(MigrationBuilder migrationBuilder) columns: new[] { "event_type", "entity_id", "state_version" }, filter: "discriminator = 'event'"); + migrationBuilder.CreateIndex( + name: "IX_ledger_transaction_markers_manifest_class_is_most_specific_~", + table: "ledger_transaction_markers", + columns: new[] { "manifest_class", "is_most_specific", "state_version" }, + filter: "discriminator = 'manifest_class'"); + migrationBuilder.CreateIndex( name: "IX_ledger_transaction_markers_operation_type_entity_id_state_v~", table: "ledger_transaction_markers", @@ -933,6 +999,11 @@ protected override void Up(MigrationBuilder migrationBuilder) table: "non_fungible_schema_history", columns: new[] { "resource_entity_id", "from_state_version" }); + migrationBuilder.CreateIndex( + name: "IX_package_blueprint_aggregate_history_package_entity_id_from_~", + table: "package_blueprint_aggregate_history", + columns: new[] { "package_entity_id", "from_state_version" }); + migrationBuilder.CreateIndex( name: "IX_package_blueprint_history_package_entity_id_from_state_vers~", table: "package_blueprint_history", @@ -943,11 +1014,22 @@ protected override void Up(MigrationBuilder migrationBuilder) table: "package_blueprint_history", columns: new[] { "package_entity_id", "name", "version", "from_state_version" }); + migrationBuilder.CreateIndex( + name: "IX_package_code_aggregate_history_package_entity_id_from_state~", + table: "package_code_aggregate_history", + columns: new[] { "package_entity_id", "from_state_version" }); + migrationBuilder.CreateIndex( name: "IX_package_code_history_package_entity_id_from_state_version", table: "package_code_history", columns: new[] { "package_entity_id", "from_state_version" }); + migrationBuilder.CreateIndex( + name: "IX_pending_transaction_payloads_pending_transaction_id", + table: "pending_transaction_payloads", + column: "pending_transaction_id", + unique: true); + migrationBuilder.CreateIndex( name: "IX_pending_transactions_first_submitted_to_gateway_timestamp", table: "pending_transactions", @@ -964,11 +1046,6 @@ protected override void Up(MigrationBuilder migrationBuilder) column: "payload_hash", unique: true); - migrationBuilder.CreateIndex( - name: "IX_pending_transactions_payload_id", - table: "pending_transactions", - column: "payload_id"); - migrationBuilder.CreateIndex( name: "IX_pending_transactions_resubmit_from_timestamp", table: "pending_transactions", @@ -1012,7 +1089,8 @@ protected override void Up(MigrationBuilder migrationBuilder) migrationBuilder.CreateIndex( name: "IX_validator_emission_statistics_validator_entity_id_epoch_num~", table: "validator_emission_statistics", - columns: new[] { "validator_entity_id", "epoch_number" }); + columns: new[] { "validator_entity_id", "epoch_number" }) + .Annotation("Npgsql:IndexInclude", new[] { "proposals_made", "proposals_missed" }); migrationBuilder.CreateIndex( name: "IX_validator_public_key_history_validator_entity_id_from_state~", @@ -1034,6 +1112,9 @@ protected override void Down(MigrationBuilder migrationBuilder) migrationBuilder.DropTable( name: "account_resource_preference_rule_history"); + migrationBuilder.DropTable( + name: "component_method_royalty_aggregate_history"); + migrationBuilder.DropTable( name: "component_method_royalty_entry_history"); @@ -1067,6 +1148,9 @@ protected override void Down(MigrationBuilder migrationBuilder) migrationBuilder.DropTable( name: "entity_vault_history"); + migrationBuilder.DropTable( + name: "key_value_store_aggregate_history"); + migrationBuilder.DropTable( name: "key_value_store_entry_history"); @@ -1079,9 +1163,6 @@ protected override void Down(MigrationBuilder migrationBuilder) migrationBuilder.DropTable( name: "ledger_transactions"); - migrationBuilder.DropTable( - name: "network_configuration"); - migrationBuilder.DropTable( name: "non_fungible_id_data"); @@ -1097,14 +1178,20 @@ protected override void Down(MigrationBuilder migrationBuilder) migrationBuilder.DropTable( name: "non_fungible_schema_history"); + migrationBuilder.DropTable( + name: "package_blueprint_aggregate_history"); + migrationBuilder.DropTable( name: "package_blueprint_history"); + migrationBuilder.DropTable( + name: "package_code_aggregate_history"); + migrationBuilder.DropTable( name: "package_code_history"); migrationBuilder.DropTable( - name: "pending_transactions"); + name: "pending_transaction_payloads"); migrationBuilder.DropTable( name: "resource_entity_supply_history"); @@ -1122,7 +1209,7 @@ protected override void Down(MigrationBuilder migrationBuilder) name: "validator_emission_statistics"); migrationBuilder.DropTable( - name: "pending_transaction_payloads"); + name: "pending_transactions"); migrationBuilder.DropTable( name: "validator_public_key_history"); diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/IdempotentApplyMigrations.sql b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/IdempotentApplyMigrations.sql index b69e5d09c..dd415beea 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/IdempotentApplyMigrations.sql +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/IdempotentApplyMigrations.sql @@ -9,16 +9,17 @@ START TRANSACTION; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TYPE account_default_deposit_rule AS ENUM ('accept', 'reject', 'allow_existing'); CREATE TYPE account_resource_preference_rule AS ENUM ('allowed', 'disallowed'); CREATE TYPE entity_type AS ENUM ('global_consensus_manager', 'global_fungible_resource', 'global_non_fungible_resource', 'global_generic_component', 'internal_generic_component', 'global_account_component', 'global_package', 'internal_key_value_store', 'internal_fungible_vault', 'internal_non_fungible_vault', 'global_validator', 'global_access_controller', 'global_identity', 'global_one_resource_pool', 'global_two_resource_pool', 'global_multi_resource_pool', 'global_transaction_tracker'); + CREATE TYPE ledger_transaction_manifest_class AS ENUM ('general', 'transfer', 'validator_stake', 'validator_unstake', 'validator_claim', 'account_deposit_settings_update', 'pool_contribution', 'pool_redemption'); CREATE TYPE ledger_transaction_marker_event_type AS ENUM ('withdrawal', 'deposit'); - CREATE TYPE ledger_transaction_marker_operation_type AS ENUM ('resource_in_use', 'account_deposited_into', 'account_withdrawn_from'); + CREATE TYPE ledger_transaction_marker_operation_type AS ENUM ('resource_in_use', 'account_deposited_into', 'account_withdrawn_from', 'account_owner_method_call'); CREATE TYPE ledger_transaction_marker_origin_type AS ENUM ('user', 'epoch_change'); - CREATE TYPE ledger_transaction_marker_type AS ENUM ('origin', 'event', 'manifest_address', 'affected_global_entity'); + CREATE TYPE ledger_transaction_marker_type AS ENUM ('origin', 'event', 'manifest_address', 'affected_global_entity', 'manifest_class'); CREATE TYPE ledger_transaction_status AS ENUM ('succeeded', 'failed'); - CREATE TYPE ledger_transaction_type AS ENUM ('genesis', 'user', 'round_update'); + CREATE TYPE ledger_transaction_type AS ENUM ('genesis', 'user', 'round_update', 'flash'); CREATE TYPE module_id AS ENUM ('main', 'metadata', 'royalty', 'role_assignment'); CREATE TYPE non_fungible_id_type AS ENUM ('string', 'integer', 'bytes', 'ruid'); CREATE TYPE package_vm_type AS ENUM ('native', 'scrypto_v1'); @@ -33,7 +34,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE account_default_deposit_rule_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -46,7 +47,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE account_resource_preference_rule_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -61,7 +62,20 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE TABLE component_method_royalty_aggregate_history ( + id bigint GENERATED BY DEFAULT AS IDENTITY, + from_state_version bigint NOT NULL, + entity_id bigint NOT NULL, + entry_ids bigint[] NOT NULL, + CONSTRAINT "PK_component_method_royalty_aggregate_history" PRIMARY KEY (id) + ); + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE component_method_royalty_entry_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -76,7 +90,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entities ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -91,9 +105,9 @@ BEGIN package_id bigint NULL, blueprint_name text NULL, blueprint_version text NULL, + assigned_module_ids module_id[] NULL, divisibility integer NULL, non_fungible_id_type non_fungible_id_type NULL, - vm_type package_vm_type NULL, stake_vault_entity_id bigint NULL, pending_xrd_withdraw_vault_entity_id bigint NULL, locked_owner_stake_unit_vault_entity_id bigint NULL, @@ -107,7 +121,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entity_metadata_aggregate_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -120,7 +134,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entity_metadata_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -136,7 +150,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entity_resource_aggregate_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -152,7 +166,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entity_resource_aggregated_vaults_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -168,7 +182,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entity_resource_vault_aggregate_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -182,7 +196,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entity_role_assignments_aggregate_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -196,7 +210,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entity_role_assignments_entry_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -212,7 +226,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entity_role_assignments_owner_role_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -225,7 +239,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE entity_vault_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -244,7 +258,20 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE TABLE key_value_store_aggregate_history ( + id bigint GENERATED BY DEFAULT AS IDENTITY, + from_state_version bigint NOT NULL, + key_value_store_entity_id bigint NOT NULL, + key_value_store_entry_ids bigint[] NOT NULL, + CONSTRAINT "PK_key_value_store_aggregate_history" PRIMARY KEY (id) + ); + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE key_value_store_entry_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -260,7 +287,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE key_value_store_schema_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -280,7 +307,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE ledger_transaction_markers ( id bigint GENERATED BY DEFAULT AS IDENTITY, state_version bigint NOT NULL, @@ -290,6 +317,8 @@ BEGIN resource_entity_id bigint NULL, quantity numeric(1000) NULL, operation_type ledger_transaction_marker_operation_type NULL, + manifest_class ledger_transaction_manifest_class NULL, + is_most_specific boolean NULL, origin_type ledger_transaction_marker_origin_type NULL, CONSTRAINT "PK_ledger_transaction_markers" PRIMARY KEY (id) ); @@ -298,7 +327,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE ledger_transactions ( state_version bigint NOT NULL, epoch bigint NOT NULL, @@ -327,6 +356,7 @@ BEGIN receipt_event_schema_hashes bytea[] NOT NULL, receipt_event_type_indexes bigint[] NOT NULL, receipt_event_sbor_type_kinds sbor_type_kind[] NOT NULL, + balance_changes jsonb NULL, transaction_tree_hash text NOT NULL, receipt_tree_hash text NOT NULL, state_tree_hash text NOT NULL, @@ -336,6 +366,8 @@ BEGIN signed_intent_hash text NULL, message jsonb NULL, raw_payload bytea NULL, + manifest_instructions text NULL, + manifest_classes ledger_transaction_manifest_class[] NULL, CONSTRAINT "PK_ledger_transactions" PRIMARY KEY (state_version) ); END IF; @@ -343,24 +375,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN - CREATE TABLE network_configuration ( - id integer NOT NULL, - network_id smallint NOT NULL, - network_name text NOT NULL, - hrp_definition jsonb NOT NULL, - well_known_addresses jsonb NOT NULL, - address_type_definitions jsonb NOT NULL, - genesis_epoch bigint NOT NULL, - genesis_round bigint NOT NULL, - CONSTRAINT "PK_network_configuration" PRIMARY KEY (id) - ); - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE non_fungible_id_data ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -373,7 +388,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE non_fungible_id_data_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -388,7 +403,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE non_fungible_id_location_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -401,7 +416,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE non_fungible_id_store_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -414,7 +429,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE non_fungible_schema_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -430,7 +445,20 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE TABLE package_blueprint_aggregate_history ( + id bigint GENERATED BY DEFAULT AS IDENTITY, + from_state_version bigint NOT NULL, + package_entity_id bigint NOT NULL, + package_blueprint_ids bigint[] NOT NULL, + CONSTRAINT "PK_package_blueprint_aggregate_history" PRIMARY KEY (id) + ); + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE package_blueprint_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -450,13 +478,28 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE TABLE package_code_aggregate_history ( + id bigint GENERATED BY DEFAULT AS IDENTITY, + from_state_version bigint NOT NULL, + package_entity_id bigint NOT NULL, + package_code_ids bigint[] NOT NULL, + CONSTRAINT "PK_package_code_aggregate_history" PRIMARY KEY (id) + ); + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE package_code_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, package_entity_id bigint NOT NULL, code_hash bytea NOT NULL, code bytea NOT NULL, + vm_type package_vm_type NOT NULL, + is_deleted boolean NOT NULL, CONSTRAINT "PK_package_code_history" PRIMARY KEY (id) ); END IF; @@ -464,18 +507,35 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN - CREATE TABLE pending_transaction_payloads ( + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE TABLE pending_transactions ( id bigint GENERATED BY DEFAULT AS IDENTITY, - notarized_transaction_blob bytea NOT NULL, - CONSTRAINT "PK_pending_transaction_payloads" PRIMARY KEY (id) + payload_hash text NOT NULL, + intent_hash text NOT NULL, + end_epoch_exclusive bigint NOT NULL, + payload_id bigint NULL, + payload_status pending_transaction_payload_ledger_status NOT NULL, + intent_status pending_transaction_intent_ledger_status NOT NULL, + initial_rejection_reason text NULL, + latest_rejection_reason text NULL, + latest_rejection_timestamp timestamp with time zone NULL, + commit_timestamp timestamp with time zone NULL, + resubmit_from_timestamp timestamp with time zone NULL, + handling_status_reason text NULL, + first_submitted_to_gateway_timestamp timestamp with time zone NOT NULL, + node_submission_count integer NOT NULL, + latest_node_submission_timestamp timestamp with time zone NULL, + latest_submitted_to_node_name text NULL, + latest_node_submission_was_accepted boolean NOT NULL, + last_submit_error text NULL, + CONSTRAINT "PK_pending_transactions" PRIMARY KEY (id) ); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE resource_entity_supply_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -490,7 +550,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE schema_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -504,7 +564,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE state_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -523,7 +583,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE validator_emission_statistics ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -538,7 +598,7 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE validator_public_key_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -552,36 +612,20 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN - CREATE TABLE pending_transactions ( + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE TABLE pending_transaction_payloads ( id bigint GENERATED BY DEFAULT AS IDENTITY, - payload_hash text NOT NULL, - intent_hash text NOT NULL, - end_epoch_exclusive numeric(20,0) NOT NULL, - payload_id bigint NOT NULL, - payload_status pending_transaction_payload_ledger_status NOT NULL, - intent_status pending_transaction_intent_ledger_status NOT NULL, - initial_rejection_reason text NULL, - latest_rejection_reason text NULL, - latest_rejection_timestamp timestamp with time zone NULL, - commit_timestamp timestamp with time zone NULL, - resubmit_from_timestamp timestamp with time zone NULL, - handling_status_reason text NULL, - first_submitted_to_gateway_timestamp timestamp with time zone NOT NULL, - node_submission_count integer NOT NULL, - latest_node_submission_timestamp timestamp with time zone NULL, - latest_submitted_to_node_name text NULL, - latest_node_submission_was_accepted boolean NOT NULL, - last_submit_error text NULL, - CONSTRAINT "PK_pending_transactions" PRIMARY KEY (id), - CONSTRAINT "FK_pending_transactions_pending_transaction_payloads_payload_id" FOREIGN KEY (payload_id) REFERENCES pending_transaction_payloads (id) ON DELETE CASCADE + pending_transaction_id bigint NULL, + notarized_transaction_blob bytea NOT NULL, + CONSTRAINT "PK_pending_transaction_payloads" PRIMARY KEY (id), + CONSTRAINT "FK_pending_transaction_payloads_pending_transactions_pending_t~" FOREIGN KEY (pending_transaction_id) REFERENCES pending_transactions (id) ON DELETE CASCADE ); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE TABLE validator_active_set_history ( id bigint GENERATED BY DEFAULT AS IDENTITY, from_state_version bigint NOT NULL, @@ -596,580 +640,422 @@ END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_account_default_deposit_rule_history_account_entity_id_from~" ON account_default_deposit_rule_history (account_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_account_resource_preference_rule_history_account_entity_id_~" ON account_resource_preference_rule_history (account_entity_id, resource_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE INDEX "IX_component_method_royalty_aggregate_history_entity_id_from_s~" ON component_method_royalty_aggregate_history (entity_id, from_state_version); + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_component_method_royalty_entry_history_entity_id_from_state~" ON component_method_royalty_entry_history (entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_component_method_royalty_entry_history_entity_id_method_nam~" ON component_method_royalty_entry_history (entity_id, method_name, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE UNIQUE INDEX "IX_entities_address" ON entities (address); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entities_from_state_version" ON entities (from_state_version) WHERE discriminator = 'global_validator'; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_metadata_aggregate_history_entity_id_from_state_vers~" ON entity_metadata_aggregate_history (entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_metadata_history_entity_id_key_from_state_version" ON entity_metadata_history (entity_id, key, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_resource_aggregate_history_entity_id_from_state_vers~" ON entity_resource_aggregate_history (entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_resource_aggregated_vaults_history_entity_id_resourc~" ON entity_resource_aggregated_vaults_history (entity_id, resource_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_resource_vault_aggregate_history_entity_id_resource_~" ON entity_resource_vault_aggregate_history (entity_id, resource_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_role_assignments_aggregate_history_entity_id_from_st~" ON entity_role_assignments_aggregate_history (entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_role_assignments_entry_history_entity_id_key_role_ke~" ON entity_role_assignments_entry_history (entity_id, key_role, key_module, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_role_assignments_owner_role_history_entity_id_from_s~" ON entity_role_assignments_owner_role_history (entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_vault_history_global_entity_id_from_state_version" ON entity_vault_history (global_entity_id, from_state_version) WHERE is_royalty_vault = true; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_vault_history_global_entity_id_vault_entity_id_from_~" ON entity_vault_history (global_entity_id, vault_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_vault_history_id_resource_entity_id_from_state_versi~" ON entity_vault_history (id, resource_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_vault_history_owner_entity_id_from_state_version" ON entity_vault_history (owner_entity_id, from_state_version) WHERE is_royalty_vault = true; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_vault_history_owner_entity_id_vault_entity_id_from_s~" ON entity_vault_history (owner_entity_id, vault_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_entity_vault_history_vault_entity_id_from_state_version" ON entity_vault_history (vault_entity_id, from_state_version) WHERE discriminator = 'non_fungible'; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE INDEX "IX_key_value_store_aggregate_history_key_value_store_entity_id~" ON key_value_store_aggregate_history (key_value_store_entity_id, from_state_version); + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_key_value_store_entry_history_key_value_store_entity_id_key~" ON key_value_store_entry_history (key_value_store_entity_id, key, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_key_value_store_schema_history_key_value_store_entity_id_fr~" ON key_value_store_schema_history (key_value_store_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_ledger_transaction_markers_entity_id_state_version" ON ledger_transaction_markers (entity_id, state_version) WHERE discriminator = 'affected_global_entity'; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_ledger_transaction_markers_event_type_entity_id_state_versi~" ON ledger_transaction_markers (event_type, entity_id, state_version) WHERE discriminator = 'event'; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE INDEX "IX_ledger_transaction_markers_manifest_class_is_most_specific_~" ON ledger_transaction_markers (manifest_class, is_most_specific, state_version) WHERE discriminator = 'manifest_class'; + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_ledger_transaction_markers_operation_type_entity_id_state_v~" ON ledger_transaction_markers (operation_type, entity_id, state_version) WHERE discriminator = 'manifest_address'; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_ledger_transaction_markers_origin_type_state_version" ON ledger_transaction_markers (origin_type, state_version) WHERE discriminator = 'origin'; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_ledger_transaction_markers_state_version" ON ledger_transaction_markers (state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE UNIQUE INDEX "IX_ledger_transactions_epoch_round_in_epoch" ON ledger_transactions (epoch, round_in_epoch) WHERE index_in_round = 0; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_ledger_transactions_intent_hash" ON ledger_transactions USING hash (intent_hash) WHERE intent_hash IS NOT NULL; END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_ledger_transactions_round_timestamp" ON ledger_transactions (round_timestamp); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_non_fungible_id_data_non_fungible_resource_entity_id_from_s~" ON non_fungible_id_data (non_fungible_resource_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE UNIQUE INDEX "IX_non_fungible_id_data_non_fungible_resource_entity_id_non_fu~" ON non_fungible_id_data (non_fungible_resource_entity_id, non_fungible_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_non_fungible_id_data_history_non_fungible_id_data_id_from_s~" ON non_fungible_id_data_history (non_fungible_id_data_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_non_fungible_id_location_history_non_fungible_id_data_id_fr~" ON non_fungible_id_location_history (non_fungible_id_data_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_non_fungible_id_store_history_non_fungible_resource_entity_~" ON non_fungible_id_store_history (non_fungible_resource_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_non_fungible_schema_history_resource_entity_id_from_state_v~" ON non_fungible_schema_history (resource_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE INDEX "IX_package_blueprint_aggregate_history_package_entity_id_from_~" ON package_blueprint_aggregate_history (package_entity_id, from_state_version); + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_package_blueprint_history_package_entity_id_from_state_vers~" ON package_blueprint_history (package_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_package_blueprint_history_package_entity_id_name_version_fr~" ON package_blueprint_history (package_entity_id, name, version, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE INDEX "IX_package_code_aggregate_history_package_entity_id_from_state~" ON package_code_aggregate_history (package_entity_id, from_state_version); + END IF; +END $EF$; + +DO $EF$ +BEGIN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_package_code_history_package_entity_id_from_state_version" ON package_code_history (package_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN - CREATE INDEX "IX_pending_transactions_first_submitted_to_gateway_timestamp" ON pending_transactions (first_submitted_to_gateway_timestamp); + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE UNIQUE INDEX "IX_pending_transaction_payloads_pending_transaction_id" ON pending_transaction_payloads (pending_transaction_id); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN - CREATE INDEX "IX_pending_transactions_intent_hash" ON pending_transactions (intent_hash); + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE INDEX "IX_pending_transactions_first_submitted_to_gateway_timestamp" ON pending_transactions (first_submitted_to_gateway_timestamp); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN - CREATE UNIQUE INDEX "IX_pending_transactions_payload_hash" ON pending_transactions (payload_hash); + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE INDEX "IX_pending_transactions_intent_hash" ON pending_transactions (intent_hash); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN - CREATE INDEX "IX_pending_transactions_payload_id" ON pending_transactions (payload_id); + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE UNIQUE INDEX "IX_pending_transactions_payload_hash" ON pending_transactions (payload_hash); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_pending_transactions_resubmit_from_timestamp" ON pending_transactions (resubmit_from_timestamp); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_resource_entity_supply_history_resource_entity_id_from_stat~" ON resource_entity_supply_history (resource_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_schema_history_entity_id_from_state_version" ON schema_history (entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_schema_history_schema_hash_from_state_version" ON schema_history (schema_hash, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_state_history_entity_id_from_state_version" ON state_history (entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_validator_active_set_history_epoch" ON validator_active_set_history (epoch); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_validator_active_set_history_from_state_version" ON validator_active_set_history (from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_validator_active_set_history_validator_public_key_history_id" ON validator_active_set_history (validator_public_key_history_id); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN - CREATE INDEX "IX_validator_emission_statistics_validator_entity_id_epoch_num~" ON validator_emission_statistics (validator_entity_id, epoch_number); + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN + CREATE INDEX "IX_validator_emission_statistics_validator_entity_id_epoch_num~" ON validator_emission_statistics (validator_entity_id, epoch_number) INCLUDE (proposals_made, proposals_missed); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_validator_public_key_history_validator_entity_id_from_state~" ON validator_public_key_history (validator_entity_id, from_state_version); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN CREATE INDEX "IX_validator_public_key_history_validator_entity_id_key_type_k~" ON validator_public_key_history (validator_entity_id, key_type, key); END IF; END $EF$; DO $EF$ BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20230922041840_InitialCreate') THEN - INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion") - VALUES ('20230922041840_InitialCreate', '7.0.11'); - END IF; -END $EF$; -COMMIT; - -START TRANSACTION; - - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231101101154_InversePendingTransactionPayloadRelationship') THEN - ALTER TABLE pending_transactions DROP CONSTRAINT "FK_pending_transactions_pending_transaction_payloads_payload_id"; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231101101154_InversePendingTransactionPayloadRelationship') THEN - DROP INDEX "IX_pending_transactions_payload_id"; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231101101154_InversePendingTransactionPayloadRelationship') THEN - ALTER TABLE pending_transactions ALTER COLUMN payload_id DROP NOT NULL; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231101101154_InversePendingTransactionPayloadRelationship') THEN - ALTER TABLE pending_transaction_payloads ADD pending_transaction_id bigint NULL; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231101101154_InversePendingTransactionPayloadRelationship') THEN - CREATE UNIQUE INDEX "IX_pending_transaction_payloads_pending_transaction_id" ON pending_transaction_payloads (pending_transaction_id); - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231101101154_InversePendingTransactionPayloadRelationship') THEN - ALTER TABLE pending_transaction_payloads ADD CONSTRAINT "FK_pending_transaction_payloads_pending_transactions_pending_t~" FOREIGN KEY (pending_transaction_id) REFERENCES pending_transactions (id) ON DELETE CASCADE; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231101101154_InversePendingTransactionPayloadRelationship') THEN - UPDATE pending_transaction_payloads ptp SET pending_transaction_id = pt.id FROM pending_transactions pt WHERE pt.payload_id = ptp.id; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231101101154_InversePendingTransactionPayloadRelationship') THEN - DELETE FROM pending_transaction_payloads WHERE id IN (SELECT ptp.id FROM pending_transaction_payloads ptp LEFT JOIN pending_transactions pt ON ptp.id = pt.payload_id WHERE pt.id IS NULL); - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231101101154_InversePendingTransactionPayloadRelationship') THEN - INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion") - VALUES ('20231101101154_InversePendingTransactionPayloadRelationship', '7.0.11'); - END IF; -END $EF$; -COMMIT; - -START TRANSACTION; - - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231122094710_AddLedgerTransactionBalanceChanges') THEN - ALTER TABLE ledger_transactions ADD balance_changes jsonb NULL; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231122094710_AddLedgerTransactionBalanceChanges') THEN - INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion") - VALUES ('20231122094710_AddLedgerTransactionBalanceChanges', '7.0.11'); - END IF; -END $EF$; -COMMIT; - -START TRANSACTION; - - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231130132946_AddNetworkHrpSuffixToNetworkConfiguration') THEN - ALTER TABLE network_configuration ADD network_hrp_suffix text NULL; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231130132946_AddNetworkHrpSuffixToNetworkConfiguration') THEN - update network_configuration set network_hrp_suffix = (select substring(recordset."HrpPrefix"::text,'_(.+)') from network_configuration, jsonb_to_recordset(address_type_definitions) as recordset("HrpPrefix" TEXT) WHERE recordset."HrpPrefix" like '%account%' limit 1) - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20231130132946_AddNetworkHrpSuffixToNetworkConfiguration') THEN - INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion") - VALUES ('20231130132946_AddNetworkHrpSuffixToNetworkConfiguration', '7.0.11'); - END IF; -END $EF$; -COMMIT; - -START TRANSACTION; - - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240119095226_SupportProtocolUpdate') THEN - ALTER TABLE entities DROP COLUMN vm_type; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240119095226_SupportProtocolUpdate') THEN - ALTER TYPE ledger_transaction_type ADD VALUE 'flash'; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240119095226_SupportProtocolUpdate') THEN - ALTER TABLE package_code_history ADD is_deleted boolean NOT NULL DEFAULT FALSE; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240119095226_SupportProtocolUpdate') THEN - ALTER TABLE package_code_history ADD vm_type package_vm_type NOT NULL DEFAULT 'native'::package_vm_type; - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240119095226_SupportProtocolUpdate') THEN - CREATE TABLE package_blueprint_aggregate_history ( - id bigint GENERATED BY DEFAULT AS IDENTITY, - from_state_version bigint NOT NULL, - package_entity_id bigint NOT NULL, - package_blueprint_ids bigint[] NOT NULL, - CONSTRAINT "PK_package_blueprint_aggregate_history" PRIMARY KEY (id) - ); - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240119095226_SupportProtocolUpdate') THEN - CREATE TABLE package_code_aggregate_history ( - id bigint GENERATED BY DEFAULT AS IDENTITY, - from_state_version bigint NOT NULL, - package_entity_id bigint NOT NULL, - package_code_ids bigint[] NOT NULL, - CONSTRAINT "PK_package_code_aggregate_history" PRIMARY KEY (id) - ); - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240119095226_SupportProtocolUpdate') THEN - CREATE INDEX "IX_package_blueprint_aggregate_history_package_entity_id_from_~" ON package_blueprint_aggregate_history (package_entity_id, from_state_version); - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240119095226_SupportProtocolUpdate') THEN - CREATE INDEX "IX_package_code_aggregate_history_package_entity_id_from_state~" ON package_code_aggregate_history (package_entity_id, from_state_version); - END IF; -END $EF$; - -DO $EF$ -BEGIN - IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240119095226_SupportProtocolUpdate') THEN + IF NOT EXISTS(SELECT 1 FROM "__EFMigrationsHistory" WHERE "MigrationId" = '20240207094138_InitialCreate') THEN INSERT INTO "__EFMigrationsHistory" ("MigrationId", "ProductVersion") - VALUES ('20240119095226_SupportProtocolUpdate', '7.0.11'); + VALUES ('20240207094138_InitialCreate', '7.0.11'); END IF; END $EF$; COMMIT; diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/MigrationsDbContextModelSnapshot.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/MigrationsDbContextModelSnapshot.cs index ac091e190..87abfca5f 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/MigrationsDbContextModelSnapshot.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Migrations/MigrationsDbContextModelSnapshot.cs @@ -62,7 +62,7 @@ * permissions under this License. */ -// +// using System; using System.Collections.Generic; using System.Numerics; @@ -70,7 +70,6 @@ using Microsoft.EntityFrameworkCore.Infrastructure; using Microsoft.EntityFrameworkCore.Storage.ValueConversion; using Npgsql.EntityFrameworkCore.PostgreSQL.Metadata; -using RadixDlt.NetworkGateway.Abstractions.Addressing; using RadixDlt.NetworkGateway.Abstractions.Model; using RadixDlt.NetworkGateway.PostgresIntegration; using RadixDlt.NetworkGateway.PostgresIntegration.Models; @@ -92,10 +91,11 @@ protected override void BuildModel(ModelBuilder modelBuilder) NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_default_deposit_rule", new[] { "accept", "reject", "allow_existing" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "account_resource_preference_rule", new[] { "allowed", "disallowed" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "entity_type", new[] { "global_consensus_manager", "global_fungible_resource", "global_non_fungible_resource", "global_generic_component", "internal_generic_component", "global_account_component", "global_package", "internal_key_value_store", "internal_fungible_vault", "internal_non_fungible_vault", "global_validator", "global_access_controller", "global_identity", "global_one_resource_pool", "global_two_resource_pool", "global_multi_resource_pool", "global_transaction_tracker" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_manifest_class", new[] { "general", "transfer", "validator_stake", "validator_unstake", "validator_claim", "account_deposit_settings_update", "pool_contribution", "pool_redemption" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_event_type", new[] { "withdrawal", "deposit" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_operation_type", new[] { "resource_in_use", "account_deposited_into", "account_withdrawn_from" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_operation_type", new[] { "resource_in_use", "account_deposited_into", "account_withdrawn_from", "account_owner_method_call" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_origin_type", new[] { "user", "epoch_change" }); - NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_type", new[] { "origin", "event", "manifest_address", "affected_global_entity" }); + NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_marker_type", new[] { "origin", "event", "manifest_address", "affected_global_entity", "manifest_class" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_status", new[] { "succeeded", "failed" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "ledger_transaction_type", new[] { "genesis", "user", "round_update", "flash" }); NpgsqlModelBuilderExtensions.HasPostgresEnum(modelBuilder, "module_id", new[] { "main", "metadata", "royalty", "role_assignment" }); @@ -173,6 +173,35 @@ protected override void BuildModel(ModelBuilder modelBuilder) b.ToTable("account_resource_preference_rule_history"); }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("EntityId") + .HasColumnType("bigint") + .HasColumnName("entity_id"); + + b.Property>("EntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("entry_ids"); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.HasKey("Id"); + + b.HasIndex("EntityId", "FromStateVersion"); + + b.ToTable("component_method_royalty_aggregate_history"); + }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ComponentMethodRoyaltyEntryHistory", b => { b.Property("Id") @@ -614,6 +643,35 @@ protected override void BuildModel(ModelBuilder modelBuilder) b.UseTphMappingStrategy(); }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreAggregateHistory", b => + { + b.Property("Id") + .ValueGeneratedOnAdd() + .HasColumnType("bigint") + .HasColumnName("id"); + + NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); + + b.Property("FromStateVersion") + .HasColumnType("bigint") + .HasColumnName("from_state_version"); + + b.Property("KeyValueStoreEntityId") + .HasColumnType("bigint") + .HasColumnName("key_value_store_entity_id"); + + b.Property>("KeyValueStoreEntryIds") + .IsRequired() + .HasColumnType("bigint[]") + .HasColumnName("key_value_store_entry_ids"); + + b.HasKey("Id"); + + b.HasIndex("KeyValueStoreEntityId", "FromStateVersion"); + + b.ToTable("key_value_store_aggregate_history"); + }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.KeyValueStoreEntryHistory", b => { b.Property("Id") @@ -900,54 +958,6 @@ protected override void BuildModel(ModelBuilder modelBuilder) b.UseTphMappingStrategy(); }); - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NetworkConfiguration", b => - { - b.Property("Id") - .HasColumnType("integer") - .HasColumnName("id"); - - b.Property("AddressTypeDefinitions") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("address_type_definitions"); - - b.Property("GenesisEpoch") - .HasColumnType("bigint") - .HasColumnName("genesis_epoch"); - - b.Property("GenesisRound") - .HasColumnType("bigint") - .HasColumnName("genesis_round"); - - b.Property("HrpDefinition") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("hrp_definition"); - - b.Property("NetworkHrpSuffix") - .IsRequired() - .HasColumnType("text") - .HasColumnName("network_hrp_suffix"); - - b.Property("NetworkId") - .HasColumnType("smallint") - .HasColumnName("network_id"); - - b.Property("NetworkName") - .IsRequired() - .HasColumnType("text") - .HasColumnName("network_name"); - - b.Property("WellKnownAddresses") - .IsRequired() - .HasColumnType("jsonb") - .HasColumnName("well_known_addresses"); - - b.HasKey("Id"); - - b.ToTable("network_configuration"); - }); - modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.NonFungibleIdData", b => { b.Property("Id") @@ -1284,8 +1294,8 @@ protected override void BuildModel(ModelBuilder modelBuilder) NpgsqlPropertyBuilderExtensions.UseIdentityByDefaultColumn(b.Property("Id")); - b.Property("EndEpochExclusive") - .HasColumnType("numeric(20,0)") + b.Property("EndEpochExclusive") + .HasColumnType("bigint") .HasColumnName("end_epoch_exclusive"); b.Property("IntentHash") @@ -1520,6 +1530,8 @@ protected override void BuildModel(ModelBuilder modelBuilder) b.HasIndex("ValidatorEntityId", "EpochNumber"); + NpgsqlIndexBuilderExtensions.IncludeProperties(b.HasIndex("ValidatorEntityId", "EpochNumber"), new[] { "ProposalsMade", "ProposalsMissed" }); + b.ToTable("validator_emission_statistics"); }); @@ -1562,6 +1574,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1588,6 +1606,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1614,6 +1638,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1640,6 +1670,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1670,6 +1706,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1696,6 +1738,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1722,6 +1770,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1748,6 +1802,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1778,6 +1838,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1804,6 +1870,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1830,6 +1902,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1856,6 +1934,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1882,6 +1966,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1924,6 +2014,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1959,6 +2055,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -1994,6 +2096,12 @@ protected override void BuildModel(ModelBuilder modelBuilder) { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.Entity"); + b.Property>("AssignedModuleIds") + .IsRequired() + .ValueGeneratedOnUpdateSometimes() + .HasColumnType("module_id[]") + .HasColumnName("assigned_module_ids"); + b.Property("BlueprintName") .IsRequired() .ValueGeneratedOnUpdateSometimes() @@ -2116,6 +2224,16 @@ protected override void BuildModel(ModelBuilder modelBuilder) .HasColumnType("text") .HasColumnName("intent_hash"); + b.Property("ManifestClasses") + .IsRequired() + .HasColumnType("ledger_transaction_manifest_class[]") + .HasColumnName("manifest_classes"); + + b.Property("ManifestInstructions") + .IsRequired() + .HasColumnType("text") + .HasColumnName("manifest_instructions"); + b.Property("Message") .HasColumnType("jsonb") .HasColumnName("message"); @@ -2213,6 +2331,26 @@ protected override void BuildModel(ModelBuilder modelBuilder) b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestAddress); }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.ManifestClassMarker", b => + { + b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); + + b.Property("IsMostSpecific") + .HasColumnType("boolean") + .HasColumnName("is_most_specific"); + + b.Property("LedgerTransactionManifestClass") + .HasColumnType("ledger_transaction_manifest_class") + .HasColumnName("manifest_class"); + + b.HasIndex("LedgerTransactionManifestClass", "IsMostSpecific", "StateVersion") + .HasFilter("discriminator = 'manifest_class'"); + + b.ToTable("ledger_transaction_markers"); + + b.HasDiscriminator().HasValue(LedgerTransactionMarkerType.ManifestClass); + }); + modelBuilder.Entity("RadixDlt.NetworkGateway.PostgresIntegration.Models.OriginLedgerTransactionMarker", b => { b.HasBaseType("RadixDlt.NetworkGateway.PostgresIntegration.Models.LedgerTransactionMarker"); diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeConfigProvider.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/ComponentMethodRoyaltyAggregateHistory.cs similarity index 87% rename from src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeConfigProvider.cs rename to src/RadixDlt.NetworkGateway.PostgresIntegration/Models/ComponentMethodRoyaltyAggregateHistory.cs index ba9d3ca3d..da1a281ac 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/NodeConfigProvider.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/ComponentMethodRoyaltyAggregateHistory.cs @@ -62,22 +62,25 @@ * permissions under this License. */ -using RadixDlt.NetworkGateway.DataAggregator.Configuration; +using System.Collections.Generic; +using System.ComponentModel.DataAnnotations; +using System.ComponentModel.DataAnnotations.Schema; -namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices; +namespace RadixDlt.NetworkGateway.PostgresIntegration.Models; -public interface INodeConfigProvider +[Table("component_method_royalty_aggregate_history")] +public class ComponentMethodRoyaltyAggregateHistory { - public CoreApiNode CoreApiNode { get; set; } -} + [Key] + [Column("id")] + public long Id { get; set; } -internal class NodeConfigProvider : INodeConfigProvider -{ - private CoreApiNode? _nodeAppSettings; + [Column("from_state_version")] + public long FromStateVersion { get; set; } + + [Column("entity_id")] + public long EntityId { get; set; } - public CoreApiNode CoreApiNode - { - get => _nodeAppSettings ?? throw new InvalidNodeStateException("NodeAppSettings in NodeConfigProvider should be set at init time"); - set => _nodeAppSettings = value; - } + [Column("entry_ids")] + public List EntryIds { get; set; } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/ComponentRoyaltyEntryHistory.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/ComponentMethodRoyaltyEntryHistory.cs similarity index 100% rename from src/RadixDlt.NetworkGateway.PostgresIntegration/Models/ComponentRoyaltyEntryHistory.cs rename to src/RadixDlt.NetworkGateway.PostgresIntegration/Models/ComponentMethodRoyaltyEntryHistory.cs diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/Entity.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/Entity.cs index 7f32acc54..64368a85b 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/Entity.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/Entity.cs @@ -145,6 +145,9 @@ internal abstract class ComponentEntity : Entity [Column("blueprint_version")] public string BlueprintVersion { get; set; } + [Column("assigned_module_ids")] + public List AssignedModuleIds { get; set; } + public override List CorrelatedEntities { get diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/KeyValueStoreAggregateHistory.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/KeyValueStoreAggregateHistory.cs new file mode 100644 index 000000000..fdc834075 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/KeyValueStoreAggregateHistory.cs @@ -0,0 +1,86 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using System.Collections.Generic; +using System.ComponentModel.DataAnnotations; +using System.ComponentModel.DataAnnotations.Schema; + +namespace RadixDlt.NetworkGateway.PostgresIntegration.Models; + +[Table("key_value_store_aggregate_history")] +internal class KeyValueStoreAggregateHistory +{ + [Key] + [Column("id")] + public long Id { get; set; } + + [Column("from_state_version")] + public long FromStateVersion { get; set; } + + [Column("key_value_store_entity_id")] + public long KeyValueStoreEntityId { get; set; } + + [Column("key_value_store_entry_ids")] + public List KeyValueStoreEntryIds { get; set; } +} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/LedgerTransaction.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/LedgerTransaction.cs index 0d9544d90..cb57c3491 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/LedgerTransaction.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/LedgerTransaction.cs @@ -232,6 +232,12 @@ internal class UserLedgerTransaction : LedgerTransaction /// [Column("raw_payload")] public byte[] RawPayload { get; set; } + + [Column("manifest_instructions")] + public string ManifestInstructions { get; set; } + + [Column("manifest_classes")] + public LedgerTransactionManifestClass[] ManifestClasses { get; set; } } internal class RoundUpdateLedgerTransaction : LedgerTransaction diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/LedgerTransactionMarker.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/LedgerTransactionMarker.cs index 039f2b5e4..a11e53b47 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/LedgerTransactionMarker.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/LedgerTransactionMarker.cs @@ -62,6 +62,7 @@ * permissions under this License. */ +using RadixDlt.NetworkGateway.Abstractions.Model; using RadixDlt.NetworkGateway.Abstractions.Numerics; using System.ComponentModel.DataAnnotations; using System.ComponentModel.DataAnnotations.Schema; @@ -85,6 +86,7 @@ internal enum LedgerTransactionMarkerOperationType ResourceInUse, AccountDepositedInto, AccountWithdrawnFrom, + AccountOwnerMethodCall, } [Table("ledger_transaction_markers")] @@ -119,6 +121,15 @@ internal class EventLedgerTransactionMarker : LedgerTransactionMarker public TokenAmount Quantity { get; set; } } +internal class ManifestClassMarker : LedgerTransactionMarker +{ + [Column("manifest_class")] + public LedgerTransactionManifestClass LedgerTransactionManifestClass { get; set; } + + [Column("is_most_specific")] + public bool IsMostSpecific { get; set; } +} + internal class ManifestAddressLedgerTransactionMarker : LedgerTransactionMarker { [Column("operation_type")] diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/NetworkConfiguration.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/NetworkConfiguration.cs deleted file mode 100644 index 0adfd46d9..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/NetworkConfiguration.cs +++ /dev/null @@ -1,119 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using RadixDlt.NetworkGateway.Abstractions.Addressing; -using System.ComponentModel.DataAnnotations; -using System.ComponentModel.DataAnnotations.Schema; -using System.Linq; - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Models; - -[Table("network_configuration")] -internal class NetworkConfiguration -{ - [Key] - [Column(name: "id")] - [DatabaseGenerated(DatabaseGeneratedOption.None)] - public int Id - { - get { return 1; } - // ReSharper disable once ValueParameterNotUsed - set { } - } - - [Column("network_id")] - public byte NetworkId { get; set; } - - [Column("network_name")] - public string NetworkName { get; set; } - - [Column("network_hrp_suffix")] - public string NetworkHrpSuffix { get; set; } - - [Column("hrp_definition", TypeName = "jsonb")] - public HrpDefinition HrpDefinition { get; set; } - - [Column("well_known_addresses", TypeName = "jsonb")] - public WellKnownAddresses WellKnownAddresses { get; set; } - - [Column("address_type_definitions", TypeName = "jsonb")] - public AddressTypeDefinition[] AddressTypeDefinitions { get; set; } - - [Column("genesis_epoch")] - public long GenesisEpoch { get; set; } - - [Column("genesis_round")] - public long GenesisRound { get; set; } - - public bool HasEqualConfiguration(NetworkConfiguration other) - { - return NetworkId == other.NetworkId - && NetworkName == other.NetworkName - && HrpDefinition == other.HrpDefinition - && WellKnownAddresses == other.WellKnownAddresses - && AddressTypeDefinitions.SequenceEqual(other.AddressTypeDefinitions) - && GenesisEpoch == other.GenesisEpoch - && GenesisRound == other.GenesisRound; - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/PendingTransaction.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/PendingTransaction.cs index a38a0a8e5..db8f27082 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/PendingTransaction.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Models/PendingTransaction.cs @@ -99,7 +99,7 @@ internal class PendingTransaction /// The epoch at which this transaction will no longer be valid. /// [Column("end_epoch_exclusive")] - public ulong EndEpochExclusive { get; private set; } + public long EndEpochExclusive { get; private set; } [Obsolete($"Use {nameof(PendingTransactionPayload.PendingTransaction)} to navigate.")] [Column("payload_id")] @@ -126,7 +126,7 @@ public static PendingTransaction NewAsSubmittedForFirstTimeToGateway( PendingTransactionHandlingConfig handlingConfig, string payloadHash, string intentHash, - ulong endEpochExclusive, + long endEpochExclusive, byte[] notarizedTransaction, DateTime timestamp ) @@ -151,7 +151,7 @@ public void HandleNodeSubmissionResult( string submittedToNodeName, NodeSubmissionResult nodeSubmissionResult, DateTime handledAt, - ulong? currentEpoch + long? currentEpoch ) { LedgerDetails.HandleSubmissionResult(nodeSubmissionResult, handledAt); @@ -175,7 +175,7 @@ DateTime markedCommittedAt public bool UpdateForPendingSubmissionOrRetirement( PendingTransactionHandlingConfig handlingConfig, DateTime currentTime, - ulong? currentEpoch) + long? currentEpoch) { var retired = RetireIfNecessary(handlingConfig, currentTime, currentEpoch); if (!retired) @@ -193,7 +193,7 @@ public bool UpdateForPendingSubmissionOrRetirement( private bool RetireIfNecessary( PendingTransactionHandlingConfig handlingConfig, DateTime currentTime, - ulong? currentEpoch) + long? currentEpoch) { if (LedgerDetails.PayloadLedgerStatus.ShouldStopSubmittingTransactionToNetwork()) { diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/ScryptoSborUtils.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/ScryptoSborUtils.cs index 6aa42f201..674865bc6 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/ScryptoSborUtils.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/ScryptoSborUtils.cs @@ -92,7 +92,7 @@ public static string DataToProgrammaticJsonString(byte[] data, byte[] schemaByte var schema = new ToolkitModel.Schema(typeIndex, schemaBytes); - return ToolkitModel.RadixEngineToolkitUniffiMethods.SborDecodeToStringRepresentation(data, ToolkitModel.SerializationMode.PROGRAMMATIC, networkId, schema); + return ToolkitModel.RadixEngineToolkitUniffiMethods.SborDecodeToStringRepresentation(data, ToolkitModel.SerializationMode.Programmatic, networkId, schema); } public static GatewayModel.ProgrammaticScryptoSborValue DataToProgrammaticJson(byte[] data, byte[] schemaBytes, SborTypeKind keyTypeKind, long schemaIndex, byte networkId) @@ -104,14 +104,14 @@ public static GatewayModel.ProgrammaticScryptoSborValue DataToProgrammaticJson(b public static GatewayModel.ProgrammaticScryptoSborValue DataToProgrammaticJson(byte[] rawScryptoSbor, byte networkId) { - var json = ToolkitModel.RadixEngineToolkitUniffiMethods.ScryptoSborDecodeToStringRepresentation(rawScryptoSbor, ToolkitModel.SerializationMode.PROGRAMMATIC, networkId, null); + var json = ToolkitModel.RadixEngineToolkitUniffiMethods.ScryptoSborDecodeToStringRepresentation(rawScryptoSbor, ToolkitModel.SerializationMode.Programmatic, networkId, null); return JsonConvert.DeserializeObject(json) ?? throw new ArgumentException("Invalid input Scrypto SBOR"); } public static GatewayModel.ProgrammaticScryptoSborValueBytes DataToProgrammaticScryptoSborValueBytes(byte[] rawScryptoSbor, byte networkId) { - var json = ToolkitModel.RadixEngineToolkitUniffiMethods.ScryptoSborDecodeToStringRepresentation(rawScryptoSbor, ToolkitModel.SerializationMode.PROGRAMMATIC, networkId, null); + var json = ToolkitModel.RadixEngineToolkitUniffiMethods.ScryptoSborDecodeToStringRepresentation(rawScryptoSbor, ToolkitModel.SerializationMode.Programmatic, networkId, null); return JsonConvert.DeserializeObject(json) ?? throw new ArgumentException("Invalid input Scrypto SBOR"); } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/ServiceCollectionExtensions.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/ServiceCollectionExtensions.cs index 82980a59f..9650e5e93 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/ServiceCollectionExtensions.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/ServiceCollectionExtensions.cs @@ -104,6 +104,7 @@ internal static IServiceCollection AddNpgsqlDataSourceHolder(this IServiceCol dataSourceBuilder.MapEnum(); dataSourceBuilder.MapEnum(); dataSourceBuilder.MapEnum(); + dataSourceBuilder.MapEnum(); dataSourceBuilder.MapEnum(); dataSourceBuilder.MapEnum(); dataSourceBuilder.MapEnum(); diff --git a/src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionOutcomeServiceObserver.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/CursorGenerator.cs similarity index 89% rename from src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionOutcomeServiceObserver.cs rename to src/RadixDlt.NetworkGateway.PostgresIntegration/Services/CursorGenerator.cs index c53f0087c..fd37a704f 100644 --- a/src/RadixDlt.NetworkGateway.GatewayApi/Services/ITransactionOutcomeServiceObserver.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/CursorGenerator.cs @@ -62,18 +62,15 @@ * permissions under this License. */ -using System; -using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; +namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; -namespace RadixDlt.NetworkGateway.GatewayApi.Services; - -public interface ITransactionOutcomeServiceObserver +public static class CursorGenerator { - ValueTask PreHandleOutcomeRequest(long stateVersion, string targetNode); - - ValueTask PostHandleOutcomeRequest(long stateVersion, string targetNode); - - ValueTask HandleOutcomeRequestFailed(long stateVersion, string targetNode, Exception exception); + public static string? GenerateOffsetCursor(int offset, int limit, long totalCount) + { + return offset + limit < totalCount + ? new GatewayModel.OffsetCursor(offset + limit).ToCursorString() + : null; + } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.cs index 9f2dfb054..e189ed4a7 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.cs @@ -65,11 +65,10 @@ using Dapper; using Microsoft.EntityFrameworkCore; using Microsoft.Extensions.Options; -using Newtonsoft.Json; using Newtonsoft.Json.Linq; using RadixDlt.NetworkGateway.Abstractions; using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.Abstractions.Model; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.Abstractions.Numerics; using RadixDlt.NetworkGateway.GatewayApi.Configuration; using RadixDlt.NetworkGateway.GatewayApi.Exceptions; @@ -78,7 +77,6 @@ using System; using System.Collections.Generic; using System.Diagnostics; -using System.Diagnostics.CodeAnalysis; using System.Globalization; using System.Linq; using System.Threading; @@ -108,8 +106,6 @@ private record ValidatorCurrentStakeViewModel( private record RoyaltyVaultBalanceViewModel(long RoyaltyVaultEntityId, string Balance, long OwnerEntityId, long LastUpdatedAtStateVersion); - private record KeyValueStoreSchemaModel(byte[] KeySchema, long KeyTypeIndex, SborTypeKind KeySborTypeKind, byte[] ValueSchema, long ValueTypeIndex, SborTypeKind ValueSborTypeKind); - private record struct ExplicitMetadataLookup(long EntityId, string MetadataKey); private readonly TokenAmount _tokenAmount100 = TokenAmount.FromDecimalString("100"); @@ -238,10 +234,10 @@ public EntityStateQuerier( if (packageCodeHistory.TryGetValue(pe.Id, out var packageCodes)) { codeItems.AddRange(packageCodes.Select(pb => new GatewayModel.PackageCodeCollectionItem( - vmType: pb.VmType.ToGatewayModel(), - codeHashHex: pb.CodeHash.ToHex(), - codeHex: pb.Code.ToHex() - ))); + vmType: pb.VmType.ToGatewayModel(), + codeHashHex: pb.CodeHash.ToHex(), + codeHex: pb.Code.ToHex() + ))); } if (packageSchemaHistory.TryGetValue(pe.Id, out var packageSchemas)) @@ -263,7 +259,7 @@ public EntityStateQuerier( case VirtualIdentityEntity: case VirtualAccountComponentEntity: - var virtualEntityData = _virtualEntityDataProvider.GetVirtualEntityData(entity.Address); + var virtualEntityData = await _virtualEntityDataProvider.GetVirtualEntityData(entity.Address); details = virtualEntityData.Details; metadata[entity.Id] = virtualEntityData.Metadata; @@ -288,7 +284,7 @@ public EntityStateQuerier( if (optIns.NonFungibleIncludeNfids && nonFungibleVaultHistory.NonFungibleIdsAndOneMore.Any()) { nfItems = nonFungibleVaultHistory.NonFungibleIdsAndOneMore.Take(_endpointConfiguration.Value.DefaultPageSize).ToList(); - nfNextCursor = GenerateOffsetCursor(0, _endpointConfiguration.Value.DefaultPageSize, nonFungibleVaultHistory.NonFungibleIdsCount); + nfNextCursor = CursorGenerator.GenerateOffsetCursor(0, _endpointConfiguration.Value.DefaultPageSize, nonFungibleVaultHistory.NonFungibleIdsCount); } details = new GatewayModel.StateEntityDetailsResponseNonFungibleVaultDetails( @@ -447,7 +443,7 @@ public EntityStateQuerier( if (nonFungibleIdsAndOneMorePerVault?.TryGetValue(x.VaultEntityId, out var nfids) == true) { items = nfids.Take(nonFungibleIdsLimit).Select(y => y.NonFungibleId).ToList(); - nextCursor = GenerateOffsetCursor(0, nonFungibleIdsLimit, x.NonFungibleIdsCount); + nextCursor = CursorGenerator.GenerateOffsetCursor(0, nonFungibleIdsLimit, x.NonFungibleIdsCount); } return new GatewayModel.NonFungibleResourcesCollectionItemVaultAggregatedVaultItem( @@ -462,7 +458,7 @@ public EntityStateQuerier( .ToList(); var vaultsTotalCount = nonFungibles.FirstOrDefault()?.VaultTotalCount ?? 0; - var nextCursor = GenerateOffsetCursor(request.Offset, request.Limit, vaultsTotalCount); + var nextCursor = CursorGenerator.GenerateOffsetCursor(request.Offset, request.Limit, vaultsTotalCount); return new GatewayModel.StateEntityNonFungibleResourceVaultsPageResponse(ledgerState, vaultsTotalCount, nextCursor, mapped, entity.Address, resourceEntity.Address); } @@ -513,7 +509,7 @@ public EntityStateQuerier( if (entity is VirtualIdentityEntity or VirtualAccountComponentEntity) { - var (_, virtualEntityMetadata) = _virtualEntityDataProvider.GetVirtualEntityData(entity.Address); + var (_, virtualEntityMetadata) = await _virtualEntityDataProvider.GetVirtualEntityData(entity.Address); metadata = virtualEntityMetadata; } else @@ -598,7 +594,7 @@ FROM most_recent_non_fungible_id_store_history_slice hs resourceAddress: request.Address.ToString(), nonFungibleIds: new GatewayModel.NonFungibleIdsCollection( totalCount: totalCount, - nextCursor: GenerateOffsetCursor(request.Offset, request.Limit, totalCount), + nextCursor: CursorGenerator.GenerateOffsetCursor(request.Offset, request.Limit, totalCount), items: items)); } @@ -669,7 +665,7 @@ ORDER BY nfid.from_state_version DESC { var programmaticJson = !vm.IsDeleted ? ScryptoSborUtils.DataToProgrammaticJson(vm.Data, nonFungibleDataSchema.Schema, - nonFungibleDataSchema.SborTypeKind, nonFungibleDataSchema.TypeIndex, _networkConfigurationProvider.GetNetworkId()) + nonFungibleDataSchema.SborTypeKind, nonFungibleDataSchema.TypeIndex, (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Id) : null; items.Add(new GatewayModel.StateNonFungibleDetailsResponseItem( @@ -934,90 +930,6 @@ LIMIT 1 return new GatewayModel.StateValidatorsListResponse(ledgerState, new GatewayModel.ValidatorCollection(null, nextCursor, items)); } - public async Task KeyValueStoreData( - EntityAddress keyValueStoreAddress, - IList keys, - GatewayModel.LedgerState ledgerState, - CancellationToken token = default) - { - var keyValueStore = await GetEntity(keyValueStoreAddress, ledgerState, token); - - var keyValueStoreSchemaQuery = new CommandDefinition( - commandText: @" -SELECT - ksh.schema AS KeySchema, - kvssh.key_type_index AS KeyTypeIndex, - kvssh.key_sbor_type_kind AS KeySborTypeKind, - vsh.schema AS ValueSchema, - kvssh.value_type_index AS ValueTypeIndex, - kvssh.value_sbor_type_kind AS ValueSborTypeKind -FROM key_value_store_schema_history kvssh -INNER JOIN schema_history ksh ON ksh.schema_hash = kvssh.key_schema_hash AND ksh.entity_id = kvssh.key_schema_defining_entity_id -INNER JOIN schema_history vsh ON vsh.schema_hash = kvssh.value_schema_hash AND vsh.entity_id = kvssh.value_schema_defining_entity_id -WHERE kvssh.key_value_store_entity_id = @entityId AND kvssh.from_state_version <= @stateVersion -ORDER BY kvssh.from_state_version DESC -", - parameters: new - { - stateVersion = ledgerState.StateVersion, - entityId = keyValueStore.Id, - }, - cancellationToken: token); - - var keyValueStoreSchema = await _dapperWrapper.QueryFirstOrDefaultAsync( - _dbContext.Database.GetDbConnection(), keyValueStoreSchemaQuery, "GetKeyValueStoreSchema" - ); - - if (keyValueStoreSchema == null) - { - throw new UnreachableException($"Missing key value store schema for :{keyValueStoreAddress}"); - } - - var dbKeys = keys.Distinct().Select(k => (byte[])k).ToList(); - - var entries = await _dbContext - .KeyValueStoreEntryHistory - .FromSqlInterpolated(@$" -WITH variables (key) AS ( - SELECT UNNEST({dbKeys}) -) -SELECT kvseh.* -FROM variables -INNER JOIN LATERAL ( - SELECT * - FROM key_value_store_entry_history - WHERE key_value_store_entity_id = {keyValueStore.Id} AND key = variables.key AND from_state_version <= {ledgerState.StateVersion} - ORDER BY from_state_version DESC - LIMIT 1 -) kvseh ON TRUE;") - .AnnotateMetricName("GetKeyValueStores") - .ToListAsync(token); - - var items = new List(); - - foreach (var e in entries) - { - if (e.IsDeleted) - { - continue; - } - - var keyProgrammaticJson = ScryptoSborUtils.DataToProgrammaticJson(e.Key, keyValueStoreSchema.KeySchema, keyValueStoreSchema.KeySborTypeKind, - keyValueStoreSchema.KeyTypeIndex, _networkConfigurationProvider.GetNetworkId()); - - var valueProgrammaticJson = ScryptoSborUtils.DataToProgrammaticJson(e.Value, keyValueStoreSchema.ValueSchema, keyValueStoreSchema.ValueSborTypeKind, - keyValueStoreSchema.ValueTypeIndex, _networkConfigurationProvider.GetNetworkId()); - - items.Add(new GatewayModel.StateKeyValueStoreDataResponseItem( - key: new GatewayModel.ScryptoSborValue(e.Key.ToHex(), keyProgrammaticJson), - value: new GatewayModel.ScryptoSborValue(e.Value.ToHex(), valueProgrammaticJson), - lastUpdatedAtStateVersion: e.FromStateVersion, - isLocked: e.IsLocked)); - } - - return new GatewayModel.StateKeyValueStoreDataResponse(ledgerState, keyValueStoreAddress, items); - } - private async Task> RoyaltyVaultBalance(long[] ownerIds, GatewayModel.LedgerState ledgerState, CancellationToken token = default) { var cd = new CommandDefinition( @@ -1091,11 +1003,12 @@ INNER JOIN LATERAL UNNEST(metadata_slice) WITH ORDINALITY AS metadata_join(id, o { if (!result.ContainsKey(vm.EntityId)) { - result[vm.EntityId] = new GatewayModel.EntityMetadataCollection(vm.TotalCount, GenerateOffsetCursor(offset, limit, vm.TotalCount), new List()); + result[vm.EntityId] = new GatewayModel.EntityMetadataCollection(vm.TotalCount, CursorGenerator.GenerateOffsetCursor(offset, limit, vm.TotalCount), new List()); } - var value = ScryptoSborUtils.DecodeToGatewayMetadataItemValue(vm.Value, _networkConfigurationProvider.GetNetworkId()); - var programmaticJson = ScryptoSborUtils.DataToProgrammaticJson(vm.Value, _networkConfigurationProvider.GetNetworkId()); + var networkId = (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Id; + var value = ScryptoSborUtils.DecodeToGatewayMetadataItemValue(vm.Value, networkId); + var programmaticJson = ScryptoSborUtils.DataToProgrammaticJson(vm.Value, networkId); var entityMetadataItemValue = new GatewayModel.EntityMetadataItemValue(vm.Value.ToHex(), programmaticJson, value); result[vm.EntityId].Items.Add(new GatewayModel.EntityMetadataItem(vm.Key, entityMetadataItemValue, vm.IsLocked, vm.FromStateVersion)); @@ -1165,8 +1078,9 @@ LIMIT 1 result[mh.EntityId] = new GatewayModel.EntityMetadataCollection(items: new List()); } - var value = ScryptoSborUtils.DecodeToGatewayMetadataItemValue(mh.Value, _networkConfigurationProvider.GetNetworkId()); - var programmaticJson = ScryptoSborUtils.DataToProgrammaticJson(mh.Value, _networkConfigurationProvider.GetNetworkId()); + var networkId = (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Id; + var value = ScryptoSborUtils.DecodeToGatewayMetadataItemValue(mh.Value, networkId); + var programmaticJson = ScryptoSborUtils.DataToProgrammaticJson(mh.Value, networkId); var entityMetadataItemValue = new GatewayModel.EntityMetadataItemValue(mh.Value.ToHex(), programmaticJson, value); result[mh.EntityId].Items.Add(new GatewayModel.EntityMetadataItem(mh.Key, entityMetadataItemValue, mh.IsLocked, mh.FromStateVersion)); @@ -1241,7 +1155,7 @@ order by ah.ord lastUpdatedAtStateVersion: vm.LastUpdatedAtStateVersion)); } - return new GatewayModel.FungibleResourcesCollection(totalCount, GenerateOffsetCursor(offset, limit, totalCount), items); + return new GatewayModel.FungibleResourcesCollection(totalCount, CursorGenerator.GenerateOffsetCursor(offset, limit, totalCount), items); } private async Task> GetResourcesSupplyData(long[] entityIds, GatewayModel.LedgerState ledgerState, CancellationToken token) @@ -1286,9 +1200,11 @@ private async Task GetEntity(EntityAddress address, GatewayMod if (entity == null) { - // TODO this method should return null/throw on missing, virtual component handling should be done upstream to avoid entity.Id = 0 uses, see https://github.com/radixdlt/babylon-gateway/pull/171#discussion_r1111957627 - if (!TryGetVirtualEntity(address, out entity)) + entity = await TryResolveAsVirtualEntity(address); + + if (entity == null) { + // TODO this method should return null/throw on missing, virtual component handling should be done upstream to avoid entity.Id = 0 uses, see https://github.com/radixdlt/babylon-gateway/pull/171#discussion_r1111957627 throw new EntityNotFoundException(address.ToString()); } } @@ -1301,25 +1217,19 @@ private async Task GetEntity(EntityAddress address, GatewayMod return typedEntity; } - private bool TryGetVirtualEntity(EntityAddress address, [NotNullWhen(true)] out Entity? entity) + private async Task TryResolveAsVirtualEntity(EntityAddress address) { - if (_virtualEntityDataProvider.IsVirtualAccountAddress(address)) + if (await _virtualEntityDataProvider.IsVirtualAccountAddress(address)) { - entity = new VirtualAccountComponentEntity(address); - - return true; + return new VirtualAccountComponentEntity(address); } - if (_virtualEntityDataProvider.IsVirtualIdentityAddress(address)) + if (await _virtualEntityDataProvider.IsVirtualIdentityAddress(address)) { - entity = new VirtualIdentityEntity(address); - - return true; + return new VirtualIdentityEntity(address); } - entity = default; - - return false; + return null; } private async Task> GetEntities(List addresses, GatewayModel.LedgerState ledgerState, CancellationToken token) @@ -1328,17 +1238,19 @@ private async Task> GetEntities(List addresse .Entities .Where(e => e.FromStateVersion <= ledgerState.StateVersion && addresses.Contains(e.Address)) .AnnotateMetricName() - .ToListAsync(token); + .ToDictionaryAsync(e => e.Address, token); - foreach (var address in addresses) + foreach (var address in addresses.Except(entities.Keys)) { - if (entities.All(e => e.Address != address) && TryGetVirtualEntity(address, out var virtualEntity)) + var virtualEntity = await TryResolveAsVirtualEntity(address); + + if (virtualEntity != null) { - entities.Add(virtualEntity); + entities.Add(virtualEntity.Address, virtualEntity); } } - return entities; + return entities.Values; } private async Task> GetStateHistory(ICollection componentEntities, GatewayModel.LedgerState ledgerState, CancellationToken token = default) @@ -1432,7 +1344,7 @@ LIMIT 1 schemaBytes!, sborStateHistory.SborTypeKind, sborStateHistory.TypeIndex, - _networkConfigurationProvider.GetNetworkId()); + (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Id); result.Add(state.EntityId, jsonState); break; @@ -1606,11 +1518,4 @@ private async Task> ResolveResourceEntityIds( .AnnotateMetricName() .ToDictionaryAsync(e => e.Address, e => e.Id, token); } - - private string? GenerateOffsetCursor(int offset, int limit, long totalCount) - { - return offset + limit < totalCount - ? new GatewayModel.OffsetCursor(offset + limit).ToCursorString() - : null; - } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.fungibles.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.fungibles.cs index 32b381108..697379b76 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.fungibles.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.fungibles.cs @@ -181,7 +181,7 @@ LIMIT 1 resourceAddress: vm.ResourceEntityAddress, vaults: new GatewayModel.FungibleResourcesCollectionItemVaultAggregatedVault( totalCount: vm.VaultTotalCount, - nextCursor: GenerateOffsetCursor(vaultOffset, vaultLimit, vm.VaultTotalCount), + nextCursor: CursorGenerator.GenerateOffsetCursor(vaultOffset, vaultLimit, vm.VaultTotalCount), items: new List())); resources[vm.ResourceEntityAddress] = existingRecord; @@ -195,7 +195,7 @@ LIMIT 1 var items = resources.Values.Cast().ToList(); - return new GatewayModel.FungibleResourcesCollection(resourcesTotalCount, GenerateOffsetCursor(resourceOffset, resourceLimit, resourcesTotalCount), items); + return new GatewayModel.FungibleResourcesCollection(resourcesTotalCount, CursorGenerator.GenerateOffsetCursor(resourceOffset, resourceLimit, resourcesTotalCount), items); } private async Task GetFungibleResourceVaults( @@ -264,7 +264,7 @@ LIMIT 1 lastUpdatedAtStateVersion: x.LastUpdatedAtStateVersion)) .ToList(); - return new GatewayModel.FungibleResourcesCollectionItemVaultAggregatedVault(vaultsTotalCount, GenerateOffsetCursor(offset, limit, vaultsTotalCount), castedResult); + return new GatewayModel.FungibleResourcesCollectionItemVaultAggregatedVault(vaultsTotalCount, CursorGenerator.GenerateOffsetCursor(offset, limit, vaultsTotalCount), castedResult); } private async Task> GetFungibleVaultsHistory(List fungibleVaultEntities, GatewayModel.LedgerState ledgerState, CancellationToken token) diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.nonfungibles.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.nonfungibles.cs index 03200911a..e743a0d92 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.nonfungibles.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EntityStateQuerier.nonfungibles.cs @@ -173,7 +173,7 @@ LIMIT 1 lastUpdatedAtStateVersion: vm.LastUpdatedAtStateVersion)); } - return new GatewayModel.NonFungibleResourcesCollection(totalCount, GenerateOffsetCursor(offset, limit, totalCount), items); + return new GatewayModel.NonFungibleResourcesCollection(totalCount, CursorGenerator.GenerateOffsetCursor(offset, limit, totalCount), items); } private async Task> GetNonFungiblesSliceAggregatedPerVault( @@ -371,7 +371,7 @@ order by ord }) .ToList(); - return new GatewayModel.NonFungibleIdsCollection(totalCount, GenerateOffsetCursor(offset, limit, totalCount), items); + return new GatewayModel.NonFungibleIdsCollection(totalCount, CursorGenerator.GenerateOffsetCursor(offset, limit, totalCount), items); } private async Task> GetNonFungibleIdsFirstPageAndOneMore( @@ -521,7 +521,7 @@ private GatewayModel.NonFungibleResourcesCollection MapToNonFungibleResourcesCol resourceAddress: vm.ResourceEntityAddress, vaults: new GatewayApiSdk.Model.NonFungibleResourcesCollectionItemVaultAggregatedVault( totalCount: vm.VaultTotalCount, - nextCursor: GenerateOffsetCursor(vaultOffset, vaultLimit, vm.VaultTotalCount), + nextCursor: CursorGenerator.GenerateOffsetCursor(vaultOffset, vaultLimit, vm.VaultTotalCount), items: new List())); resources[vm.ResourceEntityAddress] = existingRecord; @@ -535,7 +535,7 @@ private GatewayModel.NonFungibleResourcesCollection MapToNonFungibleResourcesCol existingRecord.Vaults.Items.Add(new GatewayModel.NonFungibleResourcesCollectionItemVaultAggregatedVaultItem( totalCount: vm.NonFungibleIdsCount, - nextCursor: GenerateOffsetCursor(vaultOffset, vaultLimit, vm.NonFungibleIdsCount), + nextCursor: CursorGenerator.GenerateOffsetCursor(vaultOffset, vaultLimit, vm.NonFungibleIdsCount), items: ids, vaultAddress: vm.VaultAddress, lastUpdatedAtStateVersion: vm.LastUpdatedAtStateVersion)); @@ -543,7 +543,7 @@ private GatewayModel.NonFungibleResourcesCollection MapToNonFungibleResourcesCol var items = resources.Values.Cast().ToList(); - return new GatewayModel.NonFungibleResourcesCollection(resourcesTotalCount, GenerateOffsetCursor(resourceOffset, resourceLimit, resourcesTotalCount), items); + return new GatewayModel.NonFungibleResourcesCollection(resourcesTotalCount, CursorGenerator.GenerateOffsetCursor(resourceOffset, resourceLimit, resourcesTotalCount), items); } private GatewayModel.StateEntityNonFungibleResourceVaultsPageResponse MapToStateEntityNonFungibleResourceVaultsPageResponse( @@ -565,7 +565,7 @@ private GatewayModel.StateEntityNonFungibleResourceVaultsPageResponse MapToState if (nonFungibleIdsAndOneMore?.TryGetValue(x.VaultEntityId, out var nfids) == true) { items = nfids.Take(nonFungibleIdsLimit).Select(y => y.NonFungibleId).ToList(); - nextCursor = GenerateOffsetCursor(0, nonFungibleIdsLimit, x.NonFungibleIdsCount); + nextCursor = CursorGenerator.GenerateOffsetCursor(0, nonFungibleIdsLimit, x.NonFungibleIdsCount); } return new GatewayModel.NonFungibleResourcesCollectionItemVaultAggregatedVaultItem( @@ -580,7 +580,7 @@ private GatewayModel.StateEntityNonFungibleResourceVaultsPageResponse MapToState .ToList(); var vaultsTotalCount = input.FirstOrDefault()?.VaultTotalCount ?? 0; - var nextCursor = GenerateOffsetCursor(offset, limit, vaultsTotalCount); + var nextCursor = CursorGenerator.GenerateOffsetCursor(offset, limit, vaultsTotalCount); return new GatewayModel.StateEntityNonFungibleResourceVaultsPageResponse(ledgerState, vaultsTotalCount, nextCursor, mapped, entityGlobalAddress, resourceGlobalAddress); } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EventDecoder.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EventDecoder.cs index 4151d9962..45255eac3 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EventDecoder.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/EventDecoder.cs @@ -157,13 +157,13 @@ public static ToolkitModel.TypedNativeEvent DecodeEvent(CoreModel.Event @event, return ToolkitModel.RadixEngineToolkitUniffiMethods.SborDecodeToTypedNativeEvent(eventIdentifier, @event.Data.GetDataBytes(), networkId); } - private static ToolkitModel.ObjectModuleId MapModuleId(CoreModel.ModuleId core) => + private static ToolkitModel.ModuleId MapModuleId(CoreModel.ModuleId core) => core switch { - CoreModel.ModuleId.Main => ToolkitModel.ObjectModuleId.MAIN, - CoreModel.ModuleId.Metadata => ToolkitModel.ObjectModuleId.METADATA, - CoreModel.ModuleId.Royalty => ToolkitModel.ObjectModuleId.ROYALTY, - CoreModel.ModuleId.RoleAssignment => ToolkitModel.ObjectModuleId.ROLE_ASSIGNMENT, + CoreModel.ModuleId.Main => ToolkitModel.ModuleId.Main, + CoreModel.ModuleId.Metadata => ToolkitModel.ModuleId.Metadata, + CoreModel.ModuleId.Royalty => ToolkitModel.ModuleId.Royalty, + CoreModel.ModuleId.RoleAssignment => ToolkitModel.ModuleId.RoleAssignment, _ => throw new ArgumentOutOfRangeException(nameof(core), core, null), }; } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/KeyValueStoreQuerier.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/KeyValueStoreQuerier.cs new file mode 100644 index 000000000..5a2c21970 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/KeyValueStoreQuerier.cs @@ -0,0 +1,279 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using Dapper; +using Microsoft.EntityFrameworkCore; +using Microsoft.Extensions.Options; +using RadixDlt.NetworkGateway.Abstractions; +using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.Abstractions.Model; +using RadixDlt.NetworkGateway.Abstractions.Network; +using RadixDlt.NetworkGateway.GatewayApi.Exceptions; +using RadixDlt.NetworkGateway.GatewayApi.Services; +using RadixDlt.NetworkGateway.PostgresIntegration.Models; +using System.Collections.Generic; +using System.Diagnostics; +using System.Linq; +using System.Threading; +using System.Threading.Tasks; +using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; + +namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; + +internal class KeyValueStoreQuerier : IKeyValueStoreQuerier +{ + private record KeyValueStoreItemsViewModel(long FromStateVersion, byte[] Key, int TotalCount); + + private record KeyValueStoreSchemaModel(byte[] KeySchema, long KeyTypeIndex, SborTypeKind KeySborTypeKind, byte[] ValueSchema, long ValueTypeIndex, SborTypeKind ValueSborTypeKind); + + private readonly IDapperWrapper _dapperWrapper; + private readonly ReadOnlyDbContext _dbContext; + private readonly INetworkConfigurationProvider _networkConfigurationProvider; + + public KeyValueStoreQuerier(IDapperWrapper dapperWrapper, ReadOnlyDbContext dbContext, INetworkConfigurationProvider networkConfigurationProvider) + { + _dapperWrapper = dapperWrapper; + _dbContext = dbContext; + _networkConfigurationProvider = networkConfigurationProvider; + } + + public async Task KeyValueStoreItems( + EntityAddress keyValueStoreAddress, + GatewayApiSdk.Model.LedgerState ledgerState, + int offset, + int limit, + CancellationToken token = default) + { + var keyValueStore = await GetEntity(keyValueStoreAddress, ledgerState, token); + var keyValueStoreSchema = await GetKeyValueStoreSchema(keyValueStore.Id, ledgerState, token); + + var cd = new CommandDefinition( + commandText: @" +WITH key_value_store_items_slices AS ( + SELECT key_value_store_entry_ids[@startIndex:@endIndex] AS key_value_store_items_slice, cardinality(key_value_store_entry_ids) AS key_value_store_items_total_count + FROM key_value_store_aggregate_history + WHERE key_value_store_entity_id = @keyValueStoreEntityId AND from_state_version <= @stateVersion + ORDER BY from_state_version DESC + LIMIT 1 +) +SELECT + kvseh.from_state_version AS FromStateVersion, + kvseh.key AS Key, + kvsits.key_value_store_items_total_count AS TotalCount +FROM key_value_store_items_slices AS kvsits +INNER JOIN LATERAL UNNEST(key_value_store_items_slice) WITH ORDINALITY AS key_value_store_join(id, ordinality) ON TRUE +INNER JOIN key_value_store_entry_history kvseh ON kvseh.id = key_value_store_join.id AND kvseh.is_deleted = FALSE +ORDER BY key_value_store_join.ordinality ASC +;", + parameters: new + { + keyValueStoreEntityId = keyValueStore.Id, + stateVersion = ledgerState.StateVersion, + startIndex = offset + 1, + endIndex = offset + limit, + }, + cancellationToken: token); + + var queryResult = (await _dapperWrapper.QueryAsync(_dbContext.Database.GetDbConnection(), cd)).ToList(); + + var mappedItems = new List(); + + int totalCount = queryResult.FirstOrDefault()?.TotalCount ?? 0; + + foreach (var item in queryResult) + { + var networkId = (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Id; + var keyProgrammaticJson = ScryptoSborUtils.DataToProgrammaticJson(item.Key, keyValueStoreSchema.KeySchema, keyValueStoreSchema.KeySborTypeKind, + keyValueStoreSchema.KeyTypeIndex, networkId); + + mappedItems.Add(new GatewayModel.StateKeyValueStoreKeysResponseItem( + key: new GatewayModel.ScryptoSborValue(item.Key.ToHex(), keyProgrammaticJson), + lastUpdatedAtStateVersion: item.FromStateVersion + ) + ); + } + + return new GatewayApiSdk.Model.StateKeyValueStoreKeysResponse( + ledgerState: ledgerState, + keyValueStoreAddress: keyValueStoreAddress, + totalCount: totalCount, + nextCursor: CursorGenerator.GenerateOffsetCursor(offset, limit, totalCount), + items: mappedItems + ); + } + + public async Task KeyValueStoreData( + EntityAddress keyValueStoreAddress, + IList keys, + GatewayModel.LedgerState ledgerState, + CancellationToken token = default) + { + var keyValueStore = await GetEntity(keyValueStoreAddress, ledgerState, token); + var dbKeys = keys.Distinct().Select(k => (byte[])k).ToList(); + var keyValueStoreSchema = await GetKeyValueStoreSchema(keyValueStore.Id, ledgerState, token); + + var entries = await _dbContext + .KeyValueStoreEntryHistory + .FromSqlInterpolated(@$" +WITH variables (key) AS ( + SELECT UNNEST({dbKeys}) +) +SELECT kvseh.* +FROM variables +INNER JOIN LATERAL ( + SELECT * + FROM key_value_store_entry_history + WHERE key_value_store_entity_id = {keyValueStore.Id} AND key = variables.key AND from_state_version <= {ledgerState.StateVersion} + ORDER BY from_state_version DESC + LIMIT 1 +) kvseh ON TRUE;") + .AnnotateMetricName("GetKeyValueStores") + .ToListAsync(token); + + var items = new List(); + + foreach (var e in entries) + { + if (e.IsDeleted) + { + continue; + } + + var networkId = (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Id; + var keyProgrammaticJson = ScryptoSborUtils.DataToProgrammaticJson(e.Key, keyValueStoreSchema.KeySchema, keyValueStoreSchema.KeySborTypeKind, + keyValueStoreSchema.KeyTypeIndex, networkId); + var valueProgrammaticJson = ScryptoSborUtils.DataToProgrammaticJson(e.Value, keyValueStoreSchema.ValueSchema, keyValueStoreSchema.ValueSborTypeKind, + keyValueStoreSchema.ValueTypeIndex, networkId); + + items.Add(new GatewayModel.StateKeyValueStoreDataResponseItem( + key: new GatewayModel.ScryptoSborValue(e.Key.ToHex(), keyProgrammaticJson), + value: new GatewayModel.ScryptoSborValue(e.Value.ToHex(), valueProgrammaticJson), + lastUpdatedAtStateVersion: e.FromStateVersion, + isLocked: e.IsLocked)); + } + + return new GatewayModel.StateKeyValueStoreDataResponse(ledgerState, keyValueStoreAddress, items); + } + + private async Task GetKeyValueStoreSchema( + long keyValueStoreId, + GatewayModel.LedgerState ledgerState, + CancellationToken token = default) + { + var keyValueStoreSchemaQuery = new CommandDefinition( + commandText: @" +SELECT + ksh.schema AS KeySchema, + kvssh.key_type_index AS KeyTypeIndex, + kvssh.key_sbor_type_kind AS KeySborTypeKind, + vsh.schema AS ValueSchema, + kvssh.value_type_index AS ValueTypeIndex, + kvssh.value_sbor_type_kind AS ValueSborTypeKind +FROM key_value_store_schema_history kvssh +INNER JOIN schema_history ksh ON ksh.schema_hash = kvssh.key_schema_hash AND ksh.entity_id = kvssh.key_schema_defining_entity_id +INNER JOIN schema_history vsh ON vsh.schema_hash = kvssh.value_schema_hash AND vsh.entity_id = kvssh.value_schema_defining_entity_id +WHERE kvssh.key_value_store_entity_id = @entityId AND kvssh.from_state_version <= @stateVersion +ORDER BY kvssh.from_state_version DESC +", + parameters: new + { + stateVersion = ledgerState.StateVersion, + entityId = keyValueStoreId, + }, + cancellationToken: token); + + var keyValueStoreSchema = await _dapperWrapper.QueryFirstOrDefaultAsync( + _dbContext.Database.GetDbConnection(), keyValueStoreSchemaQuery, "GetKeyValueStoreSchema" + ); + + if (keyValueStoreSchema == null) + { + throw new UnreachableException($"Missing key value store schema for :{keyValueStoreId}"); + } + + return keyValueStoreSchema; + } + + private async Task GetEntity(EntityAddress address, GatewayModel.LedgerState ledgerState, CancellationToken token) + where TEntity : Entity + { + var entity = await _dbContext + .Entities + .Where(e => e.FromStateVersion <= ledgerState.StateVersion) + .AnnotateMetricName() + .FirstOrDefaultAsync(e => e.Address == address, token); + + if (entity == null) + { + throw new EntityNotFoundException(address.ToString()); + } + + if (entity is not TEntity typedEntity) + { + throw new InvalidEntityException(address.ToString()); + } + + return typedEntity; + } +} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/LedgerStateQuerier.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/LedgerStateQuerier.cs index e7ab18190..2f9258fb6 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/LedgerStateQuerier.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/LedgerStateQuerier.cs @@ -67,6 +67,7 @@ using Microsoft.Extensions.Options; using RadixDlt.NetworkGateway.Abstractions; using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.GatewayApi.Configuration; using RadixDlt.NetworkGateway.GatewayApi.Exceptions; using RadixDlt.NetworkGateway.GatewayApi.Services; @@ -127,7 +128,7 @@ public LedgerStateQuerier( return new GatewayModel.GatewayStatusResponse( new GatewayModel.LedgerState( - _networkConfigurationProvider.GetNetworkName(), + (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Name, topLedgerTransaction.StateVersion, topLedgerTransaction.RoundTimestamp.AsUtcIsoDateWithMillisString(), topLedgerTransaction.Epoch, @@ -180,16 +181,16 @@ public LedgerStateQuerier( if (fromLedgerStateIdentifier?.HasStateVersion() == true) { - ledgerStateReport = await GetLedgerStateAfterStateVersion(fromLedgerStateIdentifier.StateVersion.Value, token); - } - else if (fromLedgerStateIdentifier?.HasTimestamp() == true) - { - ledgerStateReport = await GetLedgerStateAfterTimestamp(fromLedgerStateIdentifier.Timestamp.Value, token); + ledgerStateReport = await GetLedgerStateAtStateVersion(fromLedgerStateIdentifier.StateVersion.Value, token); } else if (fromLedgerStateIdentifier?.HasEpoch() == true) { ledgerStateReport = await GetLedgerStateAtEpochAndRound(fromLedgerStateIdentifier.Epoch.Value, fromLedgerStateIdentifier.Round ?? 1, token); } + else if (fromLedgerStateIdentifier?.HasTimestamp() == true) + { + ledgerStateReport = await GetLedgerStateAfterTimestamp(fromLedgerStateIdentifier.Timestamp.Value, token); + } return ledgerStateReport?.LedgerState; } @@ -292,16 +293,16 @@ private async Task GetLedgerState(GatewayModel.LedgerStateSel if (at?.HasStateVersion() == true) { - result = await GetLedgerStateBeforeStateVersion(at.StateVersion.Value, token); - } - else if (at?.HasTimestamp() == true) - { - result = await GetLedgerStateBeforeTimestamp(at.Timestamp.Value, token); + result = await GetLedgerStateAtStateVersion(at.StateVersion.Value, token); } else if (at?.HasEpoch() == true) { result = await GetLedgerStateAtEpochAndRound(at.Epoch.Value, at.Round ?? 1, token); } + else if (at?.HasTimestamp() == true) + { + result = await GetLedgerStateBeforeTimestamp(at.Timestamp.Value, token); + } else { result = await GetTopOfLedgerStateReport(token); @@ -322,21 +323,9 @@ private async Task GetTopOfLedgerStateReport(CancellationToke return ledgerState; } - private async Task GetLedgerStateBeforeStateVersion(long stateVersion, CancellationToken token) + private async Task GetLedgerStateAtStateVersion(long stateVersion, CancellationToken token) { - var ledgerState = await SelectLedgerStateFromQuery(_dbContext.GetLatestLedgerTransactionBeforeStateVersion(stateVersion), false, token); - - if (ledgerState == null) - { - throw new InvalidStateException("There are no transactions in the database"); - } - - return ledgerState; - } - - private async Task GetLedgerStateAfterStateVersion(long stateVersion, CancellationToken token) - { - var ledgerState = await SelectLedgerStateFromQuery(_dbContext.GetFirstLedgerTransactionAfterStateVersion(stateVersion), false, token); + var ledgerState = await SelectLedgerStateFromQuery(_dbContext.GetLatestLedgerTransactionAtStateVersion(stateVersion), false, token); if (ledgerState == null) { @@ -355,6 +344,8 @@ private async Task GetLedgerStateBeforeTimestamp(DateTime tim throw InvalidRequestException.FromOtherError("Timestamp was before the start of the ledger"); } + DetectTimestampDrift(timestamp, ledgerState.RoundTimestamp); + return ledgerState; } @@ -367,6 +358,8 @@ private async Task GetLedgerStateAfterTimestamp(DateTime time throw InvalidRequestException.FromOtherError("Timestamp is beyond the end of the known ledger"); } + DetectTimestampDrift(timestamp, ledgerState.RoundTimestamp); + return ledgerState; } @@ -398,7 +391,7 @@ private async Task GetLedgerStateAtEpochAndRound(long epoch, ? null : new LedgerStateReport( new GatewayModel.LedgerState( - _networkConfigurationProvider.GetNetworkName(), + (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Name, lt.StateVersion, lt.RoundTimestamp.AsUtcIsoDateWithMillisString(), lt.Epoch, @@ -408,4 +401,12 @@ private async Task GetLedgerStateAtEpochAndRound(long epoch, resolvesTopOfLedger ); } + + private void DetectTimestampDrift(DateTime timestamp, DateTime roundTimestamp) + { + if ((roundTimestamp - timestamp).Absolute() > TimeSpan.FromSeconds(5)) + { + _logger.LogWarning("Detected possibly invalid timestamp-based ledger state lookup. {Expected} falls outside of 5 second boundary for round timestamp {Actual}", timestamp.ToString("O"), roundTimestamp.ToString("O")); + } + } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/NetworkConfigurationInitializer.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/NetworkConfigurationInitializer.cs deleted file mode 100644 index a8ccca048..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/NetworkConfigurationInitializer.cs +++ /dev/null @@ -1,113 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using Microsoft.Extensions.DependencyInjection; -using Microsoft.Extensions.Hosting; -using Microsoft.Extensions.Logging; -using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.GatewayApi.Services; -using System; -using System.Threading; -using System.Threading.Tasks; - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; - -internal class NetworkConfigurationInitializer : BackgroundService -{ - private readonly IServiceProvider _serviceProvider; - private readonly ILogger _logger; - - public NetworkConfigurationInitializer(IServiceProvider serviceProvider, ILogger logger) - { - _serviceProvider = serviceProvider; - _logger = logger; - } - - protected override async Task ExecuteAsync(CancellationToken stoppingToken) - { - using var scope = _serviceProvider.CreateScope(); - - var networkConfigurationProvider = scope.ServiceProvider.GetRequiredService(); - - while (!stoppingToken.IsCancellationRequested) - { - try - { - await networkConfigurationProvider.Initialize(scope.ServiceProvider.GetRequiredService(), stoppingToken); - break; - } - catch (Exception exception) - { - if (exception.ShouldBeConsideredAppFatal()) - { - throw; - } - - _logger.LogWarning(exception, "Error fetching network configuration - perhaps the data aggregator hasn't committed yet? Will try again in 2 seconds"); - - await Task.Delay(2000, stoppingToken); - } - } - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/NetworkConfigurationProvider.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/NetworkConfigurationProvider.cs deleted file mode 100644 index 0083543ca..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/NetworkConfigurationProvider.cs +++ /dev/null @@ -1,291 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using Microsoft.EntityFrameworkCore; -using Microsoft.Extensions.Logging; -using RadixDlt.NetworkGateway.Abstractions.Addressing; -using RadixDlt.NetworkGateway.Abstractions.Configuration; -using RadixDlt.NetworkGateway.DataAggregator.Services; -using RadixDlt.NetworkGateway.PostgresIntegration.Models; -using System; -using System.Linq; -using System.Threading; -using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; - -/// -/// This captures the NetworkConfiguration for the DataAggregator - typically from a node, but it can also pull it -/// from the database. -/// It persists a local copy of it for the duration of the DataAggregator's uptime. -/// -internal class NetworkConfigurationProvider : INetworkConfigurationProvider -{ - private readonly IDbContextFactory _dbContextFactory; - private readonly ILogger _logger; - - private readonly object _writeLock = new(); - private NetworkConfiguration? _capturedConfig; - - public NetworkConfigurationProvider(IDbContextFactory dbContextFactory, ILogger logger) - { - _dbContextFactory = dbContextFactory; - _logger = logger; - } - - public async Task SetNetworkConfigurationOrAssertMatching( - CoreModel.NetworkConfigurationResponse inputNetworkConfiguration, - CoreModel.NetworkStatusResponse inputNetworkStatus, - CancellationToken token) - { - var networkConfiguration = Map(inputNetworkConfiguration, inputNetworkStatus); - var existingNetworkConfiguration = await GetCurrentLedgerNetworkConfigurationFromDb(token); - - EnsureNetworkConfigurationCaptured(networkConfiguration); - - if (existingNetworkConfiguration != null) - { - if (!existingNetworkConfiguration.HasEqualConfiguration(networkConfiguration)) - { - throw new ConfigurationException("Network configuration does does not match those stored in the database."); - } - } - - if (!GetCapturedConfig().HasEqualConfiguration(networkConfiguration)) - { - throw new ConfigurationException("Network configuration does does not match those stored from other nodes."); - } - } - - public async Task EnsureNetworkConfigurationLoadedFromDatabaseIfExistsAndReturnNetworkName(CancellationToken token = default) - { - var currentConfiguration = await GetCurrentLedgerNetworkConfigurationFromDb(token); - - if (currentConfiguration != null) - { - EnsureNetworkConfigurationCaptured(currentConfiguration); - - _logger.LogInformation("Network configuration for network {NetworkName} loaded from database", currentConfiguration.NetworkName); - - return currentConfiguration.NetworkName; - } - - _logger.LogInformation("Network configuration not loaded from database (db ledger likely empty)"); - - return null; - } - - public async Task SaveLedgerNetworkConfigurationToDatabaseOnInitIfNotExists(CancellationToken token) - { - await using var dbContext = await _dbContextFactory.CreateDbContextAsync(token); - - if (await dbContext.NetworkConfiguration.AsNoTracking().AnnotateMetricName().AnyAsync(token)) - { - return false; - } - - dbContext.Add(GetCapturedConfig()); - await dbContext.SaveChangesAsync(token); - return true; - } - - public byte GetNetworkId() - { - return GetCapturedConfig().NetworkId; - } - - public string GetNetworkName() - { - return GetCapturedConfig().NetworkName; - } - - public long GetGenesisEpoch() - { - return GetCapturedConfig().GenesisEpoch; - } - - public long GetGenesisRound() - { - return GetCapturedConfig().GenesisRound; - } - - public string GetNetworkHrpSuffix() - { - return GetCapturedConfig().NetworkHrpSuffix; - } - - public HrpDefinition GetHrpDefinition() - { - return GetCapturedConfig().HrpDefinition; - } - - public WellKnownAddresses GetWellKnownAddresses() - { - return GetCapturedConfig().WellKnownAddresses; - } - - public AddressTypeDefinition GetAddressTypeDefinition(AddressEntityType entityType) - { - return GetCapturedConfig().AddressTypeDefinitions.First(atd => atd.EntityType == entityType); - } - - private static NetworkConfiguration Map(CoreModel.NetworkConfigurationResponse networkConfiguration, CoreModel.NetworkStatusResponse networkStatus) - { - var wka = networkConfiguration.WellKnownAddresses; - var at = networkConfiguration.AddressTypes.Select(MapAddressTypeDefinition).ToArray(); - - return new NetworkConfiguration - { - NetworkId = (byte)networkConfiguration.NetworkId, - NetworkName = networkConfiguration.Network, - NetworkHrpSuffix = networkConfiguration.NetworkHrpSuffix, - HrpDefinition = new HrpDefinition( - GlobalPackage: GetHrpPrefix(at, AddressEntityType.GlobalPackage), - GlobalGenericComponent: GetHrpPrefix(at, AddressEntityType.GlobalGenericComponent), - InternalGenericComponent: GetHrpPrefix(at, AddressEntityType.InternalGenericComponent), - GlobalAccount: GetHrpPrefix(at, AddressEntityType.GlobalAccount), - GlobalVirtualEd25519Account: GetHrpPrefix(at, AddressEntityType.GlobalVirtualEd25519Account), - GlobalVirtualSecp256k1Account: GetHrpPrefix(at, AddressEntityType.GlobalVirtualSecp256k1Account), - GlobalValidator: GetHrpPrefix(at, AddressEntityType.GlobalValidator), - GlobalIdentity: GetHrpPrefix(at, AddressEntityType.GlobalIdentity), - GlobalVirtualEd25519Identity: GetHrpPrefix(at, AddressEntityType.GlobalVirtualEd25519Identity), - GlobalVirtualSecp256k1Identity: GetHrpPrefix(at, AddressEntityType.GlobalVirtualSecp256k1Identity), - GlobalConsensusManager: GetHrpPrefix(at, AddressEntityType.GlobalConsensusManager), - GlobalFungibleResource: GetHrpPrefix(at, AddressEntityType.GlobalFungibleResource), - GlobalNonFungibleResource: GetHrpPrefix(at, AddressEntityType.GlobalNonFungibleResource), - InternalFungibleVault: GetHrpPrefix(at, AddressEntityType.InternalFungibleVault), - InternalNonFungibleVault: GetHrpPrefix(at, AddressEntityType.InternalNonFungibleVault), - InternalKeyValueStore: GetHrpPrefix(at, AddressEntityType.InternalKeyValueStore), - GlobalAccessController: GetHrpPrefix(at, AddressEntityType.GlobalAccessController) - ), - WellKnownAddresses = new WellKnownAddresses( - Xrd: wka.Xrd, - Secp256k1SignatureVirtualBadge: wka.Secp256k1SignatureVirtualBadge, - Ed25519SignatureVirtualBadge: wka.Ed25519SignatureVirtualBadge, - PackageOfDirectCallerVirtualBadge: wka.PackageOfDirectCallerVirtualBadge, - GlobalCallerVirtualBadge: wka.GlobalCallerVirtualBadge, - SystemTransactionBadge: wka.SystemTransactionBadge, - PackageOwnerBadge: wka.PackageOwnerBadge, - ValidatorOwnerBadge: wka.ValidatorOwnerBadge, - AccountOwnerBadge: wka.AccountOwnerBadge, - IdentityOwnerBadge: wka.IdentityOwnerBadge, - PackagePackage: wka.PackagePackage, - ResourcePackage: wka.ResourcePackage, - AccountPackage: wka.AccountPackage, - IdentityPackage: wka.IdentityPackage, - ConsensusManagerPackage: wka.ConsensusManagerPackage, - AccessControllerPackage: wka.AccessControllerPackage, - TransactionProcessorPackage: wka.TransactionProcessorPackage, - MetadataModulePackage: wka.MetadataModulePackage, - RoyaltyModulePackage: wka.RoyaltyModulePackage, - AccessRulesPackage: wka.RoleAssignmentModulePackage, - GenesisHelperPackage: wka.GenesisHelperPackage, - FaucetPackage: wka.FaucetPackage, - ConsensusManager: wka.ConsensusManager, - GenesisHelper: wka.GenesisHelper, - Faucet: wka.Faucet, - PoolPackage: wka.PoolPackage, - TransactionTracker: wka.TransactionTracker - ), - AddressTypeDefinitions = at, - GenesisEpoch = networkStatus.GenesisEpochRound.Epoch, - }; - } - - private static string GetHrpPrefix(AddressTypeDefinition[] addressTypeDefinitions, AddressEntityType entityType) - { - return addressTypeDefinitions.First(at => at.EntityType == entityType).HrpPrefix; - } - - private static AddressTypeDefinition MapAddressTypeDefinition(CoreModel.AddressType arg) - { - return new AddressTypeDefinition(Enum.Parse(arg.EntityType.ToString(), true), arg.HrpPrefix, arg.AddressBytePrefix, arg.AddressByteLength); - } - - private NetworkConfiguration GetCapturedConfig() - { - return _capturedConfig ?? throw new ConfigurationException("Config hasn't been captured from a Node or from the Database yet."); - } - - private void EnsureNetworkConfigurationCaptured(NetworkConfiguration inputNetworkConfiguration) - { - lock (_writeLock) - { - if (_capturedConfig != null) - { - return; - } - - _capturedConfig = inputNetworkConfiguration; - } - } - - private async Task GetCurrentLedgerNetworkConfigurationFromDb(CancellationToken token) - { - await using var dbContext = await _dbContextFactory.CreateDbContextAsync(token); - - return await dbContext.NetworkConfiguration.AsNoTracking().SingleOrDefaultAsync(token); - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/PendingTransactionResponseAggregator.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/PendingTransactionResponseAggregator.cs new file mode 100644 index 000000000..1aa8f57a5 --- /dev/null +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/PendingTransactionResponseAggregator.cs @@ -0,0 +1,293 @@ +/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). + * + * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this + * file except in compliance with the License. You may obtain a copy of the License at: + * + * radixfoundation.org/licenses/LICENSE-v1 + * + * The Licensor hereby grants permission for the Canonical version of the Work to be + * published, distributed and used under or by reference to the Licensor’s trademark + * Radix ® and use of any unregistered trade names, logos or get-up. + * + * The Licensor provides the Work (and each Contributor provides its Contributions) on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, + * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, + * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. + * + * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create + * a distributed ledger it is your responsibility to test and validate the code, together + * with all logic and performance of that code under all foreseeable scenarios. + * + * The Licensor does not make or purport to make and hereby excludes liability for all + * and any representation, warranty or undertaking in any form whatsoever, whether express + * or implied, to any entity or person, including any representation, warranty or + * undertaking, as to the functionality security use, value or other characteristics of + * any distributed ledger nor in respect the functioning or value of any tokens which may + * be created stored or transferred using the Work. The Licensor does not warrant that the + * Work or any use of the Work complies with any law or regulation in any territory where + * it may be implemented or used or that it will be appropriate for any specific purpose. + * + * Neither the licensor nor any current or former employees, officers, directors, partners, + * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor + * shall be liable for any direct or indirect, special, incidental, consequential or other + * losses of any kind, in tort, contract or otherwise (including but not limited to loss + * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss + * of any economic or other opportunity of whatsoever nature or howsoever arising), arising + * out of or in connection with (without limitation of any use, misuse, of any ledger system + * or use made or its functionality or any performance or operation of any code or protocol + * caused by bugs or programming or logic errors or otherwise); + * + * A. any offer, purchase, holding, use, sale, exchange or transmission of any + * cryptographic keys, tokens or assets created, exchanged, stored or arising from any + * interaction with the Work; + * + * B. any failure in a transmission or loss of any token or assets keys or other digital + * artefacts due to errors in transmission; + * + * C. bugs, hacks, logic errors or faults in the Work or any communication; + * + * D. system software or apparatus including but not limited to losses caused by errors + * in holding or transmitting tokens by any third-party; + * + * E. breaches or failure of security including hacker attacks, loss or disclosure of + * password, loss of private key, unauthorised use or misuse of such passwords or keys; + * + * F. any losses including loss of anticipated savings or other benefits resulting from + * use of the Work or any changes to the Work (however implemented). + * + * You are solely responsible for; testing, validating and evaluation of all operation + * logic, functionality, security and appropriateness of using the Work for any commercial + * or non-commercial purpose and for any reproduction or redistribution by You of the + * Work. You assume all risks associated with Your use of the Work and the exercise of + * permissions under this License. + */ + +using RadixDlt.NetworkGateway.Abstractions.Model; +using System; +using System.Collections.Generic; +using System.Linq; +using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; + +namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; + +internal record PendingTransactionSummary( + string PayloadHash, + long EndEpochExclusive, + DateTime? ResubmitFromTimestamp, + string? HandlingStatusReason, + PendingTransactionPayloadLedgerStatus PayloadStatus, + PendingTransactionIntentLedgerStatus IntentStatus, + string? InitialRejectionReason, + string? LatestRejectionReason, + string? LastSubmissionError); + +internal class PendingTransactionResponseAggregator +{ + private static readonly GatewayModel.TransactionIntentStatus[] _statusesToReturnPermanentlyRejectsAtEpoch = + { + GatewayModel.TransactionIntentStatus.Unknown, + GatewayModel.TransactionIntentStatus.LikelyButNotCertainRejection, + GatewayModel.TransactionIntentStatus.Pending, + }; + + private readonly GatewayModel.LedgerState _ledgerState; + private readonly string? _committedPayloadHash; + private readonly long? _committedStateVersion; + private readonly List _knownPayloads = new(); + private readonly GatewayModel.TransactionIntentStatus? _committedIntentStatus; + private readonly string? _committedErrorMessage; + private PendingTransactionIntentLedgerStatus _mostAccuratePendingTransactionIntentLedgerStatus = PendingTransactionIntentLedgerStatus.Unknown; + private string? _rejectionReasonForMostAccurateIntentLedgerStatus; + private long? _rejectionEpoch; + + internal PendingTransactionResponseAggregator(GatewayModel.LedgerState ledgerState, TransactionQuerier.CommittedTransactionSummary? committedTransactionSummary) + { + _ledgerState = ledgerState; + + if (committedTransactionSummary is null) + { + return; + } + + _committedPayloadHash = committedTransactionSummary.PayloadHash; + _committedStateVersion = committedTransactionSummary.StateVersion; + + var (legacyStatus, payloadStatus, intentStatus) = committedTransactionSummary.Status switch + { + LedgerTransactionStatus.Succeeded => (GatewayModel.TransactionStatus.CommittedSuccess, GatewayModel.TransactionPayloadStatus.CommittedSuccess, + GatewayModel.TransactionIntentStatus.CommittedSuccess), + LedgerTransactionStatus.Failed => (GatewayModel.TransactionStatus.CommittedFailure, GatewayModel.TransactionPayloadStatus.CommittedFailure, + GatewayModel.TransactionIntentStatus.CommittedFailure), + }; + + _committedIntentStatus = intentStatus; + _committedErrorMessage = committedTransactionSummary.ErrorMessage; + + _knownPayloads.Add(new GatewayModel.TransactionStatusResponseKnownPayloadItem( + payloadHash: committedTransactionSummary.PayloadHash, + status: legacyStatus, + payloadStatus: payloadStatus, + payloadStatusDescription: GetPayloadStatusDescription(payloadStatus), + errorMessage: committedTransactionSummary.ErrorMessage, + handlingStatus: GatewayModel.TransactionPayloadGatewayHandlingStatus.Concluded, + handlingStatusReason: "The transaction is committed", + submissionError: null + )); + } + + internal void AddPendingTransaction(PendingTransactionSummary pendingTransactionSummary) + { + if (pendingTransactionSummary.PayloadHash == _committedPayloadHash) + { + return; + } + + var (legacyStatus, payloadStatus) = pendingTransactionSummary.PayloadStatus switch + { + PendingTransactionPayloadLedgerStatus.Unknown => (GatewayModel.TransactionStatus.Unknown, GatewayModel.TransactionPayloadStatus.Unknown), + PendingTransactionPayloadLedgerStatus.Committed => (GatewayModel.TransactionStatus.Pending, GatewayModel.TransactionPayloadStatus.CommitPendingOutcomeUnknown), + PendingTransactionPayloadLedgerStatus.CommitPending => (GatewayModel.TransactionStatus.Pending, GatewayModel.TransactionPayloadStatus.CommitPendingOutcomeUnknown), + PendingTransactionPayloadLedgerStatus.ClashingCommit => (GatewayModel.TransactionStatus.Rejected, GatewayModel.TransactionPayloadStatus.PermanentlyRejected), + PendingTransactionPayloadLedgerStatus.PermanentlyRejected => (GatewayModel.TransactionStatus.Rejected, GatewayModel.TransactionPayloadStatus.PermanentlyRejected), + PendingTransactionPayloadLedgerStatus.TransientlyAccepted => (GatewayModel.TransactionStatus.Pending, GatewayModel.TransactionPayloadStatus.Pending), + PendingTransactionPayloadLedgerStatus.TransientlyRejected => (GatewayModel.TransactionStatus.Pending, GatewayModel.TransactionPayloadStatus.TemporarilyRejected), + }; + + _rejectionEpoch = pendingTransactionSummary.EndEpochExclusive; + + var handlingStatus = pendingTransactionSummary.ResubmitFromTimestamp switch + { + not null => GatewayModel.TransactionPayloadGatewayHandlingStatus.HandlingSubmission, + null => GatewayModel.TransactionPayloadGatewayHandlingStatus.Concluded, + }; + + if (pendingTransactionSummary.IntentStatus.AggregationPriorityAcrossKnownPayloads() >= _mostAccuratePendingTransactionIntentLedgerStatus.AggregationPriorityAcrossKnownPayloads()) + { + _mostAccuratePendingTransactionIntentLedgerStatus = pendingTransactionSummary.IntentStatus; + _rejectionReasonForMostAccurateIntentLedgerStatus = pendingTransactionSummary.LatestRejectionReason; + } + + var initialRejectionReason = pendingTransactionSummary.InitialRejectionReason; + var latestRejectionReason = pendingTransactionSummary.LatestRejectionReason; + + // If the intent's EndEpochExclusive has been reached, then the payload and intent must be permanently rejected (assuming they're not already committed). + if (_ledgerState.Epoch >= pendingTransactionSummary.EndEpochExclusive) + { + // The if statement is defence-in-depth to avoid replacing a Committed status with PermanentlyRejected. + // This shouldn't matter, because we'd see a committed transaction in this case, which would trump the _mostAccuratePendingTransactionIntentLedgerStatus when we + // resolve the status. But best to be defensive anyway. + if (PendingTransactionIntentLedgerStatus.PermanentRejection.AggregationPriorityAcrossKnownPayloads() >= + _mostAccuratePendingTransactionIntentLedgerStatus.AggregationPriorityAcrossKnownPayloads()) + { + _mostAccuratePendingTransactionIntentLedgerStatus = PendingTransactionIntentLedgerStatus.PermanentRejection; + _rejectionReasonForMostAccurateIntentLedgerStatus = $"Transaction has expired, as its expiry epoch of {pendingTransactionSummary.EndEpochExclusive} has been reached."; + } + + // The if statement is defence-in-depth to avoid replacing a Committed status with PermanentlyRejected. + // (Even though this shouldn't be possible because of the early return if pendingTransactionSummary.PayloadHash == _committedPayloadHash) + if (PendingTransactionPayloadLedgerStatus.PermanentlyRejected.ReplacementPriority() >= pendingTransactionSummary.PayloadStatus.ReplacementPriority()) + { + payloadStatus = GatewayModel.TransactionPayloadStatus.PermanentlyRejected; + legacyStatus = GatewayModel.TransactionStatus.Rejected; + latestRejectionReason = $"Transaction has expired, as its expiry epoch of {pendingTransactionSummary.EndEpochExclusive} has been reached."; + initialRejectionReason ??= latestRejectionReason; + } + } + + _knownPayloads.Add(new GatewayModel.TransactionStatusResponseKnownPayloadItem( + payloadHash: pendingTransactionSummary.PayloadHash, + status: legacyStatus, + payloadStatus: payloadStatus, + payloadStatusDescription: GetPayloadStatusDescription(payloadStatus), + errorMessage: initialRejectionReason, + latestErrorMessage: latestRejectionReason == initialRejectionReason ? null : latestRejectionReason, + handlingStatus: handlingStatus, + handlingStatusReason: pendingTransactionSummary.HandlingStatusReason, + submissionError: pendingTransactionSummary.LastSubmissionError + )); + } + + internal GatewayModel.TransactionStatusResponse IntoResponse() + { + var (intentStatus, errorMessage) = _committedIntentStatus != null + ? (_committedIntentStatus.Value, _committedErrorMessage) + : ( + _mostAccuratePendingTransactionIntentLedgerStatus switch + { + PendingTransactionIntentLedgerStatus.Unknown => GatewayModel.TransactionIntentStatus.Unknown, + PendingTransactionIntentLedgerStatus.Committed => GatewayModel.TransactionIntentStatus.CommitPendingOutcomeUnknown, + PendingTransactionIntentLedgerStatus.CommitPending => GatewayModel.TransactionIntentStatus.CommitPendingOutcomeUnknown, + PendingTransactionIntentLedgerStatus.PermanentRejection => GatewayModel.TransactionIntentStatus.PermanentlyRejected, + PendingTransactionIntentLedgerStatus.PossibleToCommit => GatewayModel.TransactionIntentStatus.Pending, + PendingTransactionIntentLedgerStatus.LikelyButNotCertainRejection => GatewayModel.TransactionIntentStatus.LikelyButNotCertainRejection, + }, + _rejectionReasonForMostAccurateIntentLedgerStatus + ); + + var legacyIntentStatus = intentStatus switch + { + GatewayModel.TransactionIntentStatus.Unknown => GatewayModel.TransactionStatus.Unknown, + GatewayModel.TransactionIntentStatus.CommittedSuccess => GatewayModel.TransactionStatus.CommittedSuccess, + GatewayModel.TransactionIntentStatus.CommittedFailure => GatewayModel.TransactionStatus.CommittedFailure, + GatewayModel.TransactionIntentStatus.CommitPendingOutcomeUnknown => GatewayModel.TransactionStatus.Pending, + GatewayModel.TransactionIntentStatus.PermanentlyRejected => GatewayModel.TransactionStatus.Rejected, + GatewayModel.TransactionIntentStatus.LikelyButNotCertainRejection => GatewayModel.TransactionStatus.Pending, + GatewayModel.TransactionIntentStatus.Pending => GatewayModel.TransactionStatus.Pending, + }; + + var permanentlyRejectsAtEpoch = _statusesToReturnPermanentlyRejectsAtEpoch.Contains(intentStatus) ? _rejectionEpoch : null; + + return new GatewayModel.TransactionStatusResponse( + ledgerState: _ledgerState, + status: legacyIntentStatus, + intentStatus, + intentStatusDescription: GetIntentStatusDescription(intentStatus), + knownPayloads: _knownPayloads, + committedStateVersion: _committedStateVersion, + permanentlyRejectsAtEpoch: (long?)permanentlyRejectsAtEpoch, + errorMessage + ); + } + + private string GetPayloadStatusDescription(GatewayModel.TransactionPayloadStatus payloadStatus) + { + return payloadStatus switch + { + GatewayModel.TransactionPayloadStatus.Unknown => + "No information is known about the possible outcome of this transaction payload.", + GatewayModel.TransactionPayloadStatus.CommittedSuccess => + "This particular payload for this transaction has been committed to the ledger as a success. For more information, use the /transaction/committed-details endpoint.", + GatewayModel.TransactionPayloadStatus.CommittedFailure => + "This particular payload for this transaction has been committed to the ledger as a failure. For more information, use the /transaction/committed-details endpoint.", + GatewayModel.TransactionPayloadStatus.CommitPendingOutcomeUnknown => + "This particular payload for this transaction has been committed to the ledger, but the Gateway is still waiting for further details about its result.", + GatewayModel.TransactionPayloadStatus.PermanentlyRejected => + "This particular payload for this transaction has been permanently rejected. It is not possible for this particular transaction payload to be committed to this network.", + GatewayModel.TransactionPayloadStatus.TemporarilyRejected => + "This particular payload for this transaction was rejected at its last execution. It may still be possible for this transaction payload to be committed to this network.", + GatewayModel.TransactionPayloadStatus.Pending => + "This particular payload for this transaction has been accepted into a node's mempool on the network. It's possible but not certain that it will be committed to this network.", + }; + } + + private string GetIntentStatusDescription(GatewayModel.TransactionIntentStatus intentStatus) + { + return intentStatus switch + { + GatewayModel.TransactionIntentStatus.Unknown => + "No information is known about the possible outcome of this transaction.", + GatewayModel.TransactionIntentStatus.CommittedSuccess => + "This transaction has been committed to the ledger as a success. For more information, use the /transaction/committed-details endpoint.", + GatewayModel.TransactionIntentStatus.CommittedFailure => + "This transaction has been committed to the ledger as a failure. For more information, use the /transaction/committed-details endpoint.", + GatewayModel.TransactionIntentStatus.CommitPendingOutcomeUnknown => + "This transaction has been committed to the ledger, but the Gateway is still waiting for further details about its result.", + GatewayModel.TransactionIntentStatus.PermanentlyRejected => + "This transaction is permanently rejected, so can never be committed to this network.", + GatewayModel.TransactionIntentStatus.Pending => + "A payload for this transaction has been accepted into a node's mempool on the network. It's possible but not certain that it will be committed to this network.", + GatewayModel.TransactionIntentStatus.LikelyButNotCertainRejection => + "All known payload/s for this transaction have been temporarily rejected at their last execution. It may still be possible for this transaction to be committed to this network.", + }; + } +} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/PendingTransactionResubmissionService.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/PendingTransactionResubmissionService.cs index 9b69acebc..168cdc1fa 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/PendingTransactionResubmissionService.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/PendingTransactionResubmissionService.cs @@ -70,10 +70,9 @@ using RadixDlt.NetworkGateway.Abstractions.Configuration; using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.Abstractions.Utilities; using RadixDlt.NetworkGateway.DataAggregator.Configuration; -using RadixDlt.NetworkGateway.DataAggregator.NodeServices; -using RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; using RadixDlt.NetworkGateway.DataAggregator.Services; using RadixDlt.NetworkGateway.GatewayApi.Exceptions; using RadixDlt.NetworkGateway.PostgresIntegration.Models; @@ -82,7 +81,6 @@ using System.Linq; using System.Threading; using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; @@ -204,7 +202,7 @@ await GetPendingTransactionsNeedingResubmission(instantForTransactionChoosing, d private List UpdateTransactionsForPotentialSubmissionOrRetirement( PendingTransactionHandlingConfig handlingConfig, List transactionsWantingResubmission, - ulong currentEpoch, + long currentEpoch, DateTime currentTime ) { @@ -217,7 +215,10 @@ DateTime currentTime if (canResubmit) { _observers.ForEach(x => x.TransactionMarkedAsSubmissionPending()); - transactionsToResubmitWithNodes.Add(new PendingTransactionWithChosenNode(transaction, GetRandomCoreApi())); + + var coreApiNode = _networkOptionsMonitor.CurrentValue.CoreApiNodes.GetRandomEnabledNodeForConstruction(); + + transactionsToResubmitWithNodes.Add(new PendingTransactionWithChosenNode(transaction, coreApiNode)); } else { @@ -241,7 +242,7 @@ private IQueryable GetPendingTransactionsNeedingResubmission private async Task ResubmitAllAndUpdateTransactionStatusesOnFailure( List transactionsToResubmitWithNodes, PendingTransactionHandlingConfig handlingConfig, - ulong currentEpoch, + long currentEpoch, CancellationToken token ) { @@ -280,14 +281,14 @@ private async Task Resubmit(PendingTransactionWithCh } using var nodeScope = _services.CreateScope(); - nodeScope.ServiceProvider.GetRequiredService().CoreApiNode = chosenNode; + nodeScope.ServiceProvider.GetRequiredService().CoreApiNode = chosenNode; var coreApiProvider = nodeScope.ServiceProvider.GetRequiredService(); var result = await TransactionSubmitter.Submit( new SubmitContext( - TransactionApi: coreApiProvider.TransactionsApi, + TransactionApi: coreApiProvider.TransactionApi, TargetNode: chosenNode.Name, - NetworkName: _networkConfigurationProvider.GetNetworkName(), + NetworkName: (await _networkConfigurationProvider.GetNetworkConfiguration(cancellationToken)).Name, SubmissionTimeout: _mempoolOptionsMonitor.CurrentValue.ResubmissionNodeRequestTimeout, IsResubmission: true, ForceNodeToRecalculateResult: false), @@ -299,19 +300,10 @@ private async Task Resubmit(PendingTransactionWithCh return new ContextualSubmissionResult(transaction, chosenNode.Name, result); } - private CoreApiNode GetRandomCoreApi() - { - return _networkOptionsMonitor - .CurrentValue - .CoreApiNodes - .Where(n => n.Enabled && !n.DisabledForConstruction) - .GetRandomBy(n => (double)n.RequestWeighting); - } - - private async Task GetCurrentEpoch(CancellationToken cancellationToken) + private async Task GetCurrentEpoch(CancellationToken cancellationToken) { var topOfLedger = await _topOfLedgerProvider.GetTopOfLedger(cancellationToken); var signedEpoch = topOfLedger.Epoch; - return (signedEpoch >= 0) ? (ulong)signedEpoch : throw new InvalidStateException($"Epoch was negative: {signedEpoch}"); + return (signedEpoch >= 0) ? signedEpoch : throw new InvalidStateException($"Epoch was negative: {signedEpoch}"); } } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/RoleAssignmentsKeyProvider.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/RoleAssignmentsKeyProvider.cs index 248cd2819..a3f089e65 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/RoleAssignmentsKeyProvider.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/RoleAssignmentsKeyProvider.cs @@ -62,7 +62,6 @@ * permissions under this License. */ -using RadixDlt.NetworkGateway.Abstractions.Model; using System.Collections.Generic; using System.Linq; using CoreModel = RadixDlt.CoreApiSdk.Model; @@ -78,7 +77,11 @@ internal record BlueprintDefinitionIdentifier(string Name, string Version, long internal interface IRoleAssignmentsKeyProvider { - List GetNativeModulesKeys(); + List AllNativeModulesKeys { get; } + + List MetadataModulesKeys { get; } + + List RoyaltyModulesKeys { get; } List ExtractKeysFromBlueprintAuthConfig(CoreModel.AuthConfig authConfig); } @@ -89,20 +92,22 @@ internal class RoleAssignmentsKeyProvider : IRoleAssignmentsKeyProvider private static readonly string[] _royaltyRuleKeys = { "royalty_setter", "royalty_locker", "royalty_claimer", }; - private readonly List _nativeModulesKeys; + public List AllNativeModulesKeys { get; } + + public List MetadataModulesKeys { get; } + + public List RoyaltyModulesKeys { get; } public RoleAssignmentsKeyProvider() { - var metadataWithUpdaterKeys = GetKeysWithUpdaterRoles(_metadataRuleKeys, GatewayModel.ModuleId.Metadata); - var royaltyWithUpdaterKeys = GetKeysWithUpdaterRoles(_royaltyRuleKeys, GatewayModel.ModuleId.Royalty); + MetadataModulesKeys = GetKeysWithUpdaterRoles(_metadataRuleKeys, GatewayModel.ModuleId.Metadata); + RoyaltyModulesKeys = GetKeysWithUpdaterRoles(_royaltyRuleKeys, GatewayModel.ModuleId.Royalty); - _nativeModulesKeys = metadataWithUpdaterKeys - .Concat(royaltyWithUpdaterKeys) + AllNativeModulesKeys = MetadataModulesKeys + .Concat(RoyaltyModulesKeys) .ToList(); } - public List GetNativeModulesKeys() => _nativeModulesKeys; - public List ExtractKeysFromBlueprintAuthConfig(CoreModel.AuthConfig authConfig) { return authConfig @@ -110,8 +115,8 @@ public List ExtractKeysFromBlueprintAuthConfig(CoreModel.Au ?.Roles ?.Select(x => new RoleAssignmentEntry( - new RoleAssignmentRuleKey(x.Key, ModuleId.Main), - x.Value.UpdaterRoles.Select(u => new RoleAssignmentRuleKey(u, ModuleId.Main)).ToArray() + new RoleAssignmentRuleKey(x.Key, GatewayModel.ModuleId.Main), + x.Value.UpdaterRoles.Select(u => new RoleAssignmentRuleKey(u, GatewayModel.ModuleId.Main)).ToArray() )) .ToList() ?? new List(); } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/RoleAssignmentsMapper.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/RoleAssignmentsMapper.cs index cf89a8591..aaa1e764e 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/RoleAssignmentsMapper.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/RoleAssignmentsMapper.cs @@ -96,7 +96,7 @@ public RoleAssignmentsMapper(IRoleAssignmentsKeyProvider roleAssignmentsKeyProvi ICollection ownerRoles, ICollection roleAssignments) { - var nativeModulesKeys = _roleAssignmentsKeyProvider.GetNativeModulesKeys(); + var nativeModulesKeys = _roleAssignmentsKeyProvider.AllNativeModulesKeys; return componentEntities.ToDictionary(entity => entity.Id, entity => { @@ -116,7 +116,8 @@ public RoleAssignmentsMapper(IRoleAssignmentsKeyProvider roleAssignmentsKeyProvi var mainModuleKeys = _roleAssignmentsKeyProvider.ExtractKeysFromBlueprintAuthConfig(authConfig!); - var allModulesKeys = mainModuleKeys.Concat(nativeModulesKeys).ToList(); + var assignedNativeModuleKeys = nativeModulesKeys.Where(x => entity.AssignedModuleIds.Contains(x.Key.ModuleId)); + var allModulesKeys = mainModuleKeys.Concat(assignedNativeModuleKeys).ToList(); return new GatewayApiSdk.Model.ComponentEntityRoleAssignments( new JRaw(ownerRole), diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/SubmissionTrackingService.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/SubmissionTrackingService.cs index 6dbf38f00..9e71f9064 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/SubmissionTrackingService.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/SubmissionTrackingService.cs @@ -65,7 +65,6 @@ using Microsoft.EntityFrameworkCore; using Microsoft.Extensions.Logging; using Npgsql; -using RadixDlt.CoreApiSdk.Api; using RadixDlt.NetworkGateway.Abstractions; using RadixDlt.NetworkGateway.Abstractions.Configuration; using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; @@ -78,7 +77,7 @@ using System.Linq; using System.Threading; using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; +using CoreApi = RadixDlt.CoreApiSdk.Api; using ToolkitModel = RadixEngineToolkit; namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; @@ -103,7 +102,7 @@ public SubmissionTrackingService( } public async Task ObserveSubmissionToGatewayAndSubmitToNetworkIfNew( - TransactionApi transactionApi, + CoreApi.TransactionApi transactionApi, string networkName, string nodeName, PendingTransactionHandlingConfig handlingConfig, @@ -186,7 +185,7 @@ private async Task TrackSubmission( handlingConfig, payloadHash, notarizedTransaction.IntentHash().AsStr(), - notarizedTransaction.SignedIntent().Intent().Header().endEpochExclusive, + (long)notarizedTransaction.SignedIntent().Intent().Header().endEpochExclusive, notarizedTransactionBytes, submittedTimestamp ); @@ -232,7 +231,7 @@ CancellationToken token nodeName, nodeSubmissionResult, _clock.UtcNow, - currentEpoch < 0 ? null : (ulong)currentEpoch); + currentEpoch < 0 ? null : currentEpoch); await _dbContext.SaveChangesAsync(token); } diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TopOfLedgerProvider.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TopOfLedgerProvider.cs index d8d21f7a5..a7f88f9e9 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TopOfLedgerProvider.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TopOfLedgerProvider.cs @@ -63,6 +63,7 @@ */ using Microsoft.EntityFrameworkCore; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.DataAggregator.Services; using System; using System.Linq; @@ -117,7 +118,7 @@ public async Task GetTopOfLedger(CancellationToken token) .FirstOrDefaultAsync(token); return lastTransaction == null - ? PreGenesisTransactionSummary() + ? await PreGenesisTransactionSummary() : new TransactionSummary( StateVersion: lastTransaction.StateVersion, TransactionTreeHash: lastTransaction.TransactionTreeHash, @@ -133,7 +134,7 @@ public async Task GetTopOfLedger(CancellationToken token) ); } - private TransactionSummary PreGenesisTransactionSummary() + private async Task PreGenesisTransactionSummary() { // Nearly all of theses turn out to be unused! return new TransactionSummary( @@ -144,8 +145,8 @@ private TransactionSummary PreGenesisTransactionSummary() RoundTimestamp: DateTimeOffset.FromUnixTimeSeconds(0).UtcDateTime, NormalizedRoundTimestamp: DateTimeOffset.FromUnixTimeSeconds(0).UtcDateTime, CreatedTimestamp: _clock.UtcNow, - Epoch: _networkConfigurationProvider.GetGenesisEpoch(), - RoundInEpoch: _networkConfigurationProvider.GetGenesisRound(), + Epoch: (await _networkConfigurationProvider.GetNetworkConfiguration()).GenesisEpoch, + RoundInEpoch: (await _networkConfigurationProvider.GetNetworkConfiguration()).GenesisRound, IndexInEpoch: -1, // invalid, but we increase it by one to in ProcessTransactions IndexInRound: -1 // invalid, but we increase it by one to in ProcessTransactions ); diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TransactionBalanceChangesService.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TransactionBalanceChangesService.cs deleted file mode 100644 index 069822801..000000000 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TransactionBalanceChangesService.cs +++ /dev/null @@ -1,173 +0,0 @@ -/* Copyright 2021 Radix Publishing Ltd incorporated in Jersey (Channel Islands). - * - * Licensed under the Radix License, Version 1.0 (the "License"); you may not use this - * file except in compliance with the License. You may obtain a copy of the License at: - * - * radixfoundation.org/licenses/LICENSE-v1 - * - * The Licensor hereby grants permission for the Canonical version of the Work to be - * published, distributed and used under or by reference to the Licensor’s trademark - * Radix ® and use of any unregistered trade names, logos or get-up. - * - * The Licensor provides the Work (and each Contributor provides its Contributions) on an - * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, - * including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, - * MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. - * - * Whilst the Work is capable of being deployed, used and adopted (instantiated) to create - * a distributed ledger it is your responsibility to test and validate the code, together - * with all logic and performance of that code under all foreseeable scenarios. - * - * The Licensor does not make or purport to make and hereby excludes liability for all - * and any representation, warranty or undertaking in any form whatsoever, whether express - * or implied, to any entity or person, including any representation, warranty or - * undertaking, as to the functionality security use, value or other characteristics of - * any distributed ledger nor in respect the functioning or value of any tokens which may - * be created stored or transferred using the Work. The Licensor does not warrant that the - * Work or any use of the Work complies with any law or regulation in any territory where - * it may be implemented or used or that it will be appropriate for any specific purpose. - * - * Neither the licensor nor any current or former employees, officers, directors, partners, - * trustees, representatives, agents, advisors, contractors, or volunteers of the Licensor - * shall be liable for any direct or indirect, special, incidental, consequential or other - * losses of any kind, in tort, contract or otherwise (including but not limited to loss - * of revenue, income or profits, or loss of use or data, or loss of reputation, or loss - * of any economic or other opportunity of whatsoever nature or howsoever arising), arising - * out of or in connection with (without limitation of any use, misuse, of any ledger system - * or use made or its functionality or any performance or operation of any code or protocol - * caused by bugs or programming or logic errors or otherwise); - * - * A. any offer, purchase, holding, use, sale, exchange or transmission of any - * cryptographic keys, tokens or assets created, exchanged, stored or arising from any - * interaction with the Work; - * - * B. any failure in a transmission or loss of any token or assets keys or other digital - * artefacts due to errors in transmission; - * - * C. bugs, hacks, logic errors or faults in the Work or any communication; - * - * D. system software or apparatus including but not limited to losses caused by errors - * in holding or transmitting tokens by any third-party; - * - * E. breaches or failure of security including hacker attacks, loss or disclosure of - * password, loss of private key, unauthorised use or misuse of such passwords or keys; - * - * F. any losses including loss of anticipated savings or other benefits resulting from - * use of the Work or any changes to the Work (however implemented). - * - * You are solely responsible for; testing, validating and evaluation of all operation - * logic, functionality, security and appropriateness of using the Work for any commercial - * or non-commercial purpose and for any reproduction or redistribution by You of the - * Work. You assume all risks associated with Your use of the Work and the exercise of - * permissions under this License. - */ - -using Microsoft.Extensions.Logging; -using Microsoft.Extensions.Options; -using Newtonsoft.Json; -using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.GatewayApi.Configuration; -using RadixDlt.NetworkGateway.GatewayApi.CoreCommunications; -using RadixDlt.NetworkGateway.GatewayApi.Services; -using RadixDlt.NetworkGateway.PostgresIntegration.Models; -using System; -using System.Collections.Concurrent; -using System.Collections.Generic; -using System.Linq; -using System.Threading; -using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; -using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; - -namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; - -internal interface ITransactionBalanceChangesService -{ - Task> GetTransactionBalanceChanges(List transactions, CancellationToken token = default); -} - -internal class TransactionBalanceChangesService : ITransactionBalanceChangesService -{ - private readonly ICoreApiHandler _coreApiHandler; - private readonly IEnumerable _observers; - private readonly IOptionsMonitor _coreApiIntegrationOptionsMonitor; - private readonly ILogger _logger; - - public TransactionBalanceChangesService( - ICoreApiHandler coreApiHandler, - IEnumerable observers, - IOptionsMonitor coreApiIntegrationOptionsMonitor, - ILogger logger) - { - _coreApiHandler = coreApiHandler; - _observers = observers; - _coreApiIntegrationOptionsMonitor = coreApiIntegrationOptionsMonitor; - _logger = logger; - } - - public async Task> GetTransactionBalanceChanges(List transactions, CancellationToken token = default) - { - var result = new ConcurrentDictionary(); - var options = new ParallelOptions - { - MaxDegreeOfParallelism = _coreApiIntegrationOptionsMonitor.CurrentValue.TransactionBalanceChangesMaxDegreeOfParallelism, - CancellationToken = token, - }; - - await Parallel.ForEachAsync(transactions, options, async (transaction, cancellationToken) => - { - try - { - if (transaction.BalanceChanges != null) - { - var storedBalanceChanges = JsonConvert.DeserializeObject(transaction.BalanceChanges); - - if (storedBalanceChanges == null) - { - throw new InvalidOperationException("Unable to deserialize stored balance changes into CoreModel.CommittedTransactionBalanceChanges"); - } - - result.TryAdd(transaction.StateVersion, storedBalanceChanges.ToGatewayModel()); - - return; - } - - var selectedNode = _coreApiHandler.GetCoreNodeConnectedTo(); - await _observers.ForEachAsync(x => x.PreHandleOutcomeRequest(transaction.StateVersion, selectedNode.Name)); - - var coreRequest = new CoreModel.LtsStreamTransactionOutcomesRequest( - network: _coreApiHandler.GetNetworkName(), - fromStateVersion: transaction.StateVersion, - limit: 1); - - var balanceChangesResult = await _coreApiHandler.TransactionOutcome(coreRequest, cancellationToken); - - if (!balanceChangesResult.Succeeded) - { - throw balanceChangesResult.FailureResponse.OriginalApiException; - } - - var balanceChanges = balanceChangesResult.SuccessResponse.CommittedTransactionOutcomes.FirstOrDefault(); - - if (balanceChanges == null) - { - return; - } - - await _observers.ForEachAsync(x => x.PostHandleOutcomeRequest(transaction.StateVersion, selectedNode.Name)); - - result.TryAdd(transaction.StateVersion, balanceChanges.ToGatewayModel()); - } - catch (Exception ex) - { - _logger.LogError(ex, "Failed to load transaction balance changes for {StateVersion}", transaction.StateVersion); - - var selectedNode = _coreApiHandler.GetCoreNodeConnectedTo(); - - await _observers.ForEachAsync(x => x.HandleOutcomeRequestFailed(transaction.StateVersion, selectedNode.Name, ex)); - } - }); - - return result.ToDictionary(kvp => kvp.Key, kvp => kvp.Value); - } -} diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TransactionQuerier.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TransactionQuerier.cs index 9661266d4..b11fb8e37 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TransactionQuerier.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/TransactionQuerier.cs @@ -63,9 +63,11 @@ */ using Microsoft.EntityFrameworkCore; +using Newtonsoft.Json; using RadixDlt.NetworkGateway.Abstractions; using RadixDlt.NetworkGateway.Abstractions.Extensions; using RadixDlt.NetworkGateway.Abstractions.Model; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.GatewayApi.Services; using RadixDlt.NetworkGateway.PostgresIntegration.Interceptors; using RadixDlt.NetworkGateway.PostgresIntegration.Models; @@ -89,18 +91,15 @@ internal record Event(string Name, string Emitter, GatewayModel.ProgrammaticScry private readonly ReadOnlyDbContext _dbContext; private readonly ReadWriteDbContext _rwDbContext; private readonly INetworkConfigurationProvider _networkConfigurationProvider; - private readonly ITransactionBalanceChangesService _transactionBalanceChangesService; public TransactionQuerier( ReadOnlyDbContext dbContext, ReadWriteDbContext rwDbContext, - INetworkConfigurationProvider networkConfigurationProvider, - ITransactionBalanceChangesService transactionBalanceChangesService) + INetworkConfigurationProvider networkConfigurationProvider) { _dbContext = dbContext; _rwDbContext = rwDbContext; _networkConfigurationProvider = networkConfigurationProvider; - _transactionBalanceChangesService = transactionBalanceChangesService; } public async Task GetTransactionStream(TransactionStreamPageRequest request, GatewayModel.LedgerState atLedgerState, CancellationToken token = default) @@ -108,6 +107,8 @@ public async Task GetTransactionStream(TransactionS var referencedAddresses = request .SearchCriteria .ManifestAccountsDepositedInto + .Concat(request.SearchCriteria.AccountsWithManifestOwnerMethodCalls) + .Concat(request.SearchCriteria.AccountsWithoutManifestOwnerMethodCalls) .Concat(request.SearchCriteria.ManifestAccountsWithdrawnFrom) .Concat(request.SearchCriteria.ManifestResources) .Concat(request.SearchCriteria.AffectedGlobalEntities) @@ -270,6 +271,76 @@ public async Task GetTransactionStream(TransactionS } } + if (request.SearchCriteria.ManifestClassFilter != null) + { + userKindFilterImplicitlyApplied = true; + + var manifestClass = request.SearchCriteria.ManifestClassFilter.Class switch + { + LedgerTransactionManifestClass.General => LedgerTransactionManifestClass.General, + LedgerTransactionManifestClass.Transfer => LedgerTransactionManifestClass.Transfer, + LedgerTransactionManifestClass.ValidatorStake => LedgerTransactionManifestClass.ValidatorStake, + LedgerTransactionManifestClass.ValidatorUnstake => LedgerTransactionManifestClass.ValidatorUnstake, + LedgerTransactionManifestClass.ValidatorClaim => LedgerTransactionManifestClass.ValidatorClaim, + LedgerTransactionManifestClass.AccountDepositSettingsUpdate => LedgerTransactionManifestClass.AccountDepositSettingsUpdate, + LedgerTransactionManifestClass.PoolContribution => LedgerTransactionManifestClass.PoolContribution, + LedgerTransactionManifestClass.PoolRedemption => LedgerTransactionManifestClass.PoolRedemption, + _ => throw new UnreachableException($"Didn't expect {request.SearchCriteria.ManifestClassFilter.Class} value"), + }; + + searchQuery = searchQuery + .Join(_dbContext.LedgerTransactionMarkers, sv => sv, ltm => ltm.StateVersion, (sv, ltm) => ltm) + .OfType() + .Where(ttm => ttm.LedgerTransactionManifestClass == manifestClass) + .Where(ttm => (request.SearchCriteria.ManifestClassFilter.MatchOnlyMostSpecificType && ttm.IsMostSpecific) || !request.SearchCriteria.ManifestClassFilter.MatchOnlyMostSpecificType) + .Where(eltm => eltm.StateVersion <= upperStateVersion && eltm.StateVersion >= (lowerStateVersion ?? eltm.StateVersion)) + .Select(eltm => eltm.StateVersion); + } + + if (request.SearchCriteria.AccountsWithManifestOwnerMethodCalls.Any()) + { + userKindFilterImplicitlyApplied = true; + + foreach (var entityAddress in request.SearchCriteria.AccountsWithManifestOwnerMethodCalls) + { + if (!entityAddressToId.TryGetValue(entityAddress, out var entityId)) + { + return TransactionPageWithoutTotal.Empty; + } + + searchQuery = searchQuery + .Join( + _dbContext.LedgerTransactionMarkers, + stateVersion => stateVersion, + ledgerTransactionMarker => ledgerTransactionMarker.StateVersion, + (stateVersion, ledgerTransactionMarker) => ledgerTransactionMarker) + .OfType() + .Where(maltm => maltm.OperationType == LedgerTransactionMarkerOperationType.AccountOwnerMethodCall && maltm.EntityId == entityId) + .Where(maltm => maltm.StateVersion <= upperStateVersion && maltm.StateVersion >= (lowerStateVersion ?? maltm.StateVersion)) + .Select(maltm => maltm.StateVersion); + } + } + + if (request.SearchCriteria.AccountsWithoutManifestOwnerMethodCalls.Any()) + { + foreach (var entityAddress in request.SearchCriteria.AccountsWithoutManifestOwnerMethodCalls) + { + if (!entityAddressToId.TryGetValue(entityAddress, out var entityId)) + { + return TransactionPageWithoutTotal.Empty; + } + + var withManifestOwnerCall = _dbContext + .LedgerTransactionMarkers + .OfType() + .Where(maltm => maltm.OperationType == LedgerTransactionMarkerOperationType.AccountOwnerMethodCall && maltm.EntityId == entityId) + .Where(maltm => maltm.StateVersion <= upperStateVersion && maltm.StateVersion >= (lowerStateVersion ?? maltm.StateVersion)) + .Select(y => y.StateVersion); + + searchQuery = searchQuery.Where(x => withManifestOwnerCall.All(y => y != x)); + } + } + if (request.SearchCriteria.Kind == LedgerTransactionKindFilter.UserOnly && userKindFilterImplicitlyApplied) { // already handled @@ -344,219 +415,12 @@ public async Task GetTransactionStream(TransactionS return transactions.First(); } - private record CommittedTransactionSummary( + internal record CommittedTransactionSummary( long StateVersion, string PayloadHash, LedgerTransactionStatus Status, string? ErrorMessage); - private record PendingTransactionSummary( - string PayloadHash, - ulong EndEpochExclusive, - DateTime? ResubmitFromTimestamp, - string? HandlingStatusReason, - PendingTransactionPayloadLedgerStatus PayloadStatus, - PendingTransactionIntentLedgerStatus IntentStatus, - string? InitialRejectionReason, - string? LatestRejectionReason, - string? LastSubmissionError); - - private class PendingTransactionResponseAggregator - { - private readonly GatewayModel.LedgerState _ledgerState; - private readonly string? _committedPayloadHash; - private readonly long? _committedStateVersion; - private readonly List _knownPayloads = new(); - private readonly GatewayModel.TransactionIntentStatus? _committedIntentStatus; - private readonly string? _committedErrorMessage; - private PendingTransactionIntentLedgerStatus _mostAccuratePendingTransactionIntentLedgerStatus = PendingTransactionIntentLedgerStatus.Unknown; - private string? _rejectionReasonForMostAccurateIntentLedgerStatus; - - internal PendingTransactionResponseAggregator(GatewayModel.LedgerState ledgerState, CommittedTransactionSummary? committedTransactionSummary) - { - _ledgerState = ledgerState; - - if (committedTransactionSummary is null) - { - return; - } - - _committedPayloadHash = committedTransactionSummary.PayloadHash; - _committedStateVersion = committedTransactionSummary.StateVersion; - - var (legacyStatus, payloadStatus, intentStatus) = committedTransactionSummary.Status switch - { - LedgerTransactionStatus.Succeeded => (GatewayModel.TransactionStatus.CommittedSuccess, GatewayModel.TransactionPayloadStatus.CommittedSuccess, GatewayModel.TransactionIntentStatus.CommittedSuccess), - LedgerTransactionStatus.Failed => (GatewayModel.TransactionStatus.CommittedFailure, GatewayModel.TransactionPayloadStatus.CommittedFailure, GatewayModel.TransactionIntentStatus.CommittedFailure), - }; - - _committedIntentStatus = intentStatus; - _committedErrorMessage = committedTransactionSummary.ErrorMessage; - - _knownPayloads.Add(new GatewayModel.TransactionStatusResponseKnownPayloadItem( - payloadHash: committedTransactionSummary.PayloadHash, - status: legacyStatus, - payloadStatus: payloadStatus, - payloadStatusDescription: GetPayloadStatusDescription(payloadStatus), - errorMessage: committedTransactionSummary.ErrorMessage, - handlingStatus: GatewayModel.TransactionPayloadGatewayHandlingStatus.Concluded, - handlingStatusReason: "The transaction is committed", - submissionError: null - )); - } - - internal void AddPendingTransaction(PendingTransactionSummary pendingTransactionSummary) - { - if (pendingTransactionSummary.PayloadHash == _committedPayloadHash) - { - return; - } - - var (legacyStatus, payloadStatus) = pendingTransactionSummary.PayloadStatus switch - { - PendingTransactionPayloadLedgerStatus.Unknown => (GatewayModel.TransactionStatus.Unknown, GatewayModel.TransactionPayloadStatus.Unknown), - PendingTransactionPayloadLedgerStatus.Committed => (GatewayModel.TransactionStatus.Pending, GatewayModel.TransactionPayloadStatus.CommitPendingOutcomeUnknown), - PendingTransactionPayloadLedgerStatus.CommitPending => (GatewayModel.TransactionStatus.Pending, GatewayModel.TransactionPayloadStatus.CommitPendingOutcomeUnknown), - PendingTransactionPayloadLedgerStatus.ClashingCommit => (GatewayModel.TransactionStatus.Rejected, GatewayModel.TransactionPayloadStatus.PermanentlyRejected), - PendingTransactionPayloadLedgerStatus.PermanentlyRejected => (GatewayModel.TransactionStatus.Rejected, GatewayModel.TransactionPayloadStatus.PermanentlyRejected), - PendingTransactionPayloadLedgerStatus.TransientlyAccepted => (GatewayModel.TransactionStatus.Pending, GatewayModel.TransactionPayloadStatus.Pending), - PendingTransactionPayloadLedgerStatus.TransientlyRejected => (GatewayModel.TransactionStatus.Pending, GatewayModel.TransactionPayloadStatus.TemporarilyRejected), - }; - - var handlingStatus = pendingTransactionSummary.ResubmitFromTimestamp switch - { - not null => GatewayModel.TransactionPayloadGatewayHandlingStatus.HandlingSubmission, - null => GatewayModel.TransactionPayloadGatewayHandlingStatus.Concluded, - }; - - if (pendingTransactionSummary.IntentStatus.AggregationPriorityAcrossKnownPayloads() >= _mostAccuratePendingTransactionIntentLedgerStatus.AggregationPriorityAcrossKnownPayloads()) - { - _mostAccuratePendingTransactionIntentLedgerStatus = pendingTransactionSummary.IntentStatus; - _rejectionReasonForMostAccurateIntentLedgerStatus = pendingTransactionSummary.LatestRejectionReason; - } - - var initialRejectionReason = pendingTransactionSummary.InitialRejectionReason; - var latestRejectionReason = pendingTransactionSummary.LatestRejectionReason; - - // If the intent's EndEpochExclusive has been reached, then the payload and intent must be permanently rejected (assuming they're not already committed). - if ((ulong)_ledgerState.Epoch >= pendingTransactionSummary.EndEpochExclusive) - { - // The if statement is defence-in-depth to avoid replacing a Committed status with PermanentlyRejected. - // This shouldn't matter, because we'd see a committed transaction in this case, which would trump the _mostAccuratePendingTransactionIntentLedgerStatus when we - // resolve the status. But best to be defensive anyway. - if (PendingTransactionIntentLedgerStatus.PermanentRejection.AggregationPriorityAcrossKnownPayloads() >= - _mostAccuratePendingTransactionIntentLedgerStatus.AggregationPriorityAcrossKnownPayloads()) - { - _mostAccuratePendingTransactionIntentLedgerStatus = PendingTransactionIntentLedgerStatus.PermanentRejection; - _rejectionReasonForMostAccurateIntentLedgerStatus = $"Transaction has expired, as its expiry epoch of {pendingTransactionSummary.EndEpochExclusive} has been reached."; - } - - // The if statement is defence-in-depth to avoid replacing a Committed status with PermanentlyRejected. - // (Even though this shouldn't be possible because of the early return if pendingTransactionSummary.PayloadHash == _committedPayloadHash) - if (PendingTransactionPayloadLedgerStatus.PermanentlyRejected.ReplacementPriority() >= pendingTransactionSummary.PayloadStatus.ReplacementPriority()) - { - payloadStatus = GatewayModel.TransactionPayloadStatus.PermanentlyRejected; - legacyStatus = GatewayModel.TransactionStatus.Rejected; - latestRejectionReason = $"Transaction has expired, as its expiry epoch of {pendingTransactionSummary.EndEpochExclusive} has been reached."; - initialRejectionReason ??= latestRejectionReason; - } - } - - _knownPayloads.Add(new GatewayModel.TransactionStatusResponseKnownPayloadItem( - payloadHash: pendingTransactionSummary.PayloadHash, - status: legacyStatus, - payloadStatus: payloadStatus, - payloadStatusDescription: GetPayloadStatusDescription(payloadStatus), - errorMessage: initialRejectionReason, - latestErrorMessage: latestRejectionReason == initialRejectionReason ? null : latestRejectionReason, - handlingStatus: handlingStatus, - handlingStatusReason: pendingTransactionSummary.HandlingStatusReason, - submissionError: pendingTransactionSummary.LastSubmissionError - )); - } - - internal GatewayModel.TransactionStatusResponse IntoResponse() - { - var (intentStatus, errorMessage) = _committedIntentStatus != null - ? (_committedIntentStatus.Value, _committedErrorMessage) - : ( - _mostAccuratePendingTransactionIntentLedgerStatus switch - { - PendingTransactionIntentLedgerStatus.Unknown => GatewayModel.TransactionIntentStatus.Unknown, - PendingTransactionIntentLedgerStatus.Committed => GatewayModel.TransactionIntentStatus.CommitPendingOutcomeUnknown, - PendingTransactionIntentLedgerStatus.CommitPending => GatewayModel.TransactionIntentStatus.CommitPendingOutcomeUnknown, - PendingTransactionIntentLedgerStatus.PermanentRejection => GatewayModel.TransactionIntentStatus.PermanentlyRejected, - PendingTransactionIntentLedgerStatus.PossibleToCommit => GatewayModel.TransactionIntentStatus.Pending, - PendingTransactionIntentLedgerStatus.LikelyButNotCertainRejection => GatewayModel.TransactionIntentStatus.LikelyButNotCertainRejection, - }, - _rejectionReasonForMostAccurateIntentLedgerStatus - ); - - var legacyIntentStatus = intentStatus switch - { - GatewayModel.TransactionIntentStatus.Unknown => GatewayModel.TransactionStatus.Unknown, - GatewayModel.TransactionIntentStatus.CommittedSuccess => GatewayModel.TransactionStatus.CommittedSuccess, - GatewayModel.TransactionIntentStatus.CommittedFailure => GatewayModel.TransactionStatus.CommittedFailure, - GatewayModel.TransactionIntentStatus.CommitPendingOutcomeUnknown => GatewayModel.TransactionStatus.Pending, - GatewayModel.TransactionIntentStatus.PermanentlyRejected => GatewayModel.TransactionStatus.Rejected, - GatewayModel.TransactionIntentStatus.LikelyButNotCertainRejection => GatewayModel.TransactionStatus.Pending, - GatewayModel.TransactionIntentStatus.Pending => GatewayModel.TransactionStatus.Pending, - }; - - return new GatewayModel.TransactionStatusResponse( - ledgerState: _ledgerState, - status: legacyIntentStatus, - intentStatus, - intentStatusDescription: GetIntentStatusDescription(intentStatus), - knownPayloads: _knownPayloads, - committedStateVersion: _committedStateVersion, - errorMessage - ); - } - - private string GetPayloadStatusDescription(GatewayModel.TransactionPayloadStatus payloadStatus) - { - return payloadStatus switch - { - GatewayModel.TransactionPayloadStatus.Unknown => - "No information is known about the possible outcome of this transaction payload.", - GatewayModel.TransactionPayloadStatus.CommittedSuccess => - "This particular payload for this transaction has been committed to the ledger as a success. For more information, use the /transaction/committed-details endpoint.", - GatewayModel.TransactionPayloadStatus.CommittedFailure => - "This particular payload for this transaction has been committed to the ledger as a failure. For more information, use the /transaction/committed-details endpoint.", - GatewayModel.TransactionPayloadStatus.CommitPendingOutcomeUnknown => - "This particular payload for this transaction has been committed to the ledger, but the Gateway is still waiting for further details about its result.", - GatewayModel.TransactionPayloadStatus.PermanentlyRejected => - "This particular payload for this transaction has been permanently rejected. It is not possible for this particular transaction payload to be committed to this network.", - GatewayModel.TransactionPayloadStatus.TemporarilyRejected => - "This particular payload for this transaction was rejected at its last execution. It may still be possible for this transaction payload to be committed to this network.", - GatewayModel.TransactionPayloadStatus.Pending => - "This particular payload for this transaction has been accepted into a node's mempool on the network. It's possible but not certain that it will be committed to this network.", - }; - } - - private string GetIntentStatusDescription(GatewayModel.TransactionIntentStatus intentStatus) - { - return intentStatus switch - { - GatewayModel.TransactionIntentStatus.Unknown => - "No information is known about the possible outcome of this transaction.", - GatewayModel.TransactionIntentStatus.CommittedSuccess => - "This transaction has been committed to the ledger as a success. For more information, use the /transaction/committed-details endpoint.", - GatewayModel.TransactionIntentStatus.CommittedFailure => - "This transaction has been committed to the ledger as a failure. For more information, use the /transaction/committed-details endpoint.", - GatewayModel.TransactionIntentStatus.CommitPendingOutcomeUnknown => - "This transaction has been committed to the ledger, but the Gateway is still waiting for further details about its result.", - GatewayModel.TransactionIntentStatus.PermanentlyRejected => - "This transaction is permanently rejected, so can never be committed to this network.", - GatewayModel.TransactionIntentStatus.Pending => - "A payload for this transaction has been accepted into a node's mempool on the network. It's possible but not certain that it will be committed to this network.", - GatewayModel.TransactionIntentStatus.LikelyButNotCertainRejection => - "All known payload/s for this transaction have been temporarily rejected at their last execution. It may still be possible for this transaction to be committed to this network.", - }; - } - } - public async Task ResolveTransactionStatusResponse(GatewayModel.LedgerState ledgerState, string intentHash, CancellationToken token = default) { var maybeCommittedTransactionSummary = await _dbContext @@ -623,7 +487,8 @@ WITH configuration AS ( {optIns.ReceiptOutput} AS with_receipt_output, {optIns.ReceiptStateChanges} AS with_receipt_state_updates, {optIns.ReceiptEvents} AS with_receipt_events, - {optIns.BalanceChanges} AS with_balance_changes + {optIns.BalanceChanges} AS with_balance_changes, + {optIns.ManifestInstructions} AS with_manifest_instructions ) SELECT state_version, epoch, round_in_epoch, index_in_epoch, @@ -631,7 +496,7 @@ WITH configuration AS ( round_timestamp, created_timestamp, normalized_round_timestamp, receipt_status, receipt_fee_source, receipt_fee_destination, receipt_error_message, transaction_tree_hash, receipt_tree_hash, state_tree_hash, - discriminator, payload_hash, intent_hash, signed_intent_hash, message, + discriminator, payload_hash, intent_hash, signed_intent_hash, message, manifest_classes, CASE WHEN configuration.with_raw_payload THEN raw_payload ELSE ''::bytea END AS raw_payload, CASE WHEN configuration.with_receipt_costing_parameters THEN receipt_costing_parameters ELSE '{{}}'::jsonb END AS receipt_costing_parameters, CASE WHEN configuration.with_receipt_fee_summary THEN receipt_fee_summary ELSE '{{}}'::jsonb END AS receipt_fee_summary, @@ -645,7 +510,8 @@ WITH configuration AS ( CASE WHEN configuration.with_receipt_events THEN receipt_event_schema_hashes ELSE '{{}}'::bytea[] END AS receipt_event_schema_hashes, CASE WHEN configuration.with_receipt_events THEN receipt_event_type_indexes ELSE '{{}}'::bigint[] END AS receipt_event_type_indexes, CASE WHEN configuration.with_receipt_events THEN receipt_event_sbor_type_kinds ELSE '{{}}'::sbor_type_kind[] END AS receipt_event_sbor_type_kinds, - CASE WHEN configuration.with_balance_changes THEN balance_changes ELSE '{{}}'::jsonb END AS balance_changes + CASE WHEN configuration.with_balance_changes THEN balance_changes ELSE '{{}}'::jsonb END AS balance_changes, + CASE WHEN configuration.with_manifest_instructions THEN manifest_instructions ELSE ''::text END AS manifest_instructions FROM ledger_transactions, configuration WHERE state_version = ANY({transactionStateVersions})") .AnnotateMetricName("GetTransactions") @@ -678,20 +544,23 @@ FROM variables var } List mappedTransactions = new List(); - var networkId = _networkConfigurationProvider.GetNetworkId(); - - Dictionary? balanceChangesPerTransaction = null; - - if (optIns.BalanceChanges) - { - balanceChangesPerTransaction = await _transactionBalanceChangesService.GetTransactionBalanceChanges(transactions, token); - } + var networkId = (await _networkConfigurationProvider.GetNetworkConfiguration(token)).Id; foreach (var transaction in transactions.OrderBy(lt => transactionStateVersions.IndexOf(lt.StateVersion)).ToList()) { GatewayModel.TransactionBalanceChanges? balanceChanges = null; - balanceChangesPerTransaction?.TryGetValue(transaction.StateVersion, out balanceChanges); + if (optIns.BalanceChanges && transaction.BalanceChanges != null) + { + var storedBalanceChanges = JsonConvert.DeserializeObject(transaction.BalanceChanges); + + if (storedBalanceChanges == null) + { + throw new InvalidOperationException("Unable to deserialize stored balance changes into CoreModel.CommittedTransactionBalanceChanges"); + } + + balanceChanges = storedBalanceChanges.ToGatewayModel(); + } if (!optIns.ReceiptEvents || schemaLookups?.Any() == false) { diff --git a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/VirtualEntityDataProvider.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/VirtualEntityDataProvider.cs index 567a2a176..62dd6666b 100644 --- a/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/VirtualEntityDataProvider.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/Services/VirtualEntityDataProvider.cs @@ -62,13 +62,14 @@ * permissions under this License. */ +using Nito.AsyncEx; using RadixDlt.NetworkGateway.Abstractions; -using RadixDlt.NetworkGateway.Abstractions.Addressing; using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.GatewayApi.Services; +using RadixDlt.NetworkGateway.Abstractions.Network; using System; using System.Collections.Generic; using System.Linq; +using System.Threading.Tasks; using CoreModel = RadixDlt.CoreApiSdk.Model; using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; using ToolkitModel = RadixEngineToolkit; @@ -77,65 +78,72 @@ namespace RadixDlt.NetworkGateway.PostgresIntegration.Services; internal interface IVirtualEntityDataProvider { - public bool IsVirtualAccountAddress(EntityAddress address); + public Task IsVirtualAccountAddress(EntityAddress address); - public bool IsVirtualIdentityAddress(EntityAddress address); + public Task IsVirtualIdentityAddress(EntityAddress address); - (GatewayModel.StateEntityDetailsResponseComponentDetails Details, GatewayModel.EntityMetadataCollection Metadata) GetVirtualEntityData(EntityAddress address); + Task<(GatewayModel.StateEntityDetailsResponseComponentDetails Details, GatewayModel.EntityMetadataCollection Metadata)> GetVirtualEntityData(EntityAddress address); } internal class VirtualEntityDataProvider : IVirtualEntityDataProvider { - private readonly string _accountPackage; - private readonly string _identityPackage; - private readonly byte _networkId; - private readonly byte _secp256k1VirtualAccountDiscriminator; - private readonly byte _ed25519VirtualAccountDiscriminator; - private readonly byte _secp256k1VirtualIdentityDiscriminator; - private readonly byte _ed25519VirtualIdentityDiscriminator; - private readonly string _secp256k1SignatureVirtualBadge; - private readonly string _ed25519SignatureVirtualBadge; - private readonly List _virtualEntityRoleAssignmentEntries; - - public VirtualEntityDataProvider(IRoleAssignmentsKeyProvider roleAssignmentsKeyProvider, INetworkConfigurationProvider networkConfigurationProvider) + private readonly INetworkConfigurationProvider _networkConfigurationProvider; + private readonly AsyncLazy _secp256k1VirtualAccountDiscriminator; + private readonly AsyncLazy _ed25519VirtualAccountDiscriminator; + private readonly AsyncLazy _secp256k1VirtualIdentityDiscriminator; + private readonly AsyncLazy _ed25519VirtualIdentityDiscriminator; + private readonly List _virtualAccountRoleAssignmentEntries; + private readonly List _virtualIdentityRoleAssignmentEntries; + + public VirtualEntityDataProvider(INetworkConfigurationProvider networkConfigurationProvider, IRoleAssignmentsKeyProvider roleAssignmentsKeyProvider) { - _accountPackage = networkConfigurationProvider.GetWellKnownAddresses().AccountPackage; - _identityPackage = networkConfigurationProvider.GetWellKnownAddresses().IdentityPackage; - _networkId = networkConfigurationProvider.GetNetworkId(); - _secp256k1VirtualAccountDiscriminator = (byte)networkConfigurationProvider.GetAddressTypeDefinition(AddressEntityType.GlobalVirtualSecp256k1Account).AddressBytePrefix; - _ed25519VirtualAccountDiscriminator = (byte)networkConfigurationProvider.GetAddressTypeDefinition(AddressEntityType.GlobalVirtualEd25519Account).AddressBytePrefix; - _secp256k1VirtualIdentityDiscriminator = (byte)networkConfigurationProvider.GetAddressTypeDefinition(AddressEntityType.GlobalVirtualSecp256k1Identity).AddressBytePrefix; - _ed25519VirtualIdentityDiscriminator = (byte)networkConfigurationProvider.GetAddressTypeDefinition(AddressEntityType.GlobalVirtualEd25519Identity).AddressBytePrefix; - _secp256k1SignatureVirtualBadge = networkConfigurationProvider.GetWellKnownAddresses().Secp256k1SignatureVirtualBadge; - _ed25519SignatureVirtualBadge = networkConfigurationProvider.GetWellKnownAddresses().Ed25519SignatureVirtualBadge; - _virtualEntityRoleAssignmentEntries = GenerateVirtualEntityRoleAssignmentEntries(roleAssignmentsKeyProvider); + async Task GetAddressBytePrefix(AddressEntityType addressEntityType) + { + var networkConfiguration = await networkConfigurationProvider.GetNetworkConfiguration(); + + return networkConfiguration.AddressTypeDefinitions.First(atd => atd.EntityType == addressEntityType).AddressBytePrefix; + } + + AsyncLazy CreateAsyncLazy(AddressEntityType addressEntityType) + { + return new AsyncLazy(async () => await GetAddressBytePrefix(addressEntityType), AsyncLazyFlags.RetryOnFailure); + } + + _networkConfigurationProvider = networkConfigurationProvider; + _secp256k1VirtualAccountDiscriminator = CreateAsyncLazy(AddressEntityType.GlobalVirtualSecp256k1Account); + _ed25519VirtualAccountDiscriminator = CreateAsyncLazy(AddressEntityType.GlobalVirtualEd25519Account); + _secp256k1VirtualIdentityDiscriminator = CreateAsyncLazy(AddressEntityType.GlobalVirtualSecp256k1Identity); + _ed25519VirtualIdentityDiscriminator = CreateAsyncLazy(AddressEntityType.GlobalVirtualEd25519Identity); + _virtualAccountRoleAssignmentEntries = GenerateVirtualAccountRoleAssignmentEntries(roleAssignmentsKeyProvider); + _virtualIdentityRoleAssignmentEntries = GenerateVirtualIdentityRoleAssignmentEntries(roleAssignmentsKeyProvider); } - public bool IsVirtualAccountAddress(EntityAddress address) + public Task IsVirtualAccountAddress(EntityAddress address) { return IsAccount(DecodeAddress(address, false)); } - public bool IsVirtualIdentityAddress(EntityAddress address) + public Task IsVirtualIdentityAddress(EntityAddress address) { return IsIdentity(DecodeAddress(address, false)); } - public (GatewayModel.StateEntityDetailsResponseComponentDetails Details, GatewayModel.EntityMetadataCollection Metadata) GetVirtualEntityData(EntityAddress address) + public async Task<(GatewayModel.StateEntityDetailsResponseComponentDetails Details, GatewayModel.EntityMetadataCollection Metadata)> GetVirtualEntityData(EntityAddress address) { var decoded = DecodeAddress(address, true); + var networkConfiguration = await _networkConfigurationProvider.GetNetworkConfiguration(); - if (!IsSecp256k1(decoded) && !IsEd25519(decoded)) + if (await IsSecp256k1(decoded) == false && await IsEd25519(decoded) == false) { throw new ArgumentException("Failed to detect key algorithm (ed25519 or secp256k1)", nameof(address)); } - if (!IsAccount(decoded) && !IsIdentity(decoded)) + if (await IsAccount(decoded) == false && await IsIdentity(decoded) == false) { throw new ArgumentException("Failed to detect entity type (account or identity)", nameof(address)); } - ToolkitModel.PublicKeyHash publicKeyHash = IsSecp256k1(decoded) + ToolkitModel.PublicKeyHash publicKeyHash = await IsSecp256k1(decoded) ? new ToolkitModel.PublicKeyHash.Secp256k1(decoded.AddressBytes) : new ToolkitModel.PublicKeyHash.Ed25519(decoded.AddressBytes); @@ -144,19 +152,19 @@ public bool IsVirtualIdentityAddress(EntityAddress address) var ownerKeysBytes = ToolkitModel.RadixEngineToolkitUniffiMethods.MetadataSborEncode(ownedKeysItem); var ownerKeysRawHex = ownerKeysBytes.ToArray().ToHex(); - var ownerKeysProgrammaticJson = ScryptoSborUtils.DataToProgrammaticJson(ownerKeysBytes, _networkId); + var ownerKeysProgrammaticJson = ScryptoSborUtils.DataToProgrammaticJson(ownerKeysBytes, networkConfiguration.Id); var ownerBadgeBytes = ToolkitModel.RadixEngineToolkitUniffiMethods.MetadataSborEncode(ownerBadgeItem); var ownerBadgeRawHex = ownerBadgeBytes.ToArray().ToHex(); - var ownerBadgeProgrammaticJson = ScryptoSborUtils.DataToProgrammaticJson(ownerBadgeBytes, _networkId); + var ownerBadgeProgrammaticJson = ScryptoSborUtils.DataToProgrammaticJson(ownerBadgeBytes, networkConfiguration.Id); var roleAssignmentOwnerProofLocalId = new CoreModel.NonFungibleLocalId( simpleRep: ToolkitModel.RadixEngineToolkitUniffiMethods.NonFungibleLocalIdAsStr(new ToolkitModel.NonFungibleLocalId.Bytes(decoded.AddressBytes)), idType: CoreModel.NonFungibleIdType.Bytes, sborHex: ToolkitModel.RadixEngineToolkitUniffiMethods.NonFungibleLocalIdSborEncode(new ToolkitModel.NonFungibleLocalId.Bytes(decoded.AddressBytes)).ToArray().ToHex()); - var roleAssignmentOwnerProofGlobalId = IsSecp256k1(decoded) - ? new CoreModel.NonFungibleGlobalId(_secp256k1SignatureVirtualBadge, roleAssignmentOwnerProofLocalId) - : new CoreModel.NonFungibleGlobalId(_ed25519SignatureVirtualBadge, roleAssignmentOwnerProofLocalId); + var roleAssignmentOwnerProofGlobalId = await IsSecp256k1(decoded) + ? new CoreModel.NonFungibleGlobalId(networkConfiguration.WellKnownAddresses.Secp256k1SignatureVirtualBadge, roleAssignmentOwnerProofLocalId) + : new CoreModel.NonFungibleGlobalId(networkConfiguration.WellKnownAddresses.Ed25519SignatureVirtualBadge, roleAssignmentOwnerProofLocalId); var ownerRule = new CoreModel.ProtectedAccessRule(new CoreModel.ProofAccessRuleNode(new CoreModel.RequireProofRule(new CoreModel.NonFungibleRequirement(roleAssignmentOwnerProofGlobalId)))); var roleAssignmentOwner = new CoreModel.OwnerRole(rule: ownerRule, updater: CoreModel.OwnerRoleUpdater.Object); @@ -168,35 +176,35 @@ public bool IsVirtualIdentityAddress(EntityAddress address) new List { new("_self_", GatewayModel.ObjectModuleId.Main) }), }; - var effectiveRoleAssignmentEntries = securifyRule.Concat(_virtualEntityRoleAssignmentEntries).ToList(); - - var details = IsAccount(decoded) + var details = await IsAccount(decoded) ? new GatewayModel.StateEntityDetailsResponseComponentDetails( - packageAddress: _accountPackage, + packageAddress: networkConfiguration.WellKnownAddresses.AccountPackage, blueprintName: "Account", blueprintVersion: "1.0.0", state: new CoreModel.AccountFieldStateValue(CoreModel.DefaultDepositRule.Accept), - roleAssignments: new GatewayModel.ComponentEntityRoleAssignments(roleAssignmentOwner, effectiveRoleAssignmentEntries), + roleAssignments: new GatewayModel.ComponentEntityRoleAssignments(roleAssignmentOwner, securifyRule.Concat(_virtualAccountRoleAssignmentEntries).ToList()), royaltyVaultBalance: null) : new GatewayModel.StateEntityDetailsResponseComponentDetails( - packageAddress: _identityPackage, + packageAddress: networkConfiguration.WellKnownAddresses.IdentityPackage, blueprintName: "Identity", blueprintVersion: "1.0.0", state: null, - roleAssignments: new GatewayModel.ComponentEntityRoleAssignments(roleAssignmentOwner, effectiveRoleAssignmentEntries), + roleAssignments: new GatewayModel.ComponentEntityRoleAssignments(roleAssignmentOwner, securifyRule.Concat(_virtualIdentityRoleAssignmentEntries).ToList()), royaltyVaultBalance: null); var ownerKeys = new GatewayModel.EntityMetadataItemValue(ownerKeysRawHex, ownerKeysProgrammaticJson, ScryptoSborUtils.ConvertToolkitMetadataToGateway(ownedKeysItem)); var ownerBadge = new GatewayModel.EntityMetadataItemValue(ownerBadgeRawHex, ownerBadgeProgrammaticJson, ScryptoSborUtils.ConvertToolkitMetadataToGateway(ownerBadgeItem)); + var metadataItems = new List + { + new("owner_keys", ownerKeys), + new("owner_badge", ownerBadge, true), + }; + var metadata = new GatewayModel.EntityMetadataCollection( - totalCount: 2, + totalCount: metadataItems.Count, nextCursor: null, - items: new List - { - new("owner_keys", ownerKeys), - new("owner_badge", ownerBadge, true), - } + items: metadataItems ); return (details, metadata); @@ -214,30 +222,42 @@ private DecodedRadixAddress DecodeAddress(EntityAddress address, bool strict) return decodedAddress; } - private bool IsAccount(DecodedRadixAddress decoded) + private async Task IsAccount(DecodedRadixAddress decoded) + { + return decoded.DiscriminatorByte == await _secp256k1VirtualAccountDiscriminator.Task || decoded.DiscriminatorByte == await _ed25519VirtualAccountDiscriminator.Task; + } + + private async Task IsIdentity(DecodedRadixAddress decoded) { - return decoded.DiscriminatorByte == _secp256k1VirtualAccountDiscriminator || decoded.DiscriminatorByte == _ed25519VirtualAccountDiscriminator; + return decoded.DiscriminatorByte == await _secp256k1VirtualIdentityDiscriminator.Task || decoded.DiscriminatorByte == await _ed25519VirtualIdentityDiscriminator.Task; } - private bool IsIdentity(DecodedRadixAddress decoded) + private async Task IsSecp256k1(DecodedRadixAddress decoded) { - return decoded.DiscriminatorByte == _secp256k1VirtualIdentityDiscriminator || decoded.DiscriminatorByte == _ed25519VirtualIdentityDiscriminator; + return decoded.DiscriminatorByte == await _secp256k1VirtualAccountDiscriminator.Task || decoded.DiscriminatorByte == await _secp256k1VirtualIdentityDiscriminator.Task; } - private bool IsSecp256k1(DecodedRadixAddress decoded) + private async Task IsEd25519(DecodedRadixAddress decoded) { - return decoded.DiscriminatorByte == _secp256k1VirtualAccountDiscriminator || decoded.DiscriminatorByte == _secp256k1VirtualIdentityDiscriminator; + return decoded.DiscriminatorByte == await _ed25519VirtualAccountDiscriminator.Task || decoded.DiscriminatorByte == await _ed25519VirtualIdentityDiscriminator.Task; } - private bool IsEd25519(DecodedRadixAddress decoded) + private List GenerateVirtualAccountRoleAssignmentEntries(IRoleAssignmentsKeyProvider roleAssignmentsKeyProvider) { - return decoded.DiscriminatorByte == _ed25519VirtualAccountDiscriminator || decoded.DiscriminatorByte == _ed25519VirtualIdentityDiscriminator; + return roleAssignmentsKeyProvider + .MetadataModulesKeys + .Select(entry => new GatewayModel.ComponentEntityRoleAssignmentEntry( + new GatewayModel.RoleKey(entry.Key.Name, entry.Key.ModuleId.ToGatewayModel()), + new GatewayModel.ComponentEntityRoleAssignmentEntryAssignment(GatewayModel.RoleAssignmentResolution.Owner, null), + entry.Updaters.Select(x => new GatewayModel.RoleKey(x.Name, x.ModuleId.ToGatewayModel())).ToList() + )) + .ToList(); } - private List GenerateVirtualEntityRoleAssignmentEntries(IRoleAssignmentsKeyProvider roleAssignmentsKeyProvider) + private List GenerateVirtualIdentityRoleAssignmentEntries(IRoleAssignmentsKeyProvider roleAssignmentsKeyProvider) { return roleAssignmentsKeyProvider - .GetNativeModulesKeys() + .AllNativeModulesKeys .Select(entry => new GatewayModel.ComponentEntityRoleAssignmentEntry( new GatewayModel.RoleKey(entry.Key.Name, entry.Key.ModuleId.ToGatewayModel()), new GatewayModel.ComponentEntityRoleAssignmentEntryAssignment(GatewayModel.RoleAssignmentResolution.Owner, null), diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/CoreApiProvider.cs b/src/RadixDlt.NetworkGateway.PostgresIntegration/ToolkitModelExtensions.cs similarity index 75% rename from src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/CoreApiProvider.cs rename to src/RadixDlt.NetworkGateway.PostgresIntegration/ToolkitModelExtensions.cs index f111552da..0a01ded78 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/CoreApiProvider.cs +++ b/src/RadixDlt.NetworkGateway.PostgresIntegration/ToolkitModelExtensions.cs @@ -62,32 +62,27 @@ * permissions under this License. */ -using System.Net.Http; -using System.Net.Http.Headers; -using CoreApi = RadixDlt.CoreApiSdk.Api; +using RadixDlt.NetworkGateway.Abstractions.Model; +using System; +using ToolkitModel = RadixEngineToolkit; -namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; +namespace RadixDlt.NetworkGateway.PostgresIntegration; -internal class CoreApiProvider : ICoreApiProvider +internal static class ToolkitModelExtensions { - public CoreApi.TransactionApi TransactionsApi { get; } - - public CoreApi.StreamApi StreamApi { get; } - - public CoreApi.StatusApi StatusApi { get; } - - public CoreApi.MempoolApi MempoolApi { get; } - - public CoreApiProvider(INodeConfigProvider nodeConfig, HttpClient httpClient) + public static LedgerTransactionManifestClass ToModel(this ToolkitModel.ManifestClass input) { - if (!string.IsNullOrWhiteSpace(nodeConfig.CoreApiNode.CoreApiAuthorizationHeader)) + return input switch { - httpClient.DefaultRequestHeaders.Authorization = AuthenticationHeaderValue.Parse(nodeConfig.CoreApiNode.CoreApiAuthorizationHeader); - } - - TransactionsApi = new CoreApi.TransactionApi(httpClient, nodeConfig.CoreApiNode.CoreApiAddress); - StreamApi = new CoreApi.StreamApi(httpClient, nodeConfig.CoreApiNode.CoreApiAddress); - StatusApi = new CoreApi.StatusApi(httpClient, nodeConfig.CoreApiNode.CoreApiAddress); - MempoolApi = new CoreApi.MempoolApi(httpClient, nodeConfig.CoreApiNode.CoreApiAddress); + ToolkitModel.ManifestClass.General => LedgerTransactionManifestClass.General, + ToolkitModel.ManifestClass.Transfer => LedgerTransactionManifestClass.Transfer, + ToolkitModel.ManifestClass.PoolContribution => LedgerTransactionManifestClass.PoolContribution, + ToolkitModel.ManifestClass.PoolRedemption => LedgerTransactionManifestClass.PoolRedemption, + ToolkitModel.ManifestClass.ValidatorStake => LedgerTransactionManifestClass.ValidatorStake, + ToolkitModel.ManifestClass.ValidatorUnstake => LedgerTransactionManifestClass.ValidatorUnstake, + ToolkitModel.ManifestClass.ValidatorClaim => LedgerTransactionManifestClass.ValidatorClaim, + ToolkitModel.ManifestClass.AccountDepositSettingsUpdate => LedgerTransactionManifestClass.AccountDepositSettingsUpdate, + _ => throw new ArgumentOutOfRangeException(nameof(input), input, null), + }; } } diff --git a/src/RadixDlt.NetworkGateway.PrometheusIntegration/DataAggregatorBuilderExtensions.cs b/src/RadixDlt.NetworkGateway.PrometheusIntegration/DataAggregatorBuilderExtensions.cs index 3ea06b86d..00785145a 100644 --- a/src/RadixDlt.NetworkGateway.PrometheusIntegration/DataAggregatorBuilderExtensions.cs +++ b/src/RadixDlt.NetworkGateway.PrometheusIntegration/DataAggregatorBuilderExtensions.cs @@ -64,6 +64,7 @@ using Microsoft.Extensions.DependencyInjection; using Prometheus; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.DataAggregator; using RadixDlt.NetworkGateway.DataAggregator.Monitoring; using RadixDlt.NetworkGateway.DataAggregator.NodeServices; @@ -96,7 +97,6 @@ public static DataAggregatorBuilder AddPrometheusObserverMetrics(this DataAggreg .AddSingleton(provider => provider.GetRequiredService()) .AddSingleton(provider => provider.GetRequiredService()) .AddSingleton(provider => provider.GetRequiredService()) - .AddSingleton(provider => provider.GetRequiredService()) .AddSingleton(provider => provider.GetRequiredService()) .AddSingleton(provider => provider.GetRequiredService()) .AddSingleton(provider => provider.GetRequiredService()) diff --git a/src/RadixDlt.NetworkGateway.PrometheusIntegration/DataAggregatorMetricsObserver.cs b/src/RadixDlt.NetworkGateway.PrometheusIntegration/DataAggregatorMetricsObserver.cs index 19303142c..6c2ec402a 100644 --- a/src/RadixDlt.NetworkGateway.PrometheusIntegration/DataAggregatorMetricsObserver.cs +++ b/src/RadixDlt.NetworkGateway.PrometheusIntegration/DataAggregatorMetricsObserver.cs @@ -65,6 +65,7 @@ using Prometheus; using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.DataAggregator.Monitoring; using RadixDlt.NetworkGateway.DataAggregator.NodeServices; using RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; @@ -87,7 +88,6 @@ internal class DataAggregatorMetricsObserver : IPendingTransactionResubmissionServiceObserver, IAggregatorHealthCheckObserver, ISystemStatusServiceObserver, - INodeInitializerObserver, INodeTransactionLogWorkerObserver, INodeMempoolTransactionHashesReaderWorkerObserver, ILedgerExtenderServiceObserver, @@ -495,12 +495,6 @@ void ISystemStatusServiceObserver.SetIsPrimary(bool isPrimary) _isPrimaryStatus.SetStatus(isPrimary); } - void INodeInitializerObserver.TrackInitializerFaultedException(Type worker, string nodeName, bool isStopRequested, Exception exception) - { - var errorType = isStopRequested && exception is OperationCanceledException ? "stopped" : "faulting"; - _nodeInitializersErrorsCount.WithLabels(GetType().Name, nodeName, exception.GetNameForMetricsOrLogging(), errorType).Inc(); - } - ValueTask INodeTransactionLogWorkerObserver.DoWorkFailed(string nodeName, Exception exception) { _failedFetchLoopsUnlabeled.WithLabels(nodeName).Inc(); @@ -563,7 +557,7 @@ ValueTask ILedgerExtenderServiceObserver.StageCompleted(string stage, TimeSpan d return ValueTask.CompletedTask; } - public ValueTask GetNetworkConfigurationFailed(string nodeName, Exception exception) + ValueTask INetworkConfigurationReaderObserver.GetNetworkConfigurationFailed(string nodeName, Exception exception) { _failedNetworkConfigurationFetchCounterUnScoped.WithLabels(nodeName).Inc(); diff --git a/src/RadixDlt.NetworkGateway.PrometheusIntegration/GatewayApiBuilderExtensions.cs b/src/RadixDlt.NetworkGateway.PrometheusIntegration/GatewayApiBuilderExtensions.cs index 9cf642c2f..539e83344 100644 --- a/src/RadixDlt.NetworkGateway.PrometheusIntegration/GatewayApiBuilderExtensions.cs +++ b/src/RadixDlt.NetworkGateway.PrometheusIntegration/GatewayApiBuilderExtensions.cs @@ -89,7 +89,6 @@ public static GatewayApiBuilder AddPrometheusObserverMetrics(this GatewayApiBuil .AddSingleton(provider => provider.GetRequiredService()) .AddSingleton(provider => provider.GetRequiredService()) .AddSingleton(provider => provider.GetRequiredService()) - .AddSingleton(provider => provider.GetRequiredService()) .AddSingleton(provider => provider.GetRequiredService()); return builder; diff --git a/src/RadixDlt.NetworkGateway.PrometheusIntegration/GatewayApiMetricObserver.cs b/src/RadixDlt.NetworkGateway.PrometheusIntegration/GatewayApiMetricObserver.cs index bc3ce9d4c..76a91aa79 100644 --- a/src/RadixDlt.NetworkGateway.PrometheusIntegration/GatewayApiMetricObserver.cs +++ b/src/RadixDlt.NetworkGateway.PrometheusIntegration/GatewayApiMetricObserver.cs @@ -67,16 +67,13 @@ using Prometheus; using RadixDlt.NetworkGateway.Abstractions.CoreCommunications; using RadixDlt.NetworkGateway.Abstractions.Extensions; -using RadixDlt.NetworkGateway.GatewayApi.Configuration; using RadixDlt.NetworkGateway.GatewayApi.Exceptions; using RadixDlt.NetworkGateway.GatewayApi.Services; using System; using System.Collections.Generic; using System.Globalization; using System.Threading.Tasks; -using CoreModel = RadixDlt.CoreApiSdk.Model; using GatewayModel = RadixDlt.NetworkGateway.GatewayApiSdk.Model; -using ToolkitModel = RadixEngineToolkit; namespace RadixDlt.NetworkGateway.PrometheusIntegration; @@ -85,7 +82,6 @@ internal class GatewayApiMetricObserver : ICoreNodeHealthCheckerObserver, ISubmissionServiceObserver, ITransactionPreviewServiceObserver, - ITransactionOutcomeServiceObserver, ILedgerStateQuerierObserver, ISubmissionTrackingServiceObserver, ISqlQueryObserver @@ -157,27 +153,6 @@ internal class GatewayApiMetricObserver : new CounterConfiguration { LabelNames = new[] { "target_node" } } ); - private static readonly Counter _transactionOutcomeRequestCount = Metrics - .CreateCounter( - "ng_transaction_outcome_request_count", - "Number of transaction outcome requests", - new CounterConfiguration { LabelNames = new[] { "target_node" } } - ); - - private static readonly Counter _transactionOutcomeSuccessCount = Metrics - .CreateCounter( - "ng_transaction_outcome_success_count", - "Number of transaction outcome successes", - new CounterConfiguration { LabelNames = new[] { "target_node" } } - ); - - private static readonly Counter _transactionOutcomeErrorCount = Metrics - .CreateCounter( - "ng_transaction_outome_error_count", - "Number of transaction outcome errors", - new CounterConfiguration { LabelNames = new[] { "target_node" } } - ); - private static readonly Counter _transactionSubmitResolutionByResultCount = Metrics .CreateCounter( "ng_construction_transaction_submission_resolution_count", @@ -257,17 +232,17 @@ ValueTask ICoreNodeHealthCheckerObserver.CountByStatus(int healthyAndSyncedCount return ValueTask.CompletedTask; } - void ICoreNodeHealthCheckerObserver.NodeUnhealthy((CoreApiNode CoreApiNode, long? NodeStateVersion, Exception? Exception) healthCheckData) + void ICoreNodeHealthCheckerObserver.NodeUnhealthy((Abstractions.Configuration.CoreApiNode CoreApiNode, long? NodeStateVersion, Exception? Exception) healthCheckData) { _healthCheckStatusByNode.WithLabels(healthCheckData.CoreApiNode.Name).Set(0); } - void ICoreNodeHealthCheckerObserver.NodeHealthyButLagging((CoreApiNode CoreApiNode, long? NodeStateVersion, Exception? Exception) healthCheckData) + void ICoreNodeHealthCheckerObserver.NodeHealthyButLagging((Abstractions.Configuration.CoreApiNode CoreApiNode, long? NodeStateVersion, Exception? Exception) healthCheckData) { _healthCheckStatusByNode.WithLabels(healthCheckData.CoreApiNode.Name).Set(0.5); } - void ICoreNodeHealthCheckerObserver.NodeHealthyAndSynced((CoreApiNode CoreApiNode, long? NodeStateVersion, Exception? Exception) healthCheckData) + void ICoreNodeHealthCheckerObserver.NodeHealthyAndSynced((Abstractions.Configuration.CoreApiNode CoreApiNode, long? NodeStateVersion, Exception? Exception) healthCheckData) { _healthCheckStatusByNode.WithLabels(healthCheckData.CoreApiNode.Name).Set(1); } @@ -300,27 +275,6 @@ ValueTask ITransactionPreviewServiceObserver.HandlePreviewRequestFailed(GatewayM return ValueTask.CompletedTask; } - ValueTask ITransactionOutcomeServiceObserver.PreHandleOutcomeRequest(long stateVersion, string targetNode) - { - _transactionOutcomeRequestCount.WithLabels(targetNode).Inc(); - - return ValueTask.CompletedTask; - } - - ValueTask ITransactionOutcomeServiceObserver.PostHandleOutcomeRequest(long stateVersion, string targetNode) - { - _transactionOutcomeSuccessCount.WithLabels(targetNode).Inc(); - - return ValueTask.CompletedTask; - } - - ValueTask ITransactionOutcomeServiceObserver.HandleOutcomeRequestFailed(long stateVersion, string targetNode, Exception exception) - { - _transactionOutcomeErrorCount.WithLabels(targetNode).Inc(); - - return ValueTask.CompletedTask; - } - ValueTask ISubmissionTrackingServiceObserver.OnSubmissionTrackedInDatabase(bool isDuplicate) { if (isDuplicate) diff --git a/tests/RadixDlt.NetworkGateway.UnitTests/Abstractions/Addressing/RadixAddressTests.cs b/tests/RadixDlt.NetworkGateway.UnitTests/Abstractions/Network/RadixAddressTests.cs similarity index 98% rename from tests/RadixDlt.NetworkGateway.UnitTests/Abstractions/Addressing/RadixAddressTests.cs rename to tests/RadixDlt.NetworkGateway.UnitTests/Abstractions/Network/RadixAddressTests.cs index b83eb0fa4..dd0bd05f9 100644 --- a/tests/RadixDlt.NetworkGateway.UnitTests/Abstractions/Addressing/RadixAddressTests.cs +++ b/tests/RadixDlt.NetworkGateway.UnitTests/Abstractions/Network/RadixAddressTests.cs @@ -63,12 +63,12 @@ */ using FluentAssertions; -using RadixDlt.NetworkGateway.Abstractions.Addressing; using RadixDlt.NetworkGateway.Abstractions.Extensions; +using RadixDlt.NetworkGateway.Abstractions.Network; using System.Collections.Generic; using Xunit; -namespace RadixDlt.NetworkGateway.UnitTests.Abstractions.Addressing; +namespace RadixDlt.NetworkGateway.UnitTests.Abstractions.Network; public class RadixAddressTests { diff --git a/tests/RadixDlt.NetworkGateway.UnitTests/GatewayApi/Validators/RadixAddressValidatorTests.cs b/tests/RadixDlt.NetworkGateway.UnitTests/GatewayApi/Validators/RadixAddressValidatorTests.cs index 78067421c..c3b83596d 100644 --- a/tests/RadixDlt.NetworkGateway.UnitTests/GatewayApi/Validators/RadixAddressValidatorTests.cs +++ b/tests/RadixDlt.NetworkGateway.UnitTests/GatewayApi/Validators/RadixAddressValidatorTests.cs @@ -64,8 +64,10 @@ using FluentAssertions; using Moq; -using RadixDlt.NetworkGateway.GatewayApi.Services; +using RadixDlt.NetworkGateway.Abstractions.Network; using RadixDlt.NetworkGateway.GatewayApi.Validators; +using System.Threading; +using System.Threading.Tasks; using Xunit; namespace RadixDlt.NetworkGateway.UnitTests.GatewayApi.Validators; @@ -126,15 +128,17 @@ public class RadixAddressValidatorTests [InlineData("internal_keyvaluestore_tdx_24_1kpkxjgh28rp2e2fudwfx3ck9sau86xzt3ckc7gnl25rd6dltc023jk", "tdx_24_")] [InlineData("internal_vault_tdx_24_1nqhwlrwsq3g99n5kxnly9j58ase6ncwe0ce80dyq92f233jcemy2t8", "tdx_24_")] [InlineData("accesscontroller_tdx_24_1cd9e0x20w8e6fh5zcyv0rzzpz94n275ldxs26w868x5davl7s2w47v", "tdx_24_")] - public void WhenGiven_ValidValue_Succeeds(string address, string expectedNetworkHrpSuffix) + public async Task WhenGiven_ValidValue_Succeeds(string address, string expectedNetworkHrpSuffix) { // Prepare. - var mockNetworkConfigurationProvider = new Mock(); - mockNetworkConfigurationProvider.Setup(x => x.GetNetworkHrpSuffix()).Returns(expectedNetworkHrpSuffix); - var validator = new RadixAddressValidator(mockNetworkConfigurationProvider.Object); + var networkConfigurationProviderMock = new Mock(); + networkConfigurationProviderMock + .Setup(x => x.GetNetworkConfiguration(It.IsAny())) + .ReturnsAsync(new NetworkConfiguration(0, null!, 0, 0, null!, null!, expectedNetworkHrpSuffix, null!)); + var validator = new RadixAddressValidator(networkConfigurationProviderMock.Object); // Act. - var result = validator.Validate(address); + var result = await validator.ValidateAsync(address); // Assert. result.IsValid.Should().BeTrue(); @@ -147,15 +151,17 @@ public void WhenGiven_ValidValue_Succeeds(string address, string expectedNetwork [InlineData("resource_rdx1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxradxrd", "tdx_2_")] [InlineData("resource_tdx_24_1tknxxxxxxxxxradxrdxxxxxxxxx009923554798xxxxxxxxxd3jrej", "rdx")] [InlineData("consensusmanager_tdx_2_1scxxxxxxxxxxcnsmgrxxxxxxxxx000999665565xxxxxxxxxv6cg29", "tdx_24_")] - public void WhenGiven_InvalidValue_Fails(string address, string expectedNetworkHrpSuffix) + public async Task WhenGiven_InvalidValue_Fails(string address, string expectedNetworkHrpSuffix) { // Prepare. - var mockNetworkConfigurationProvider = new Mock(); - mockNetworkConfigurationProvider.Setup(x => x.GetNetworkHrpSuffix()).Returns(expectedNetworkHrpSuffix); - var validator = new RadixAddressValidator(mockNetworkConfigurationProvider.Object); + var networkConfigurationProviderMock = new Mock(); + networkConfigurationProviderMock + .Setup(x => x.GetNetworkConfiguration(It.IsAny())) + .ReturnsAsync(new NetworkConfiguration(0, null!, 0, 0, null!, null!, expectedNetworkHrpSuffix, null!)); + var validator = new RadixAddressValidator(networkConfigurationProviderMock.Object); // Act. - var result = validator.Validate(address); + var result = await validator.ValidateAsync(address); // Assert. result.IsValid.Should().BeFalse(); diff --git a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/NetworkConfigurationReader.cs b/tests/RadixDlt.NetworkGateway.UnitTests/PostgresIntegration/LedgerExtension/ExtensionsTests.cs similarity index 64% rename from src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/NetworkConfigurationReader.cs rename to tests/RadixDlt.NetworkGateway.UnitTests/PostgresIntegration/LedgerExtension/ExtensionsTests.cs index ea90591f8..bda96c200 100644 --- a/src/RadixDlt.NetworkGateway.DataAggregator/NodeServices/ApiReaders/NetworkConfigurationReader.cs +++ b/tests/RadixDlt.NetworkGateway.UnitTests/PostgresIntegration/LedgerExtension/ExtensionsTests.cs @@ -62,46 +62,95 @@ * permissions under this License. */ -using RadixDlt.NetworkGateway.Abstractions.Extensions; -using System; +using FluentAssertions; +using RadixDlt.NetworkGateway.PostgresIntegration.LedgerExtension; using System.Collections.Generic; -using System.Threading; -using System.Threading.Tasks; -using CoreApi = RadixDlt.CoreApiSdk.Api; -using CoreModel = RadixDlt.CoreApiSdk.Model; +using Xunit; -namespace RadixDlt.NetworkGateway.DataAggregator.NodeServices.ApiReaders; +namespace RadixDlt.NetworkGateway.UnitTests.PostgresIntegration.LedgerExtension; -internal class NetworkConfigurationReader : INetworkConfigurationReader +public class ExtensionsTests { - private readonly CoreApi.StatusApi _statusApi; - private readonly INodeConfigProvider _nodeConfigProvider; - private readonly IEnumerable _observers; - - public NetworkConfigurationReader( - ICoreApiProvider coreApiProvider, - INodeConfigProvider nodeConfigProvider, - IEnumerable observers) + [Fact] + public void GetOrAdd_Specs() { - _observers = observers; - _nodeConfigProvider = nodeConfigProvider; - _statusApi = coreApiProvider.StatusApi; + var factoryCalls = 0; + + int Factory(int key) + { + factoryCalls++; + + return 3; + } + + var dict = new Dictionary(); + var a = dict.GetOrAdd(5, Factory); + var b = dict.GetOrAdd(5, Factory); + + a.Should().Be(3); + b.Should().Be(3); + factoryCalls.Should().Be(1); + } + + private record MyTuple(byte A, int B); + + private record MyTriple(byte A, int B, long C); + + [Fact] + public void Unzip2_ShouldNotAllocateOnEmpty() + { + var lookupSet = new HashSet(); + var res = lookupSet.Unzip(x => x.A, x => x.B, out var a, out var b); + + res.Should().BeFalse(); + a.Should().BeNull(); + b.Should().BeNull(); } - public async Task<(CoreModel.NetworkConfigurationResponse Configuration, CoreModel.NetworkStatusResponse Status)> GetNetworkConfiguration(CancellationToken token) + [Fact] + public void Unzip2_Specs() { - try + var lookupSet = new HashSet { - var configuration = await _statusApi.StatusNetworkConfigurationPostAsync(token); - var status = await _statusApi.StatusNetworkStatusPostAsync(new CoreModel.NetworkStatusRequest(configuration.Network), token); + new MyTuple(1, 2), + new MyTuple(3, 2), + new MyTuple(1, 1), + }; - return (configuration, status); - } - catch (Exception ex) + var res = lookupSet.Unzip(x => x.A, x => x.B, out var a, out var b); + + res.Should().BeTrue(); + a.Should().Equal(new List { 1, 3, 1 }); + b.Should().Equal(new List { 2, 2, 1 }); + } + + [Fact] + public void Unzip3_ShouldNotAllocateOnEmpty() + { + var lookupSet = new HashSet(); + var res = lookupSet.Unzip(x => x.A, x => x.B, x => x.C, out var a, out var b, out var c); + + res.Should().BeFalse(); + a.Should().BeNull(); + b.Should().BeNull(); + c.Should().BeNull(); + } + + [Fact] + public void Unzip3_Specs() + { + var lookupSet = new HashSet { - await _observers.ForEachAsync(x => x.GetNetworkConfigurationFailed(_nodeConfigProvider.CoreApiNode.Name, ex)); + new MyTriple(1, 2, 3), + new MyTriple(3, 2, 1), + new MyTriple(1, 1, 1), + }; - throw; - } + var res = lookupSet.Unzip(x => x.A, x => x.B, x => x.C, out var a, out var b, out var c); + + res.Should().BeTrue(); + a.Should().Equal(new List { 1, 3, 1 }); + b.Should().Equal(new List { 2, 2, 1 }); + c.Should().Equal(new List { 3, 1, 1 }); } } diff --git a/tests/RadixDlt.NetworkGateway.UnitTests/RadixDlt.NetworkGateway.UnitTests.csproj b/tests/RadixDlt.NetworkGateway.UnitTests/RadixDlt.NetworkGateway.UnitTests.csproj index 4add4e5cb..76e93832f 100644 --- a/tests/RadixDlt.NetworkGateway.UnitTests/RadixDlt.NetworkGateway.UnitTests.csproj +++ b/tests/RadixDlt.NetworkGateway.UnitTests/RadixDlt.NetworkGateway.UnitTests.csproj @@ -26,4 +26,16 @@ + + + + + + + + + + + +