starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Do not allow duplicate tags per monitor? #415

New issue

Closed

opened 2026-02-28 01:45:46 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-28 01:45:46 -05:00

Owner

Originally created by @fdcastel on GitHub (Oct 14, 2021).

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 https://github.com/louislam/uptime-kuma/issues/686.

Originally created by @fdcastel on GitHub (Oct 14, 2021). **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: ![image](https://user-images.githubusercontent.com/629408/137261706-641daed5-25cc-4462-a9da-a17fe5b66283.png) 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 https://github.com/louislam/uptime-kuma/issues/686.

deekerman

2026-02-28 01:45:46 -05:00

closed this issue
added the
feature-request
label

deekerman commented

2026-02-28 01:45:52 -05:00

Author

Owner

@louislam commented on GitHub (Oct 14, 2021):

It is by design, more details: https://github.com/louislam/uptime-kuma/pull/278

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

@louislam commented on GitHub (Oct 14, 2021): It is by design, more details: https://github.com/louislam/uptime-kuma/pull/278 Same Tags with different values = OK Same Tags with same values = Not OK

deekerman commented

2026-02-28 01:45:52 -05:00

Author

Owner

@fdcastel commented on GitHub (Oct 14, 2021):

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.

@fdcastel commented on GitHub (Oct 14, 2021): 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.

deekerman commented

2026-02-28 01:45:52 -05:00

Author

Owner

@chakflying commented on GitHub (Oct 14, 2021):

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?

@chakflying commented on GitHub (Oct 14, 2021): 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?

deekerman commented

2026-02-28 01:45:53 -05:00

Author

Owner

@fdcastel commented on GitHub (Oct 14, 2021):

Understood. Thanks for the clarification @chakflying .

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

@fdcastel commented on GitHub (Oct 14, 2021): Understood. Thanks for the clarification @chakflying . Yes. Updating the first tag is an option. I will update the PR for this scenario.

deekerman commented

2026-02-28 01:45:53 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jul 26, 2023):

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

@CommanderStorm commented on GitHub (Jul 26, 2023): @fdcastel is this issue still relevant? If not, could you close it? (otherwise this will become an immortal zombie)

deekerman commented

2026-02-28 01:45:53 -05:00

Author

Owner

@fdcastel commented on GitHub (Jul 27, 2023):

Sure! 🧟 😄

@fdcastel commented on GitHub (Jul 27, 2023): Sure! 🧟 😄