Re: mergedata, etc.: what happens with duplicate keys?

"[email protected]" <[email protected]>
Newsgroups gmane.comp.sysutils.cfengine.general
Message-ID <[email protected]>
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
On Monday, 2 August 2021 at 22:45:02 UTC+1 Bas van der Vlies wrote:

> 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
>
> > On 31 Jul 2021, at 13:43, [email protected] <
> [email protected]> wrote:
> > 
> > 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
> > 
> > 
> > -- 
> > 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 [email protected].
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/help-cfengine/a4a3e96b-4cf5-4e5d-b531-f1504cb18333n%40googlegroups.com
> .
>
>

-- 
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 [email protected].
To view this discussion on the web visit https://groups.google.com/d/msgid/help-cfengine/a93f63ad-f03f-47c1-b324-b5c970c3f3d9n%40googlegroups.com.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.