@fluidframework/container-runtime 2.0.0-dev-rc.1.0.0.232845 → 2.0.0-dev-rc.2.0.0.246488

package/.eslintrc.cjs

@@ -4,15 +4,15 @@
  */
 
 module.exports = {
-	extends: [require.resolve("@fluidframework/eslint-config-fluid/minimal"), "prettier"],
+	extends: [
+		require.resolve("@fluidframework/eslint-config-fluid/minimal-deprecated"),
+		"prettier",
+	],
 	parserOptions: {
 		project: ["./tsconfig.json", "./src/test/tsconfig.json"],
 	},
 	rules: {
 		"@typescript-eslint/strict-boolean-expressions": "off",
-
-		// This library is used in the browser, so we don't want dependencies on most node libraries.
-		"import/no-nodejs-modules": ["error", { allow: ["events"] }],
 	},
 	overrides: [
 		{
@@ -20,7 +20,7 @@ module.exports = {
 			files: ["*.spec.ts", "src/test/**"],
 			rules: {
 				// Test files are run in node only so additional node libraries can be used.
-				"import/no-nodejs-modules": ["error", { allow: ["assert", "crypto", "events"] }],
+				"import/no-nodejs-modules": ["error", { allow: ["assert", "crypto"] }],
 			},
 		},
 	],

package/{.mocharc.js → .mocharc.cjs}

@@ -5,7 +5,7 @@
 
 "use strict";
 
-const getFluidTestMochaConfig = require("@fluidframework/mocha-test-setup/mocharc-common");
+const getFluidTestMochaConfig = require("@fluid-internal/mocha-test-setup/mocharc-common");
 
 const packageDir = __dirname;
 const config = getFluidTestMochaConfig(packageDir);

package/CHANGELOG.md

@@ -1,5 +1,59 @@
 # @fluidframework/container-runtime
 
+## 2.0.0-rc.2.0.0
+
+### Minor Changes
+
+-   container-runtime: New feature: ID compression for DataStores & DDSs ([#19859](https://github.com/microsoft/FluidFramework/issues/19859)) [51f0d3db73](https://github.com/microsoft/FluidFramework/commits/51f0d3db737800e1c30ea5e3952d38ff30ffc7da)
+
+    ### Key changes
+
+    1. A new API IContainerRuntimeBase.generateDocumentUniqueId() is exposed. This API will opportunistically generate IDs in short format (non-negative numbers). If it can't achieve that, it will return UUID strings. UUIDs generated will have low entropy in groups and will compress well. It can be leveraged anywhere in container where container unique IDs are required. I.e. any place that uses uuid() and stores data in container is likely candidate to start leveraging this API.
+    2. Data store internal IDs (IDs that are auto generated by FF system) will opportunistically be generated in shorter form. Data stores created in detached container will always have short IDs, data stores created in attached container will opportunistically be short (by using newly added IContainerRuntimeBase.generateDocumentUniqueId() capability)
+    3. Similar DDS names will be opportunistically short (same considerations for detached DDS vs. attached DDS)
+
+    ### Implementation details
+
+    1. Container level ID Compressor can now be enabled with delay. With such setting, only new IContainerRuntimeBase.generateDocumentUniqueId() is exposed (ID Compressor is not exposed in such case, as leveraging any of its other capabilities requires future container sessions to load ID Compressor on container load, for correctness reasons). Once Container establishes connection and any changes are made in container, newly added API will start generating more compact IDs (in most cases).
+
+    ### Breaking changes
+
+    1. DDS names can no longer start with "\_" symbol - this is reserved for FF needs. I've validated that's not an issue for AzureClient (it only creates root object by name, everything else is referred by handle). Our main internal partners almost never use named DDSs (I can find only 4 instances in Loop).
+
+    ### Backward compatibility considerations
+
+    1. Data store internal IDs could collide with earlier used names data stores. Earlier versions of FF framework (before DataStore aliasing feature was added) allowed customers to supply IDs for data stores. And thus, files created with earlier versions of framework could have data store IDs that will be similar to names FF will use for newly created data stores ("A", ... "Z", "a"..."z", "AA", etc.). While such collision is possible, it's very unlikely (almost impossible) if user-provided names were at least 4-5 characters long.
+    2. If application runs to these problems, or wants to reduce risks, consider disabling ID compressor via IContainerRuntimeOptions.enableRuntimeIdCompressor = "off".
+
+    ### Minor changes
+
+    1. IContainerRuntime.createDetachedRootDataStore() is removed. Please use IContainerRuntime.createDetachedDataStore and IDataStore.trySetAlias() instead
+    2. IContainerRuntimeOptions.enableRuntimeIdCompressor has been changes from boolean to tri-state.
+
+-   driver-definitions: repositoryUrl removed from IDocumentStorageService ([#19522](https://github.com/microsoft/FluidFramework/issues/19522)) [90eb3c9d33](https://github.com/microsoft/FluidFramework/commits/90eb3c9d33d80e24caa1393a50f414c5602f6aa3)
+
+    The `repositoryUrl` member of `IDocumentStorageService` was unused and always equal to the empty string. It has been removed.
+
+-   Deprecated error-related enums have been removed ([#19067](https://github.com/microsoft/FluidFramework/issues/19067)) [59793302e5](https://github.com/microsoft/FluidFramework/commits/59793302e56784cfb6ace0e6469345f3565b3312)
+
+    Error-related enums `ContainerErrorType`, `DriverErrorType`, `OdspErrorType` and `RouterliciousErrorType` were previously
+    deprecated and are now removed. There are replacement object-based enumerations of `ContainerErrorTypes`,
+    `DriverErrorTypes`, `OdspErrorTypes` and `RouterliciousErrorTypes`. Refer to the release notes of [Fluid Framework version
+    2.0.0-internal.7.0.0](https://github.com/microsoft/FluidFramework/releases/tag/client_v2.0.0-internal.7.0.0) for details
+    on the replacements.
+
+-   container-definitions: ILoaderOptions no longer accepts arbitrary key/value pairs ([#19306](https://github.com/microsoft/FluidFramework/issues/19306)) [741926e225](https://github.com/microsoft/FluidFramework/commits/741926e2253a161504ecc6a6451d8f15d7ac4ed6)
+
+    ILoaderOptions has been narrowed to the specific set of supported loader options, and may no longer be used to pass arbitrary key/value pairs through to the runtime.
+
+-   container-definitions: Added containerMetadata prop on IContainer interface ([#19142](https://github.com/microsoft/FluidFramework/issues/19142)) [d0d77f3516](https://github.com/microsoft/FluidFramework/commits/d0d77f3516d67f3c9faedb47b20dbd4e309c3bc2)
+
+    Added `containerMetadata` prop on IContainer interface.
+
+-   runtime-definitions: Moved ISignalEnvelope interface to core-interfaces ([#19142](https://github.com/microsoft/FluidFramework/issues/19142)) [d0d77f3516](https://github.com/microsoft/FluidFramework/commits/d0d77f3516d67f3c9faedb47b20dbd4e309c3bc2)
+
+    The `ISignalEnvelope` interface has been moved to the @fluidframework/core-interfaces package.
+
 ## 2.0.0-rc.1.0.0
 
 ### Minor Changes

package/README.md

@@ -1,5 +1,50 @@
 # @fluidframework/container-runtime
 
+## Data Virtualization For DataStores (Work in Progress)
+
+It's a capability to exclude some content from initial snapshot (used when loading container) and thus improve boot
+performance of a container. Excluded content could be loaded at a later time when it's required.
+
+### Motivation for Data Virtualization
+
+This section talks about how the system used to work before Data virtualization. Currently, the content of whole file
+is downloaded in one go. Due to limitation of data virtualization, FF holds all blobs in snapshot as those might be
+required in the future. Any delayed loading (through FF APIs) results in loading state of datastores at a sequence
+number of snapshot we booted from, up until the current sequence number by applying the pending ops for that datastore.
+While application may choose not to load some data stores immediately on boot (and realize some saving in time and
+memory by not allocating appropriate app state for such datastores), FF still pays the costs for such content. It also
+continues to pay the cost for all such content indefinitely, even if those datastores were loaded.
+
+### Improvement with Data Virtualization
+
+With this, we will provide a capability to:
+
+-   Exclude some sub-trees from snapshot payload, thus allowing faster transfer times / boot times and smaller initial
+    memory footprint.
+-   Ability to delay-load data stores later.
+
+Container Runtime Apis like IContainerRuntimeBase.createDataStore and IContainerRuntimeBase.createDetachedDataStore
+provides an argument `loadingGroupId` which allows apps to mark a datastore at time of creation currently. Every data
+store is assigned a groupID. Not providing groupID (on API) means that default ID is used. This groupId represents the
+group of the datastore within a container or its snapshot. When a container is loaded initially, only datastores which
+belongs to default group are fetched from service and can be loaded on demand when requested by user. This decreases
+the amount of data which needs to be fetched during load and hence provides faster boot times for the container.
+Attempting to load any datastore within a non-default group results in fetching all content/datastores marked with same
+groupId. So, one network will be required to fetch content for a group when a datastore from a group is requested by an
+application.
+In advanced app scenarios, app would want to make datastores with a specific group Id, based on how it wants to load a
+certain group at once, and not load the datastores that aren't part of the group. By effectively using groupID, app
+will be able to improve boot times by not fetching unnecessary groups at load.
+So to summarize, when datastore is assigned to a group, content of such data store will not be loaded with initial load
+of container. It will be loaded only when any datastore with such groupID is realized.
+This will improve the boot perf. Data virtualization or providing the `loadingGroupId` will however decrease the
+performance of loading of those datastores as one network call would be required before loading. However,
+providing same `loadingGroupId` to put some data stores in same group, would improve performance for their loading as
+compared to providing a different group Id to each of these datastores as then one network call will be required to
+fetch snapshot for that group of datastores rather than one network call for each datastore. So, the datastores which
+can get fairly big in size content wise and which are not required to be loaded on boot, can be put under a non-default
+groupId.
+
 <!-- AUTO-GENERATED-CONTENT:START (LIBRARY_PACKAGE_README:scripts=FALSE) -->
 
 <!-- prettier-ignore-start -->

package/{api-extractor-esm.json → api-extractor-cjs.json}

@@ -1,4 +1,8 @@
 {
 	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
-	"extends": "../../../common/build/build-common/api-extractor-base-esm.json"
+	"extends": "../../../common/build/build-common/api-extractor-base.cjs.primary.json",
+	// CJS is actually secondary; so, no report.
+	"apiReport": {
+		"enabled": false
+	}
 }

package/api-extractor-lint.json

@@ -1,4 +1,4 @@
 {
 	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
-	"extends": "../../../common/build/build-common/api-extractor-lint.json"
+	"extends": "../../../common/build/build-common/api-extractor-lint.esm.primary.json"
 }

package/api-extractor.json

@@ -1,4 +1,4 @@
 {
 	"$schema": "https://developer.microsoft.com/json-schemas/api-extractor/v7/api-extractor.schema.json",
-	"extends": "../../../common/build/build-common/api-extractor-base.json"
+	"extends": "../../../common/build/build-common/api-extractor-base.esm.primary.json"
 }