iTwin
IModelDb.saveSettingDictionary should require the schema lock.
@kabentley shouldn't `saveSettingDictionary` try to obtain the schema (file) lock?
Originally posted by @pmconne in https://github.com/iTwin/itwinjs-core/pull/6646#discussion_r1607193738
Same for deleteSettingDictionary. Conflicts will only occur if two users attempt to modify the same row (i.e., the same dictionary) in different ways. OTOH, changing the iModel's settings dictionaries should really be an admin-only task, and admins will presumably want every one else to pull in those changes as soon as they're made - acquiring the schema lock is one way to accomplish that.
@Josh-Schifter astutely questions whether permitting entire settings dictionaries to be stored in the iModel is wise or necessary. Instead, perhaps it should only permit storing pointers to settings dictionaries stored outside of the iModel in workspace dbs. This would keep workspace management in one place (the workspace management tool/app), decouple changes to settings from changes to the engineering content, and prevent contention for the schema lock when adjusting settings. Those pointers could be established once, when the iModel is created ("here is where to find the settings specific to this iModel", "settings specific for this iModel's iTwin", "settings specific to this branch").
Those pointers could be established once, when the iModel is created ("here is where to find the settings specific to this iModel", "settings specific for this iModel's iTwin", "settings specific to this branch").
From a discussion with @williamkbentley and @YashodipD: Or, maybe even take it a step further... why store such pointers at all? Potentially we could establish a rule for how to find "settings specific to this iModel", "settings specific to this iTwin", etc. If we ever need to refer to additional resources, those pointers would be stored in the appropriate settings dictionary and not directly in the iModel.
The idea is motivated by wanting to remove ambiguity by establishing firm rules like "There is one and only one special settings dictionary for an iModel (or iTwin, etc.) and there is a well known method for finding it". We can think of that special dictionary as a 'Table of Contents' or something like that.
Yeah, we have settings per iModel, iTwin, organization, branch, and application. We need to store each of those associations somewhere. Ideally using a single mechanism, which would rule out the iModel's property table.
I'm not sure if that would warrant a whole separate service, but it doesn't really seem to fit into any existing service.
Yes, but iModels are versioned
So are WorkspaceDbs. I've submitted some proposed refinements in #7316.