Skip to content

Using _in graphql filter functionality provides OR behavior, not AND #42

Description

@NoisyFlowers

We use the _in filter functionality of neo4j-graphql-js (https://github.com/neo4j-graphql/neo4j-graphql-js/blob/master/docs/graphql-filtering.md) in many of our queries. It's easy and convenient. However, by doing this we are providing OR functionality when our intent is to provide AND.

For instance, take a look at this query clause in our Specimen search form:

{partsPreserved_some: {pbotID_in: $partsPreserved}}

If several partsPreserved are specified, this query clause will return Specimens that have at least one of those partsPreserved. Our intent is to return Specimens that have all of those partsPreserved.

I haven't found a convenient neo4j-graphql-js filtering approach that provides what we want. The documentation is unclear, forcing one to trial and error. I had hoped using _every instead of _some in the outer portion would do it, but the resulting behavior is unexpected and appears to be erratic (I can't explain it, at least).

The best I've come up with is to generate a separate query clause for each partsPreserved specified. Something like:

                filters.partsPreserved.forEach((p,i) => {
                    filter += `, {
                        partsPreserved_some: {
                                    pbotID: $partPreserved${i}
                        }
                    `
               })

Note that this also requires us to generate graphql variables to match that specified in the above query clause string.

This is the approach used for the forthcoming multi-character Description querying on Specimen and OTU. I haven't implemented it elsewhere yet.

We use _in all over the place. Updating all of these will take time. It will also generate a lot more graphql code than we do at this time.

Because of the scale of fixing this everywhere and the fact that what we have right now is providing useable search functionality, even if it's not exactly what we intend, I'm not sure this should be a priority at this time.

Activity

  1. self-assigned this
    on Aug 2, 2024
  2. NoisyFlowers commented on Aug 2, 2024

    @NoisyFlowers
    ContributorAuthor

    To be clear: We are doing AND search between query elements (e.g. partPreserved and notableFeatures). But within each of those (and any that allow the specification of multiple values) we are doing OR right now.

  3. aazaff commented on Aug 3, 2024

    @aazaff
    Contributor

    That last comment was very helpful. I am also unsure on where to prioritize this within everything else. We officially have unitl the 15th. Do you have any items you especially want to prioritize on your end?

  4. NoisyFlowers commented on Aug 6, 2024

    @NoisyFlowers
    ContributorAuthor

    Initial experimentation in how to address this is on the QueryHelper branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions