You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the WoT ThingModel is only taken into account when creating new Things in Ditto. In this case, a JSON skeleton of the Thing based on the WoT TM is created.
Over time, a WoT ThingModel might however evolve, e.g. new properties, new actions or new submodels, etc. are added.
Those evolvements can be categorised in:
non-breaking evolvements (according to Semantic Versioning changes to the MINOR version):
only additions to existing functionality without removing existing properties/actions/events
breaking evolvements (according to Semantic Versioning changes to the MAJOR version)
also containing breaking functionality with renaming/removing existing properties/actions/events
out of scope for this issue - as this would require e.g. also deleting stuff from things or renaming
In my experience, non-breaking evolvements can happen very regularly, as the (exposed) functionality of IoT devices evolves quickly over time.
For such non-breaking evolvements, Ditto shall provide means to "migrate" existing things to a newer MINOR version of referenced WoT ThingModels.
Concretely, the following steps would have be done when updating the minor version of a WoT ThingModel in a Ditto thing's definition:
definition of a Thing is modified (either via ModifyDefinition or via MergeThing for the "definition")
Ditto checks if the "minor" version increased - and only if it did - performs a "migration":
resolving all "submodel" versions of the new "minor" thing model
update all feature definition fields with the updated "submodel" models
potentially adding previously non-yet-existing features in the process
for existing features / "submodels" which received a minor update, for each pair of <old model version>,<new model version>:
generate JSON skeleton for <old model version>
generate JSON skeleton for <new model version>
calculate the "diff" as Json Merge Patch from new to old JSON skeleton
for all "new added" (non-optional) properties:
create the property with the defined default value
but only if the Thing does not yet contain a "real" value for the property yet (which could already be sent by the real device - we don't want to overwrite "real" values with default values)
The algorithm might still not be "complete" - but in a nutshell, we have to handle:
updating Thing attributes with default values for new TM "properties"
updating Feature properties with default values for new TM "properties"
updating Feature definitions
updating the Thing's definition if all was successful
TODO: what to do in case of an error?
and that - all based on a simple update request of a Thing definition
The text was updated successfully, but these errors were encountered:
Currently, the WoT ThingModel is only taken into account when creating new Things in Ditto. In this case, a JSON skeleton of the Thing based on the WoT TM is created.
Over time, a WoT ThingModel might however evolve, e.g. new
properties
, newactions
or newsubmodels
, etc. are added.Those evolvements can be categorised in:
In my experience, non-breaking evolvements can happen very regularly, as the (exposed) functionality of IoT devices evolves quickly over time.
For such non-breaking evolvements, Ditto shall provide means to "migrate" existing things to a newer MINOR version of referenced WoT ThingModels.
Concretely, the following steps would have be done when updating the minor version of a WoT ThingModel in a Ditto thing's
definition
:definition
of a Thing is modified (either viaModifyDefinition
or viaMergeThing
for the"definition"
)definition
fields with the updated "submodel" models<old model version>,<new model version>
:<old model version>
<new model version>
default
valueThe algorithm might still not be "complete" - but in a nutshell, we have to handle:
attributes
with default values for new TM "properties"properties
with default values for new TM "properties"definition
sdefinition
if all was successfuldefinition
The text was updated successfully, but these errors were encountered: