mergedata, etc.: what happens with duplicate keys?

[t.d...@servicemusic.org.uk]

All the documentation and examples about "mergedata" (and bundle "cmerge", etc.) seem to be based on non-overlapping data sets.  For example, with two simple key:value JSON datasets, the examples and documentation have no overlap of keys.

But what is supposed to happen when the same key, and with potentially different value, appears in both JSON datasets?

My proposed use-case is two simple JSON key:value datasets. The first can be regarded as a full and complete set of default key:value pairs; the second is smaller and contains override values for a subset of those same keys.  The desired result would be that full set as modified by the overrides.

There seems to be no documentation describing how this is handled, not even whether it is regarded as an error condition.  If it is documented somewhere, it seems well hidden.

If I should be using something else rather than "mergedata", let me know.

Any thoughts?  Primarily about my proposed use-case, but also about improving the documentation (e.g. at function "mergedata") to describe this case of same-key merging.

Assume CFE 3.12, but if CFE 3.15 would be different, that would be possible.  (By the way my reading of documentation also included some 3.18.)

-- David Lee

[Bas van der Vlies]

David,

the cf_surfsara_lib also depends a lot of mergdate. The last one wins, see for a small example:
* https://github.com/basvandervlies/cf_surfsara_lib#mustachejson-rules

regards

> --
> You received this message because you are subscribed to the Google Groups "help-cfengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to help-cfengin...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/a4a3e96b-4cf5-4e5d-b531-f1504cb18333n%40googlegroups.com.

[t.d...@servicemusic.org.uk]

Thanks, Bas.  I'll take a look.

It seems that this behaviour ("last one wins") ought to be documented, so that we, the users, know what to expect, and that it is intentionally designed to behave this way.

Documenting it would also means that the behaviour should be preserved into the future.

Without such CFE documentation, it would be possible for a future implementation simply to change the behaviour. and for such a change to be called a "feature".  By adding documentation into CFE, it would means that any such change would be reasonably classified as a "bug" (or that such change would have earlier been planned, announced, managed, etc.).

I'd really like to see CFE themselves document and confirm this "last one wins" behaviour.

-- David Lee

[Vratislav Podzimek]

On Thu, 2021-08-05 at 03:19 -0700, t.d...@servicemusic.org.uk wrote:
> Thanks, Bas.  I'll take a look.
>
> It seems that this behaviour ("last one wins") ought to be documented, so that we, the users, know
> what to expect, and that it is intentionally designed to behave this way.
>
> Documenting it would also means that the behaviour should be preserved into the future.
>
> Without such CFE documentation, it would be possible for a future implementation simply to change
> the behaviour. and for such a change to be called a "feature".  By adding documentation into CFE, it
> would means that any such change would be reasonably classified as a "bug" (or that such change
> would have earlier been planned, announced, managed, etc.).
>
> I'd really like to see CFE themselves document and confirm this "last one wins" behaviour.

Could you please create a ticket at https://tracker.mender.io/secure/CreateIssue.jspa ?

Thanks!

--
Vratislav

> https://groups.google.com/d/msgid/help-cfengine/a93f63ad-f03f-47c1-b324-b5c970c3f3d9n%40googlegroups.com
> .

[Nick Anderson]

https://tracker.mender.io/browse/CFE-3733

[Nick Anderson]

Documentation updated: https://docs.cfengine.com/docs/3.18/reference-functions-mergedata.html