Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rework Workspace and Settings apis #6646

Open
wants to merge 87 commits into
base: master
Choose a base branch
from
Open

Conversation

kabentley
Copy link
Contributor

@kabentley kabentley commented Apr 18, 2024

Make the apis for loading Settings and WorkspaceResources easier to use. It makes it possible to store SettingsDictionaries in cloud workspaces and load them automatically when you open an iModel.

This includes breaking changes to the (beta) apis for:

  • Settings Schemas
  • Settings Dictionaries
  • Workspaces
  • CloudSqlite

It also introduces the Workspace.Editor namespace that can be used to modify Workspaces.

@johnnyd710 this will require work for the Settings Editor. It enforces that all Settings defined by a SettingSchema must all have the same prefix. That will undoubtedly break existing code in iTS, since settings will have a different name. You also need to add the concept of storing SettingsDictionaries in cloud containers, as we discussed.

Also, @johnnyd710, @wgoehrig, @MichaelSwigerAtBentley we should talk about how the settings editor will allow picking cloud-based WorkspaceDbs. We will probably need some kind of queries from the BlobContainer service.

*/
getObject<T extends object>(settingName: SettingName, defaultValue: T): T;
getObject<T extends object>(settingName: SettingName): T | undefined;

/** Get an array setting by SettingName.
* @param settingName The name of the setting
* @param defaultValue value returned if settingName is not present in any SettingDictionary, or if the highest priority setting is not an array.
* @param defaultValue value returned if settingName is not present in any Settings.Dictionary, or if the highest priority setting is not an array.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just noticed that these comments are now wrong. It throws if the value doesn't match.

@kabentley
Copy link
Contributor Author

I meant to reply to this comment:

Presumably it is meaningless for non-arrays (including objects, though you could make a case for a higher-priority setting overriding some properties of a lower-priority one).

VS Code does that for objects, but I strongly suggest we don't allow it. It creates a big complicated, ambiguous mess for queries. I don't see it being worthwhile or necessary.

@pmconne
Copy link
Member

pmconne commented May 23, 2024

VS Code does that for objects, but I strongly suggest we don't allow it. It creates a big complicated, ambiguous mess for queries. I don't see it being worthwhile or necessary.

Fine by me. I will rename cumulative to combineArrays.

@pmconne
Copy link
Member

pmconne commented May 23, 2024

Some questions from @Josh-Schifter below. I am starting on rewriting Workspace.md now, with an eye toward making sure it provides answers to all of these (among others).

What is the admin workflow for managing workspaces?

  • At present, an admin must create the cloud containers, create the styles (and decide versioning), and configure specific workspace versions to iModels.
  • Where should all that happen?

What is the unit of versioning for workspace information?

  • Should all ‘Drawing Production’ data be in one block, versioned together?
  • Should users (admins) be able to create and manage the blocks and decide on their contents?

What is the admin workflow for creating new versions?

  • I assume that admins will make changes over multiple sessions before publishing a new version. Is that correct?
  • How can they test their changes? Can they point their session to the unpublished version?
  • Should the UI for changing data and publishing versions be part of our mango app?

How are new versions consumed by iTwins / iModels?

  • Who will decide when to consume a new version?
  • I assume that consuming a new version will imply a changeset is created in the target iModel. Is that right?
  • Where will that UI be?
  • Specific code will be needed to apply the new version (ex. dimension style). How will we assure that code is present when applying?
  • This is related to the earlier question about which data is versioned together.

How iModels consume data from the application default workspaces?

  • They will also be versioned – by us. But what version will the iModels get?
  • Will there be a way to update the version for a particular iModel?
  • Is this handled the same or differently from user managed workspaces?

How will admins organize “Org level workspaces”?

  • Will every style in an Org workspace by available for every iModel?
  • What if they want a subset of those styles for a particular project?
  • Will they need to create multiple workspacedbs for each possible subset?
  • Wouldn’t that force them to either a) create a separate db for each style or b) duplicate some styles between dbs?

Copy link
Contributor

mergify bot commented May 27, 2024

This pull request is now in conflicts. Could you fix it @kabentley? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants