Supporting multiple container schemas #21217
-
|
How can I check whether my client uses the correct schema when connecting to a container? If I have a new version of my fluid program, but still want to connect to some old containers with the previous schema, how do I know which schema the container uses? It seems that there is no error if you mix container schemas when creating and connecting to a container, even if the documentation says that they should be the same. Should I then check the initialObjects of the container against possible schemas to figure out which schema the container has? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
@SampoSyrjanen, just to confirm, you are referring to the container schema, correct? Not the schema of a SharedTree DDS? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, the container schema. |
Beta Was this translation helpful? Give feedback.
-
|
I'd recommend explicitly putting a version field at a well-known location within your container which remains consistent across different types of container schemas. You could do this within SharedTree, SharedDirectory, SharedMap, etc. On container creation, populate this field before attaching the container. On container load, you can determine which schema your container is using based on this field. You can adopt this strategy in an ecosystem which hasn't used it already by interpreting absence of the version number as version 0 (or a number of unversioned schemas which you can distinguish between using other means). Because of collaborative scenarios, this approach doesn't easily let you migrate documents in old container formats to newer ones, but this is an area that we're looking into improving the experience around. |
Beta Was this translation helpful? Give feedback.
I'd recommend explicitly putting a version field at a well-known location within your container which remains consistent across different types of container schemas. You could do this within SharedTree, SharedDirectory, SharedMap, etc.
On container creation, populate this field before attaching the container. On container load, you can determine which schema your container is using based on this field.
You can adopt this strategy in an ecosystem which hasn't used it already by interpreting absence of the version number as version 0 (or a number of unversioned schemas which you can distinguish between using other means).
Because of collaborative scenarios, this approach doesn't easily let …