Do not allow duplicate tags per monitor?

[fdcastel]

Is it a duplicate question?
No.

Is your feature request related to a problem? Please describe.
Maybe.

Describe the solution you'd like
I was a bit surprised when I saw this:

What is the value of t1 on monitor1?

I believe monitor_tag table should have a composite primary key (or an UNIQUE key/index) of (monitor_id, tag_id) blocking this occurrence in the db model.

Describe alternatives you've considered
None.

Additional context
If this is indeed the intended design, please disregard. However, I found the semantics of having one tag with multiple values somewhat strange (or that one tag could be "present" multiple times).

I discovered this while working on a PR for #686.

[louislam]

It is by design, more details: #278

Same Tags with different values = OK
Same Tags with same values = Not OK

[fdcastel]

Ok. 😟 However, I didn't find any rationale for this behavior in #278.

There's a sample scenario? I really can't find any reason for this. It only keeps the code more complex, IMHO.

PR #705 would also be wrong in this case. Given that we cannot uniquely identify a tag just by name, an update of t1=50 will left two t1 tags with value = 50, bringing the monitor to "Not OK" scenario above.

[chakflying]

in previous suggestions to implement this feature, tags are mostly used for filtering and grouping. So something like having both DNS and DNS: TXT make sense. Your use case did not even cross my mind when I made this, but I totally see that this will be useful as well.

If you think your use case won't be dealing with duplicate tags, I guess we can just update the first tag we find with that name?

[fdcastel]

Understood. Thanks for the clarification @chakflying .

Yes. Updating the first tag is an option. I will update the PR for this scenario.

[CommanderStorm]

@fdcastel is this issue still relevant?
If not, could you close it? (otherwise this will become an immortal zombie)

[fdcastel]

Sure! 🧟 😄