mirror of
https://github.com/SigNoz/signoz.git
synced 2026-08-10 23:10:47 +01:00
b9f4fcd681
Some checks failed
build-staging / js-build (push) Has been cancelled
build-staging / go-build (push) Has been cancelled
build-staging / prepare (push) Has been cancelled
build-staging / staging (push) Has been cancelled
cacheci / tests (push) Has been cancelled
Release Drafter / update_release_draft (push) Has been cancelled
Possible options 1. The compatibility keys maps (the approach already in the code). `backward_compat_keys.go` makes an alias key at metadata time. We rejected this option because of evidence. The alias key resolves, but it reads the wrong data. It prepares to `attributes_string['<alias>']`, and that physical key does not hold the data. 2. The flat multi-key. `GetKeys` returns multiple keys in order, and the downstream code uses the list. The option fails on semantics. It removes one piece of information that the downstream must have. The downstream must know the difference between two cases: - Two keys are the same field with two spellings so we can merge them into one expression. - Two keys are different fields with the same name. The condition builder must make one condition for each key. The operator connects the conditions. Three failures show the problem: - Negative operators connect with OR across the keys. A row that has only one spelling then always matches. Example: `env != 'prod'` matches each row that does not have one of the two keys. - A row that has both spellings with different values gets no clear result. - A value position (group-by, select) needs exactly one expression for one field. A flat list cannot point to that expression. The information must live somewhere. 3. Annotations on `TelemetryFieldKey` Maintain the `SemconvMembers` and `SemconvMaterializedColumns` fields on the keys. The information is the same as in option 4. But it's awkward because "these N keys are one family, in this order" lives in N copies, one copy on each key. 4. introduce `LogicalField` The information is the same as in option 3, but the structure holds it: - The slice is the ambiguity. - The group is the family. - The member order is the precedence. The code sorts the members one time, by family rank, at construction. - The members point to the metadata entries. The code copies nothing and changes nothing. - The identity (signal, context, data type) is on the group. A merge across contexts or data types is not possible. The design does not avoid that merge; the design cannot express it. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>