Eviepayne
(vladtheimplier)
21 Abril, 2025 01:08
1
Al buscar en mi foro con tags:tag1 si tag1 es un sinónimo de tag-one, no obtengo resultados y la publicación con tag-one no se muestra.
1 me gusta
Eviepayne
(vladtheimplier)
22 Abril, 2025 13:16
3
Creo que este probablemente no sea el comportamiento previsto, por lo que lo etiquetaré como un error.
sam
(Sam Saffron)
23 Abril, 2025 05:30
4
Entiendo, probablemente deberíamos agregar el manejo de sinónimos aquí, de acuerdo.
Poniendo un pr-welcome en esto en caso de que la comunidad quiera ayudar. La búsqueda es extremadamente autónoma, escribir pruebas para ella debería ser muy sencillo.
2 Me gusta
Moin
12 Febrero, 2026 09:32
5
Corregido
Todos estos funcionan ahora:
Buscar etiqueta:howto
Buscar etiqueta:how-to
Buscar #howto
Buscar #how-to
main ← fix/tag-synonyms-in-search
merged 07:57AM - 09 Feb 26 UTC
What is the problem?
Discourse allows admins to mark a tag as a synonym of anot… her tag. For
example, "brunch" can be made a synonym of "lunch". When this happens,
all topics tagged with "brunch" are automatically retagged with "lunch",
and the `tags.target_tag_id` column on the synonym tag record is set to
point to the target tag.
However, several code paths did not account for synonyms:
1. **Search:** `Search#search_tags` and the hashtag advanced filter did
not resolve synonyms. When a user searched using a synonym name (e.g.
`tags:brunch`, `tags:brunch+eggs`, or `#brunch`), no results were
returned because:
- The `tags:` comma path queries `topic_tags` joined with `tags` by
name, but topics are tagged with the target tag "lunch", not the
synonym "brunch".
- The `tags:` plus path aggregates tag names per topic into a
tsvector and matches against the searched name, but the aggregated
names are target tag names, so "brunch" never matches.
- The `#` hashtag path picks the synonym tag's own `id` and queries
`topic_tags` by that ID, but topics store the target tag's ID.
2. **Filter route:** `TopicsFilter#tag_ids_from_tag_names` concatenated
both the synonym's own ID and the target tag ID. For match-all
queries (e.g. `tag:brunch`), this required a topic to have both IDs
in `topic_tags`, which never happens since only the target tag ID is
stored. For negation queries (e.g. `-tag:brunch`), the exclusion
targeted the synonym ID rather than the target, so no topics were
excluded.
What is the solution?
In `Search#search_tags`, add a synonym resolution step before the
existing comma/plus branching logic. It splits the match string into
individual tag names, queries for any that are synonyms via
`Tag.where_name(tag_names).where.not(target_tag_id: nil)`, builds a
name mapping, and replaces synonym names with their target tag names.
The replacement operates on the split array elements rather than using
substring replacement to avoid corrupting tag names that may contain
other tag names as substrings.
In the hashtag advanced filter, pick both `:id` and `:target_tag_id`
from the tag lookup and prefer `target_tag_id` when present, so the
query uses the target tag's ID instead of the synonym's own ID.
In `TopicsFilter#tag_ids_from_tag_names`, replace the transpose/concat
approach with `.map { |id, target_id| target_id || id }` to resolve
each tag to its canonical ID — the target for synonyms, or the tag's
own ID otherwise.
A partial index on `tags.target_tag_id` is added (scoped to
`WHERE target_tag_id IS NOT NULL`) to support efficient synonym lookups.
2 Me gusta
nat
(Natalie T)
Cerrado
14 Febrero, 2026 00:00
6
Este tema se cerró automáticamente después de 38 horas. Ya no se permiten nuevas respuestas.