[feature request/bug report] comparative operator doesn't work with community rating
So if one apply e.g. rating>3, only myrating>3 is shown, but not those provided from community rating.
Comments
-
Kolen Cheung said:
So if one apply e.g. rating>3, only myrating>3 is shown, but not those provided from community rating.
You're missing the colon. It should be rating:>3 (which does work for community ratings).
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Oh, great! Sorry for such a silly mistake.
I tested using
mytag>4
and it “worked” and I didn’t double check the syntax in the wiki.But of course in the hindsight its result is not the same as that of
mytag:>4
. Don’t know how Logos is parsing that as a string though. Becausemytag>4
would results in a ton of resources buttag>4
doesn’t at all.I guess it is an example of a not strongly spec’d DSL leading to confusion and unexpected behavior.
0 -
Kolen Cheung said:
Because
mytag>4
would results in a ton of resources buttag>4
doesn’t at all.It's the other way around.
XXX>4 will return exactly the same results as XXX (the >4 is ignored as invalid). There lots of resources with the letters 'tag' in the title, description, publisher, etc., but none with the letters 'mytag'.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Kolen Cheung said:
Don’t know how Logos is parsing that as a string though.
I guess it is an example of a not strongly spec’d DSL leading to confusion and unexpected behavior.
See https://community.logos.com/forums/p/132647/862316.aspx#862316. The same query parser as the resource search engine is used in the Library Catalog, leading to similar unexpected results.
This situation is a little more interesting, though, as (I'm guessing) most users would want (a hypothetical) "fuzzy mode" on for an ad-hoc query in the Library (maybe ignoring typos in the query), but "strict mode" in Collections (which should have more predictable results, yet mostly share the same syntax).
Anyway, it's something we're keeping in mind for potential future search enhancements but we have no current plans to change the behaviour of Library filtering/Collection rules.
0