-
Notifications
You must be signed in to change notification settings - Fork 1
Description
Currently, sbem components do not have any enforcement of namespace consistency; i.e. you can create two in-memory objects which have the same name but don't refer to the same location in memory, have different field values, etc. This is problematic (a) if we want to implement the connector that goes from ZoneComponents -> Database (which is not super important right now) or (b) after loading components from a library, if we want them to have consistent mutation behavior. For instance, currently, if you load a Zone from the database which uses the same ConstructionAssembly for two surfaces types (e.g. facade and roof), and then the user mutates one of them, e.g. by changing the first layer in the assembly for the roof , the facade will not stay in sync since two completely separate in memory objects were created when loading from the database.
A solution would be to use a global cache which handles deduplication according to the Name/ClassName combination as a pre-instantiation hook. Whenever an object is instantiated, it gets registered in the global class if it is not yet registered, otherwise, the object can be returned from the cache, ignoring whatever values were supposedly attempting to be loaded; this can result in some (potentially) unwanted behavior too though, in some edge cases where mutations are made to an object, and then it is attempted to be reloaded again from the database which is now stale. One mechanism here would be to potentially enforce some mechanism which toggles cache deduplication on and off. It would also be useful to have a similar method which converts all members of the hierarchy into fully unique components, so that e.g. a previously shared component between two referencing fields (e.g. RoofAssembly and WallAsssembly) now becomes separate objects in memory with their own names. That would be necessary for the case where you have a component - which originally used the same in-memory object, but you now want a guarantee that when you change one specific value, it won't change any other values - so in other words when you want the opposite of the previously mentioned behavior.