When creating new layers its often useful to employ the git paradigm of forking (in LMIPy this would be cloning) and existing layer and update it, as opposed creating a new one from scratch. This reduces mistakes as its often the case that the original layer works before cloning.
Right now, once a new version of a layer is created from a clone we often delete the old version and replace it. This is problematic as it causes slug and id changes which may need to be updating in the applications using the layer.
I propose that we improve this workflow by introducing a merge method into LMI, which would act as the inverse operation to .clone().
The method Layer.merge() should have the following behaviour:
layerB.merge(layerA) merges layerBintolayerA
Here, merge means to update one config with another another
Method params:
a. merge_into=<Layer.id> (required)
b. merge_and_delete=False: if True, deletes layerA after successful update of layerB
c. merge_keys specify the keys to merge in the case that we want to be selective
When creating new layers its often useful to employ the git paradigm of forking (in LMIPy this would be cloning) and existing layer and update it, as opposed creating a new one from scratch. This reduces mistakes as its often the case that the original layer works before cloning.
Right now, once a new version of a layer is created from a clone we often delete the old version and replace it. This is problematic as it causes
slugandidchanges which may need to be updating in the applications using the layer.I propose that we improve this workflow by introducing a merge method into LMI, which would act as the inverse operation to
.clone().e.g.
The method
Layer.merge()should have the following behaviour:layerB.merge(layerA)mergeslayerBintolayerAmerge_into=<Layer.id>(required) b.merge_and_delete=False: ifTrue, deleteslayerAafter successful update oflayerBc.merge_keysspecify the keys to merge in the case that we want to be selective