[Hotfix] Removed nfid store aggregate. (#774)

* Removed nfid store aggregate.

CHANGELOG.md

@@ -1,3 +1,10 @@
+## 1.6.2
+Release built: 05.08.2024
+
+### Database changes
+- Removed the large `non_fungible_id_store_history` aggregate table. Queries for non fungible ids follow a similar strategy as key value stores and utilize `_definition` and `_history` tables to return data. Total supply and total minted/burned can be queried from the `resource_entity_supply_history` table.
+- Renamed `non_fungible_id_data` table to `non_fungible_id_definition`.
+
 ## 1.6.1
 Release built: 21.05.2024
 
@@ -21,7 +28,7 @@ Release built: 09.05.2024
 
 > [!CAUTION]
 > **Breaking Changes:**
-> - Changed ordering of the collection returned by the `/state/key-value-store/keys` endpoint. Entries are no longer orderer by their last modification state version but rather by their first appearance on the network, descending.
+> - Changed ordering of the collection returned by the `/state/key-value-store/keys` endpoint. Entries are no longer ordered by their last modification state version but rather by their first appearance on the network, descending.
 > - Property `total_count` of the `/state/key-value-store/keys` endpoint is no longer provided.
 > - Renamed `state.recovery_role_recovery_attempt` property from `timed_recovery_allowed_after` to `allow_timed_recovery_after` returned from `/state/entity/details` when querying for access controller.
 

Directory.Build.props

@@ -14,7 +14,7 @@
   </PropertyGroup>
 
   <PropertyGroup>
-    <VersionPrefix>1.6.1</VersionPrefix>
+    <VersionPrefix>1.6.2</VersionPrefix>
     <VersionSuffix>develop</VersionSuffix>
   </PropertyGroup>
 

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.6.1"
+    image: "radixdlt/babylon-ng-database-migrations:v1.6.2"
     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.6.1"
+    image: "radixdlt/babylon-ng-data-aggregator:v1.6.2"
     profiles: ["NONE"]
     deploy:
       restart_policy:
@@ -97,7 +97,7 @@ services:
       - ./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.6.1"
+    image: "radixdlt/babylon-ng-gateway-api:v1.6.2"
     profiles: ["NONE"]
     ports:
       - "127.0.0.1:5308:8080" # This allows you to connect to the API at http://localhost:5308

src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultKeyValueStoreHandler.cs

@@ -104,7 +104,7 @@ public DefaultKeyValueStoreHandler(
         return await _keyValueStoreQuerier.KeyValueStoreKeys(
             (EntityAddress)request.KeyValueStoreAddress,
             ledgerState,
-            GatewayModel.StateKeyValueStoreKeysCursor.FromCursorString(request.Cursor),
+            GatewayModel.IdBoundaryCoursor.FromCursorString(request.Cursor),
             _endpointConfiguration.Value.ResolvePageSize(request.LimitPerPage),
             token);
     }

src/RadixDlt.NetworkGateway.GatewayApi/Handlers/DefaultNonFungibleHandler.cs

@@ -89,14 +89,12 @@ public DefaultNonFungibleHandler(ILedgerStateQuerier ledgerStateQuerier, IEntity
     {
         var ledgerState = await _ledgerStateQuerier.GetValidLedgerStateForReadRequest(request.AtLedgerState, token);
 
-        var cursor = GatewayModel.OffsetCursor.FromCursorString(request.Cursor);
-        var pageRequest = new IEntityStateQuerier.PageRequest(
-            Address: (EntityAddress)request.ResourceAddress,
-            Offset: cursor?.Offset ?? 0,
-            Limit: _endpointConfiguration.Value.ResolveNonFungibleIdsPageSize(request.LimitPerPage)
-        );
-
-        return await _entityStateQuerier.NonFungibleIds(pageRequest, ledgerState, token);
+        return await _entityStateQuerier.NonFungibleIds(
+            nonFungibleResourceAddress: (EntityAddress)request.ResourceAddress,
+            ledgerState: ledgerState,
+            cursor: GatewayModel.IdBoundaryCoursor.FromCursorString(request.Cursor),
+            pageSize: _endpointConfiguration.Value.ResolvePageSize(request.LimitPerPage),
+            token);
     }
 
     public async Task<GatewayModel.StateNonFungibleDataResponse> Data(GatewayModel.StateNonFungibleDataRequest request, CancellationToken token = default)

src/RadixDlt.NetworkGateway.GatewayApi/Services/IEntityStateQuerier.cs

@@ -127,7 +127,7 @@ public sealed record ResourceVaultsPageRequest(EntityAddress Address, EntityAddr
         GatewayModel.LedgerState ledgerState,
         CancellationToken token = default);
 
-    Task<GatewayModel.StateNonFungibleIdsResponse> NonFungibleIds(PageRequest request, GatewayModel.LedgerState ledgerState, CancellationToken token = default);
+    Task<GatewayModel.StateNonFungibleIdsResponse> NonFungibleIds(EntityAddress nonFungibleResourceAddress, GatewayModel.LedgerState ledgerState, GatewayModel.IdBoundaryCoursor? cursor, int pageSize, CancellationToken token = default);
 
     Task<GatewayModel.StateNonFungibleDataResponse> NonFungibleIdData(
         EntityAddress resourceAddress,

src/RadixDlt.NetworkGateway.GatewayApi/Services/IKeyValueStoreQuerier.cs

@@ -81,7 +81,7 @@ public interface IKeyValueStoreQuerier
     Task<GatewayModel.StateKeyValueStoreKeysResponse> KeyValueStoreKeys(
         EntityAddress keyValueStoreAddress,
         GatewayModel.LedgerState ledgerState,
-        GatewayModel.StateKeyValueStoreKeysCursor? cursor,
+        GatewayModel.IdBoundaryCoursor? cursor,
         int pageSize,
         CancellationToken token = default);
 }

src/RadixDlt.NetworkGateway.GatewayApi/gateway-api-schema.yaml

@@ -1,6 +1,6 @@
 openapi: 3.0.0
 info:
-  version: v1.6.1
+  version: v1.6.2
   title: Radix Gateway API - Babylon
   license:
     name: The Radix License, Version 1.0

src/RadixDlt.NetworkGateway.GatewayApiSdk/Model/StateKeyValueStoreKeysCursor.cs → src/RadixDlt.NetworkGateway.GatewayApiSdk/Model/IdBoundaryCoursor.cs

@@ -67,17 +67,17 @@
 namespace RadixDlt.NetworkGateway.GatewayApiSdk.Model;
 
 [DataContract]
-public sealed record StateKeyValueStoreKeysCursor(long? StateVersionBoundary, long? IdBoundary)
+public sealed record IdBoundaryCoursor(long? StateVersionBoundary, long? IdBoundary)
 {
     [DataMember(Name = "sv", EmitDefaultValue = false)]
     public long? StateVersionBoundary { get; set; } = StateVersionBoundary;
 
     [DataMember(Name = "id", EmitDefaultValue = false)]
     public long? IdBoundary { get; set; } = IdBoundary;
 
-    public static StateKeyValueStoreKeysCursor FromCursorString(string cursorString)
+    public static IdBoundaryCoursor FromCursorString(string cursorString)
     {
-        return Serializations.FromBase64JsonOrDefault<StateKeyValueStoreKeysCursor>(cursorString);
+        return Serializations.FromBase64JsonOrDefault<IdBoundaryCoursor>(cursorString);
     }
 
     public string ToCursorString()

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.6.1
+ * The version of the OpenAPI document: v1.6.2
  * Generated by: https://github.com/openapitools/openapi-generator.git
  */
 

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.6.1
+ * The version of the OpenAPI document: v1.6.2
  * Generated by: https://github.com/openapitools/openapi-generator.git
  */
 

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.6.1
+ * The version of the OpenAPI document: v1.6.2
  * Generated by: https://github.com/openapitools/openapi-generator.git
  */
 

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.6.1
+ * The version of the OpenAPI document: v1.6.2
  * Generated by: https://github.com/openapitools/openapi-generator.git
  */
 

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.6.1
+ * The version of the OpenAPI document: v1.6.2
  * Generated by: https://github.com/openapitools/openapi-generator.git
  */
 

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.6.1
+ * The version of the OpenAPI document: v1.6.2
  * Generated by: https://github.com/openapitools/openapi-generator.git
  */