feat: add search filters for gene (clinically actionable, druggable g…

[katiestahl]

…enome, drug resistance)

close #479

I went ahead and also added these as fields to access for genes in gene_type.rb. Let me know whether or not we want to keep that @mcannon068nw . Otherwise, the core part that addresses the requirement is genes.rb

[katiestahl]

hmmm @mcannon068nw I'm debating removing the fields I added for gene_type since they're kinda unnecessary/redundant since a user can just look at the categories to synthesize that information if desired. On one hand, it's nice in the response for quick use and easy to find with a quick glance. But it also is a bit redundant since it's simplified info that's already available in the response... Thoughts?

[jsstevenson]

hmmm @mcannon068nw I'm debating removing the fields I added for gene_type since they're kinda unnecessary/redundant since a user can just look at the categories to synthesize that information if desired. On one hand, it's nice in the response for quick use and easy to find with a quick glance. But it also is a bit redundant since it's simplified info that's already available in the response... Thoughts?

FWIW I would agree that it can be dangerous to introduce a second way to do a thing that you can already do. IMO the graphql interface needs to just work and be efficient, and user friendliness/convenience can be implemented in consumer packages like rdgidb/dgipy.

[jsstevenson]

I approved this in principle, but a few other considerations/stuff I noticed:

• I've been trying to add test coverage for new queries/query features as I add them -- you could add a new "example" to this module covering these resolver filter args
• the following query causes a server error (note the name argument)

query {
  genes(druggableGenome:true, name:"BRAF"){
    edges {
      node {
        conceptId
        clinicallyActionable
      }
    }
  }
}

the stuff you added is correct but it's creating a conflict with the way the name arg is defined, to fix you need to change that arg definition to this:

  option(:name, type: String, description: 'Left anchored string search on gene symbol') do |scope, value|
    scope.where('genes.name ILIKE ?', "#{value.upcase}%")
    #                 ^ added genes table name here
  end

[mcannon068nw]

hmmm @mcannon068nw I'm debating removing the fields I added for gene_type since they're kinda unnecessary/redundant since a user can just look at the categories to synthesize that information if desired. On one hand, it's nice in the response for quick use and easy to find with a quick glance. But it also is a bit redundant since it's simplified info that's already available in the response... Thoughts?

FWIW I would agree that it can be dangerous to introduce a second way to do a thing that you can already do. IMO the graphql interface needs to just work and be efficient, and user friendliness/convenience can be implemented in consumer packages like rdgidb/dgipy.

It might be worth it to rethink this then. I think when I was envisioning this issue, I was trying to think of more ways to introduce potentially useful filtering at different layers of the query, not necessarily just the first level gene search.

As an example, I believe I was thinking about a case like this:

What if our researcher was hypothetically only interested in interactions for genes of a particular category, such as clinically actionable or KINASE? They could definitely write some post-processing code to filter based on whats returned in the gene categories block, but wouldn't it also be useful to just have something like this:

Where the filter is just done as an additional parameter and only returns results that are clinically actionable, or a kinase, or part of the druggable genome.

Would love some additional thoughts on this @jsstevenson @katiestahl

[jsstevenson]

^^ yeah that totally makes sense to me. We might want to double-check that this isn't a search that you could just do on interactions but if not, then it totally makes sense