I’m handling a weird issue: I’m having an empty q...
# community-help
m
I’m handling a weird issue: I’m having an empty query I am sending, so expecting everything to be returned, but I only get 26 results?
Copy code
{facet_counts: [], found: 26,…}
facet_counts: []
found: 26
hits: [{,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…},…]
out_of: 30
page: 1
request_params: {collection_name: "e4l_dev_toolkit", per_page: 50, q: ""}
search_cutoff: false
search_time_ms: 0
Using typesense-js
k
To get all results send query string as * -- but you can access only upto 250 results. Or use export as Anton has suggested.
m
With
"*"
I actually get the same resutls
Copy code
{facet_counts: [], found: 26,…}
facet_counts: []
found: 26
hits: [{,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…}, {,…},…]
out_of: 30
page: 1
request_params: {collection_name: "e4l_dev_toolkit", per_page: 50, q: "*"}
search_cutoff: false
search_time_ms: 0
There are only 30 documents whatsoever, there will never be more.
It is actually unwanted behaviour tho needing to add
"*"
in the query in my honest opinion @Kishore Nallan --> when reactively bound in Vue, on typing through v-model when a user doesn’t enter anything in their searchbox, or just delete what they typed, I’d rather have on empty string everything turning up, besides adding additional logic.
k
You can configure a default query for the instant search widget I think. cc @Jason Bosco
m
^ not using widgets, definitely not using anything Algolia related 😉
k
Haha ok. The reason for using q=* is because that's what almost all other search engines use so it helps being compatible with that convention.
m
Yeah that I understand, but I think if you send something “empty” typesense should use internally as “*” I could be mistaken tho 🤷
I found the culprit @Kishore Nallan, we index a few int fields as
-100
since it was difficult to work with
null
values in there. But the initial sort should actually always show those
-100
ones, but our values usually just go from
-4
to
+8
I’ll have a think on how to resolve this.
k
In 0.23.1 there's a parameter for how null values should be sorted.
m
Can you upload
null
values into an int field in
0.23.1
?
if that is possible it might be easier.
k
Oh wait, that's only for null/missing string values.
If a field is set as optional you can send null values
m
Well … the fields are required, the value
null
is an actual valid research value 😬
But maybe I can put the requirement on a higher level
k
Yeah the field check can be done at the application layer.
m
Copy code
[
                        'name' => 'impact',
                        'type' => 'int32',
                        'facet' => true,
                        'optional' => true
                    ],
so using this, should allow the field to accept
null
then?
Let’s try. I’ll get back if I still have some issues 🙂
k
Yes
m
Seems like
optional
has different behaviour as what I thought @Kishore Nallan --> when it’s set to optional and we feed it a
null
value it’s not even showing up in the “values” anymore of the document, it’s non-existing. What I expect is that it is existing, but can simply accept
null
as value. -->
impact: null
vs
impact: 1
something like
?Int
( if we would type it in PHP e.g. )
j
m
@Jason Bosco that was not the issue, but really not using Algolia … 😉 I know that you guys can tap into the Agolia widgets, but imo, not always everything should be referred to the Algolia docs ( slight annoyance for me ) As even tho when using Algolia before those widgets have been rubbish to built a nice interface, lightweight and styled/implemented exactly how you want + full control. But the issue is something else. I am wondering is it possible to do something like
num_employees:[10..100] && num_employees:=200
for the filter_by possibilities?
j
Oh my bad, I missed the part where you said you didn't use Algolia’s UI widgets! Need to get my Monday morning coffee! re:filtering, yes that syntax should work
m
Awesome, that filter will probably solve my problem. Although where do you prefer to get feature requests? Still need to contact as we want from a 40K USD / year Algolia price to Typesense 😅
j
At 40K USD / year spend on Algolia, you’ll be eligible for our free migration support plans: https://cloud.typesense.org/pricing#switching-from-algolia If that applies, could you email support@typesense.org and we can set you up. We can then do a private Slack connect channel to guide you through the migration and prioritize any missing features for you
m
I’ll let our director send you an email when he’s back in the office 🙂
👍 1
j
In general though, feel free to open Github issues with feature requests. That helps track demand / popularity of an ask
m
Definitely, but priority support isn’t a bad thing in these bespoke creations 🙂
🙂 1
Seems like the above is not working @Jason Bosco I used:
impact:[-4..8] && impact:=-100
But it is not returning any results. I want everything between -4 and 8 and also everything that is labelled -100
(on the same field for the matter)
j
Ah, looks like impact is not an array field. Could you try this instead:
[-4..8,-100]
m
I can one sec 🙂
Perfect @Jason Bosco, not a bad idea to add that to the docs examples 😉
j
Yup! Will add it
1
🎉 1