Open KelseaChang5 opened 2 years ago
Website Request Checklist:
This request would be an epic unto itself; it speaks to the need to have more filtering and searching available in Genegraph. I think we may want to consider an epic for this, though I don't think we would do everything suggested here.
@KelseaChang5 This request requires a bigger discussion to get to a set of distinct prioritized requests with a direct understanding of the downstream efforts they are gating. At this point we will not be prioritizing this as one comprehensive request.
Questions for Phil and Erin: When can we go through and discuss the downstream features being gated by lack of search capabilities in GG? Based on that discussion can we determine if those search capabilities are best supported by GG or by the website? Finally, can we then prioritize the discrete search features that GG needs to deliver and what other work will be displaced as a result?
@toneillbroad Pls read my comment above. I don't want to step on your plans with Phil. If this request is something that the two of you are trying to break down and tackle so as to identify the actual enhancements that are most critical to make to GG then please let us know.
Let's discuss at our next standup, what to do with this ticket. Break it up , refine, etc..
Not sufficient info on how this is being planned from the website. Not an imminent need to address but would be a worthwhile discussion to add a ticket for someone to delve deep into the jena/lucene relationship to get out in front and see if there is a way to provide the equivalent of facets (ala elasticsearch) and perhaps provide some demo code for the website to see.
discussed at 2/14 standup as a team, decided we will need to do some strategizing around improving search. @toneillbroad will verify with Phil that this is not urgent and let him know we will need some requirements work around defining specifically what needs to be done. As this request stands it is much too broad to consider a single request.
Website request (CGWM-360) - ClinGen Website JIRA Board ticket link Requested Date of Completion: June 24, 2022
Description Genegraph currently provides extremely limiting select capability. If order to implement the Advanced Search functionality on the website using data from Genegraph, it will be necessary for Genegraph to offer the same functionality one would expect from any database.
This request is to provide a full query experience for all calls, allowing for conditionals, sorting, pattern matching, and logical clauses. For example, in a standard relational database, one can specify pattern matching via the LIKE operator, logical clauses via the AND and OR operator, and conditionals via the WHERE clause. This is expected functionality and necessary to do even the most basic of selects. (In GraphQL vernacular, this might be known as filters?)
This request imagines augmenting all calls with a “where” attribute that allows complex expressions via some standard json or pseudo sql structure. Research shows this is a common approach others have done with GraphQL but our queries don’t seem to accept where attribute (Postgres: Filter query results / search queries | Hasura GraphQL Docs | Writing Your First GraphQL Query ).
The actual format implemented is not important, only that the functionality be provided, and a reasonably easy language construct implemented which does not require in-depth knowledge of how Genegraph manages its internal stores or relation trees. Below is the minimal functionality needed to implement Advanced Search, however, over time, it is reasonable to assume more database functionality will be needed to support the needs of the users.l (Examples in pseudo sql for ease of understanding since we are all familiar with it):
Complex select conditionals (ex: where activity = dosage AND (haplo > 0 OR triplo > 0)
Ability to select from an array of options, similar to the IN predicate (ex. where haplo in [1, 2, 3, 40])
Ability to perform a conditional on an item but not include it in the return set. (Ex select actionability.classification where actionability.gene = dosage.gene)
Ability to select on intrinsic record data, such as create and updated dates (ex. where date.updated > 2022-01-01)
Pattern matching (ex. where gene.label like ‘%something%’)
Basic builtin functions like COUNT(), MAX(), and MIN()
Joins/has/nesting (which sort exists within the current implementation) but need ability for root where to descend into subsequent call results
Sorting on any returned attribute. (ex. where activity = dosage OR activity = actionability orderby actionability.classification desc)
There may be other standard DB functions required but this allows initial planning and development to begin.
This request was discussed on previous calls so it should not be a surprise and I would imagine the reasons for it are clear but if any questions please don’t hesitate to ask.