Workspaces: Correct way to create new WorkspaceDb in a Workspace Container?

[arbrumbaugh]

I'm trying to create a new WorkspaceDb in a Workspace Container, and then retrieve the latest version of that newly created WorkspaceDb by calling IModelHost.appWorkspace.getWorkspaceDb().

After creating the Workspace Container, the default WorkspaceDb gets created and then I create a new major version (1.0.0). I'm able to successfully get the v1.0.0 of the default WorkspaceDb thru IModelHost.appWorkspace.getWorkspaceDb().
In the same session, using the same WorkspaceEditor, I create a new WorkspaceDb in the same Workspace Container by calling EditableWorkspaceContainer.createDb(). The version of this new WorkspaceDb is 0.0.0, so I create a new major version 1.0.0 and publish the change. However, when I try to get the new WorkspaceDb by calling IModelHost.appWorkspace.getWorkspaceDb(), it returns the WorkspaceDb v0.0.0, which I assumed would return v1.0.0.

I have a created a test case to reproduce this scenario here: CloudWorkspace.test.ts.

Is my workflow incorrect for creating and retrieving the latest version of a new WorkspaceDb?

[nick4598]

Thanks for writing up a test which reproduces this. I was able to get your test to pass by adding a cloudContainer.checkForChanges() to resolveDbFileName within WorkspaceImpl.ts. It seems that there are two cloudcaches on the local machine which represent the same container. One is meant for editing the Workspace, and I believe the other is a readonly copy of the Workspace. The problem appears to be that the local readonly copy does not get updated (this is what checkForChanges does) after the Workspace is edited. Since the local readonly copy doesn't get updated, it doesn't see the new workspaceDb that you created.

I'm not sure though if we should always call checkForChanges when resolving a WorkspaceDb file name, so I will spend some more time looking at this for a better solution.

As a temporary workaround you could use cont = IModelHost.appWorkspace.findContainer(testContainer.cloudProps.containerId) and call cont.cloudContainer.checkForChanges(). Do this before you try to get v1.0.0 of the workspaceDb. I also confirmed that this approach makes your test pass.

[kabentley]

@arbrumbaugh do you really want to create a container with more than one WorkspaceDb in it? What is the use case? @pmconne and I discussed disallowing that.

[pmconne]

@kabentley I talked to @arbrumbaugh et al about that, they are fine with 1 db per container.

[nick4598]

Does that limitation need to be enforced in the code if people are able to use Workspaces in such a way to hit this issue?

[nick4598]

@kabentley What is the concern with calling checkForChanges in resolveDbFileName? Too many polls?

[arbrumbaugh]

@nick4598 thanks for taking a look into this and providing a work around for our current implementation.

@kabentley our current implementation allows admins to create multiple WorkspaceDbs in a WorkspaceContainer. This was how we designed our usage of Workspaces from awhile ago, but now as @pmconne mentioned, we will update our implementation to only allow one WorkspaceDb per WorkspaceContainer.