https://typesense.org logo
Join Slack
Powered by
Hey guys, with pretty long fields, I receive resul...
# community-help
y
Hey guys, with pretty long fields, I receive results in hits but highlights aren’t there
j
Could you share the full search query with all the search params and the Typesense version you're using?
y
/collections/blog-posts/documents/search?x-typesense-api-key=xxx&q=combat&query_by=title,custom_excerpt,excerpt,plaintext&infix=always,always,always,always&query_by_weights=128,1,1,1&include_fields=title,custom_excerpt,excerpt,slug,plaintext,feature_image&page=1&per_page=10
I was experimenting with weights and infix stuff there but it’s the same without them too
I also noticed even if I give 128 weight to the title and 1 to others, infix hits on title are still not at the top
As opposed to normal hits on the other fields
oh highlights are actually there without the infix only
It’s also there with infix and smaller fields
j
To clarify, you're saying that for large fields highlights are not being returned for that field if infix is turned on for that field?
y
I think so yes
Without infix, large field is good, if I turn on infix, highlights don’t show up (but only for that field)
j
That sounds like a bug. Could you open a Github issue with a small dataset and curl queries to replicate the issue?
y
Not right now but I can at some point
🙏 1
j
Separately, weights can only go to a max of 127. Beyond that it causes overflow and the results will be unpredictable
y
it’s the same with 10, 1, 1, 1
infix match is still way down in the hits
Even though it has the 10 weight
Same with 100 too
j
Are there prefix matches above that though? If so prefix matches are currently considered to be more relevant...
y
There is yea, but I wouldn’t expect that to happen with me giving 100 weight
the field that has the prefix match is weighted 1, the field that has the infix match is weighted 100
Prefix still shows up higher
j
Yeah we currently don't use weights for infix vs prefix match weighting. But now that you point it out, I can see how it would be useful. Could you open a separate Github issue for this, mentioning your use-case?
y
It is indeed, the infix I have is on title, prefix match is on a huge body text field, so that title definitely matters much more
here is an example title: FutureBuilders
and imagine a 20kb body with builder text in it
When I write “builders” to the search bar, I naturally expect the one with the title showing up higher, since the weight of each word in that 20kb body means much less
Because I thought I set it up that way with the weights but thanks for clearing that up
👍 1
j
Got it, yeah makes sense to me
y
thanks for the fast response btw, I’ll create the issues for each though the fact that I need to setup a dataset and curl queries triggers laziness 😄
j
Even a few records to showcase the issue would be great! It typically helps avoid back and forth in trying to replicate the issue and verify the fix
y
I’m guessing it has been suggested before but a playground with a predefined data set we can query would go a long way. It makes it easier for users to submit issues in better way, which makes it more likely to do them 🙂
j
That's an interesting idea! The variability in collection schemas makes it hard though, given the permutations of field configurations available
y
I think a default one would cover a good chunk of issues if people are able to query it any way they want. Though same exact UI with some configurability also works. Seems pretty low priority but idk. I just starting playing with Typesense yesterday 😄
Created the issues, no reproduction yet
👍 1
Open in Slack
PreviousNext
Powered by