[feature request/bug report] comparative operator doesn't work with community rating

Kolen Cheung
Kolen Cheung Member Posts: 1,096 ✭✭✭
edited November 2024 in English Forum

So if one apply e.g. rating>3, only myrating>3 is shown, but not those provided from community rating.

Tagged:

Comments

  • Mark Barnes
    Mark Barnes Member Posts: 15,432 ✭✭✭

    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!

  • Kolen Cheung
    Kolen Cheung Member Posts: 1,096 ✭✭✭

    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. Because mytag>4 would results in a ton of resources but tag>4 doesn’t at all.

    I guess it is an example of a not strongly spec’d DSL leading to confusion and unexpected behavior.

  • Mark Barnes
    Mark Barnes Member Posts: 15,432 ✭✭✭

    Because mytag>4 would results in a ton of resources but tag>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!

  • Bradley Grainger (Logos)
    Bradley Grainger (Logos) Administrator, Logos Employee Posts: 11,993

    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.