Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
submodels [2026/09/08 20:27] hermann |
submodels [2026/09/08 20:44] (current) hermann |
||
|---|---|---|---|
| Line 181: | Line 181: | ||
| ==== Dependency Propagation When Publishing as a User Submodel ==== | ==== Dependency Propagation When Publishing as a User Submodel ==== | ||
| - | When a local submodel is published as a user submodel, its dependencies are packaged with it rather than published as independent user submodels. | + | When a local submodel is published as a user submodel, its dependencies become local submodels of the published submodel, rather than independent user submodels of their own. |
| - | Consider a local submodel **A** that depends on local submodels **B** and **C**, where **B** also depends on **C**. Publishing **A** as a user submodel produces the following structure: | + | Consider a local submodel **A** that depends on local submodels **B** and **C**, where **B** also depends on **C**. Publishing **A** as a user submodel produces a single user submodel, **A**, containing **B** and **C** as local submodels of **A**. **B** and **C** sit side by side inside **A**'s own local submodel set, so **B** does not get a separate copy of **C** — it uses the single copy of **C** held by their common parent **A**, the same way one local submodel depends on another local submodel of the same model. **B** and **C** are not added to the user's submodel set as independent, top-level entries — only **A** is. |
| - | * **A** receives its own local submodel copy of **B** and its own local submodel copy of **C**. | + | This flat structure holds regardless of whether **A** uses **C** directly. Even if **C** is used only by **B**, and not by **A** itself, publishing **A** still places **B** and **C** side by side as local submodels of **A** — **C** is not nested inside **B**. |
| - | * **B**, in turn, receives its own local submodel copy of **C** — a separate copy from the one held directly by **A**. | + | |
| - | + | ||
| - | The published user submodel therefore ends up containing two independent copies of **C**: one local to **A**, and one local to **B**. **B** and **C** are not added to the user's submodel set as independent, top-level entries — only **A** is. These packaged copies exist only because **A** depends on them, and each is private to the user submodel that contains it, the same as a local submodel copy obtained through [[#copying_importing_a_local_submodel_between_models|copying]]. | + | |
| ==== Republishing and Naming Collisions ==== | ==== Republishing and Naming Collisions ==== | ||
| Line 194: | Line 191: | ||
| Publishing or sending a submodel again — whether because the local submodel changed, or because a user submodel of the same name already exists for some other reason — behaves differently depending on the target: | Publishing or sending a submodel again — whether because the local submodel changed, or because a user submodel of the same name already exists for some other reason — behaves differently depending on the target: | ||
| - | * **User submodels are overwritten by name.** Publishing a local submodel as a user submodel always replaces whatever user submodel currently holds that name, whether that is an earlier published version of the same submodel or an unrelated existing user submodel that happens to share the name. Since dependencies are packaged as private local copies inside the published submodel rather than published as separate user submodels (see [[#dependency_propagation_when_publishing_as_a_user_submodel|Dependency Propagation When Publishing as a User Submodel]] above), republishing **A** does not touch any independently named user submodels **B** or **C** — it simply replaces **A**'s packaged copies with the current definitions of **B** and **C**. | + | * **User submodels are overwritten by name.** Publishing a local submodel as a user submodel always replaces whatever user submodel currently holds that name, whether that is an earlier published version of the same submodel or an unrelated existing user submodel that happens to share the name. Since dependencies become local submodels of the published submodel rather than independent user submodels (see [[#dependency_propagation_when_publishing_as_a_user_submodel|Dependency Propagation When Publishing as a User Submodel]] above), republishing **A** does not touch any independently named user submodels **B** or **C** — it simply replaces **A**'s local submodels **B** and **C** with their current definitions. |
| * **Store submodels are versioned, not overwritten.** Sending a submodel to the Store again does not replace the previous submission; it creates a new version, tagged with the Dinamica EGO version in use at the time, following the same versioning behavior described in [[#versioning_and_compatibility|Versioning and Compatibility]]. | * **Store submodels are versioned, not overwritten.** Sending a submodel to the Store again does not replace the previous submission; it creates a new version, tagged with the Dinamica EGO version in use at the time, following the same versioning behavior described in [[#versioning_and_compatibility|Versioning and Compatibility]]. | ||
| Line 215: | Line 212: | ||
| The store submodel package therefore ends up containing two independent copies of **C**: one local to **A**, and one local to **B**. Once packaged, these copies are independent of each other, the same as any other local submodels obtained through copying (see [[#copying_importing_a_local_submodel_between_models|Copying (Importing) a Local Submodel Between Models]]). | The store submodel package therefore ends up containing two independent copies of **C**: one local to **A**, and one local to **B**. Once packaged, these copies are independent of each other, the same as any other local submodels obtained through copying (see [[#copying_importing_a_local_submodel_between_models|Copying (Importing) a Local Submodel Between Models]]). | ||
| + | |||
| + | Unlike publishing to a user submodel, this nesting follows the actual dependency graph. If **C** is used only by **B**, and not by **A** itself, the store submodel package nests **C** inside **B** instead of placing it directly inside **A**: **C** becomes a local submodel of **B**, and **B** a local submodel of **A**. | ||
| ==== Dependencies Are Scoped to Their Store Submodel ==== | ==== Dependencies Are Scoped to Their Store Submodel ==== | ||