How to add two or more FluidDataObject into a container and how to add a FluidDataObject to an exist container dynamically?

user_14996145 0
Viewed 88

I use getTinyliciousContainer get a container ,use getDefaultObjectFromContainer get a default FluidDataObject , How to add two or more FluidDataObject into a container and how to add a FluidDataObject to an exist container dynamically?

  const registryEntry: any = new Map([doFactory.registryEntry]);
  const factory = new ContainerRuntimeFactoryWithDefaultDataStore(doFactory, registryEntry);
  const container = await getTinyliciousContainer(src, factory);
  const database = await getDefaultObjectFromContainer<T>(container);
fluid fluid-framework containers
1 Answers

While we do use getDefaultObjectFromContainer to fetch containers, this is just the Default object.

You have a bunch of additional methods & requests you can call on the Container that provide different access patterns to the Container.

Most simply, the @fluidframework/aqueduct package includes getObjectFromContainer and getObjectWithIdFromContainer. These are methods available on your Container if you extend ContainerRuntimeFactoryWithDefaultDataStore. The first gets an object from the Container by its path from the root object. The second gets the Object by the UUID of the object.

However, the questions underscores a critical, under-explained concept in the Fluid system. How (also where, and why) are data objects stored in a container?

Ultimately, Data Objects are Fluid things that can bundle together Distributed Data Structures and operate on them. You can also add your own business logic, create a more complex Data Model, and handle Data Object life cycle methods.

From the Container perspective, these objects are available by "request."† When the container is created, it is constructed with a group of request handlers that provide access to the Data Objects. The methods listed above wrap around the default request handlers that are available by default on Containers created with Aqueduct.

The runtime‡ does expect some concept of a root data object to perform garbage collection and perform other tasks. Many developers only use one Data Object within their Container, but Data Objects are pretty powerful. Each Data Object can have a custom Data Model, can be individually virtualized, etc.

‡ This is really the default runtime shipped in the OSS project. Fluid's architecture is such that you could swap out the runtime fairly easily.

† This is based on the philosophy that the Container should be a distributed web server, providing access to virtualized objects within the server.

user_96997820
Related