Open perolavsvendsen opened 9 months ago
Perhaps better (although a bit painful, potentially?) to just keep data.name
as it was given (name
argument) and rather add reference to the stratigraphic column, e.g.
Could potentially move reference to stratigraphic column from masterdata
to this reference as well, and only include it when we are actually exporting stratigraphic horizons (?)
data:
name: Whatever2Top
stratigraphic:
column: MyStratigraphicColumn
name: Whatever Fm. 2 Top
Note that particularly changing the data.name
will require discussion, and will potentially be breaking change.
If we want to avoid changing data.name
we could consider being more specific on identifiers, so that consumers who care can be explicit, e.g.:
data:
name: Whatever Fm. 2. Top
identifiers:
name_stratigraphic_column: Whatever Fm. 2. Top
name_source: Whatever2Top
(data.identifiers
can be expanded if need be)
This requires (even more) thinking and discussions.
Discussions 2023-12-20: @daniel-sol @jcrivenaes @HansKallekleiv @tnatt
data.name
is used as a identifier both inside and outside FMUdata.name
is translated from "FMU name" to master data-derived name (strat col) on exportdata.alias
.Since the name is used as a identifier, the change can cause problems. Example:
A zone is called "MyZone". When exporting the isochore, it is renamed to "My Zone Fm. Top" to adhere to master data. A third object refers to "MyZone", which now no longer exists.
A current possible solution is to use the
alias
as a fallback. However, unclear how well this works with Elasticsearch since it is a list.A perhaps better solution is to include the "FMU name" explicitly:
We do not want to change
data.name
due to the amount of contracts and dependencies related to this.