https://typesense.org logo
Join Slack
Powered by
Hi team, quick question: we do have a plant databa...
# community-help
b
Hi team, quick question: we do have a plant database with common names in 135 languages, as a nested object in the object field 
vernacular
, with 2 letter iso language as key and 
string[]
as values. Is there a way to be able to both set 
locale
for every language individually to enable rtl etc, but still be able to 
query_by
vernacular, instead of having to join all languages like 
vernacular.en
etc in the search string?
I tried to 
query_by
vernacular.*
but that doesn't return any matches.
@Kishore Nallan sorry to bump - should the wildcard work this way on objects? If not, is there a way to not have to concat together 120 fields in every typeahead query_by? Much appreciated!
f
You'd have to use some sort of runtime function to run before setting up the query parameters. i.e. 
function concatParams() {
concat logic here
b
Thanks Fanis! There is no way to query_by foo.* if i define the locale of subfields of foo individually?
It feels a bit weird to have to attach 'vernacular.ace,vernacular.af,vernacular.am,vernacular.an,vernacular.ar,vernacular.as,vernacular.ast,vernacular.az,vernacular.ba,vernacular.ban,vernacular.bcl,vernacular.be,vernacular.bg,vernacular.bh,vernacular.bjn,vernacular.bm,vernacular.bn,vernacular.bo,vernacular.br,vernacular.bs,vernacular.ca,vernacular.ceb,vernacular.co,vernacular.cs,vernacular.csb,vernacular.cv,vernacular.cy,vernacular.da,vernacular.dag,vernacular.de,vernacular.diq,vernacular.dsb,vernacular.dv,vernacular.el,vernacular.en,vernacular.eo,vernacular.es,vernacular.et,vernacular.eu,vernacular.ext,vernacular.fa,vernacular.ff,vernacular.fi,vernacular.fj,vernacular.fo,vernacular.fr,vernacular.frr,vernacular.fy,vernacular.ga,vernacular.gd,vernacular.gl,vernacular.gn,vernacular.grc,vernacular.gu,vernacular.gv,vernacular.ha,vernacular.haw,vernacular.he,vernacular.hi,vernacular.hr,vernacular.hsb,vernacular.ht,vernacular.hu,vernacular.hy,vernacular.ia,vernacular.id,vernacular.ie,vernacular.ig,vernacular.ilo,vernacular.inh,vernacular.io,vernacular.is,vernacular.it,vernacular.ja,vernacular.jv,vernacular.ka,vernacular.kab,vernacular.kbd,vernacular.kg,vernacular.kk,vernacular.km,vernacular.kn,vernacular.ko,vernacular.koi,vernacular.ks,vernacular.ku,vernacular.kv,vernacular.kw,vernacular.ky,vernacular.la,vernacular.lb,vernacular.lbe,vernacular.li,vernacular.lmo,vernacular.ln,vernacular.lt,vernacular.lu,vernacular.lv,vernacular.mad,vernacular.mdf,vernacular.mg,vernacular.mhr,vernacular.mi,vernacular.min,vernacular.mk,vernacular.ml,vernacular.mn,vernacular.mnw,vernacular.mr,vernacular.mrj,vernacular.ms,vernacular.mt,vernacular.mul,vernacular.my,vernacular.myv,vernacular.myn,vernacular.mzn,vernacular.na,vernacular.nah,vernacular.nap,vernacular.nb,vernacular.ne,vernacular.nl,vernacular.nn,vernacular.no,vernacular.nv,vernacular.oc,vernacular.olo,vernacular.or,vernacular.os,vernacular.pa,vernacular.pam,vernacular.pcd,vernacular.pl,vernacular.pms,vernacular.ps,vernacular.pt,vernacular.pwn,vernacular.qu,vernacular.rn,vernacular.ro,vernacular.ru,vernacular.rw,vernacular.sa,vernacular.sah,vernacular.sat,vernacular.sc,vernacular.scn,vernacular.sco,vernacular.sd,vernacular.se,vernacular.sg,vernacular.sh,vernacular.si,vernacular.sgs,vernacular.sk,vernacular.sl,vernacular.smn,vernacular.sn,vernacular.so,vernacular.sq,vernacular.sr,vernacular.stq,vernacular.su,vernacular.sv,vernacular.sw,vernacular.szy,vernacular.szl,vernacular.ta,vernacular.tcy,vernacular.te,vernacular.tg,vernacular.th,vernacular.tl,vernacular.to,vernacular.tr,vernacular.tt,vernacular.ty,vernacular.tyv,vernacular.udm,vernacular.ug,vernacular.uk,vernacular.ur,vernacular.uz,vernacular.vec,vernacular.vep,vernacular.vi,vernacular.vls,vernacular.vo,vernacular.wa,vernacular.war,vernacular.wo,vernacular.xmf,vernacular.yi,vernacular.za,vernacular.zh,vernacular.zu' Plus the same number of 1,1,1,1... etc to every request, on every keystroke @Fanis Tharropoulos
k
The foo.* should work. We even have tests for it.
b
Saw that on github, that's why I'm surprised.
Should i file an issue there?
k
Please produce a reproducible example like this: https://gist.github.com/jasonbosco/7c3432713216c378472f13e72246f46b
b
Will try, bit complicated. Only thing that comes to mind is that it gets lost when the collection is aliased, but will investigate and ideally come up with a reproducible case.
Other weird quirk i just noticed that might be related: even when concatenating i can only search 'halfway' through the languages, until about malaysian in the example above, but I'm not getting any Chinese (zh) matches. The documents themselves are returned properly with the Chinese etc names, but when i copy & paste them into a search i don't get them as results. Just 0 results without error.
k
I think we have some soft limits on the number of fields that can be resolved. Supporting 100+ fields is not a very common use case.
b
Copy. It'd be a nice touch to give more people a sense that they can search in their language, but can consolidate 'other' languages in one field after a certain cutoff. I assume that the limit only applies to indexed fields? And is there a specific number you can share we can make sure to stay below?
k
You can consider using a single field for all european languages.
b
We'd probably do it by number of speakers. Non-indexed fields beyond the limit are fine? And if a field is not in the collection definition, it's not indexed per default?
k
Yes non indexed are fine. Only those in collection schema are indexed.
👍 1
Open in Slack
PreviousNext
Powered by