Search case sensitivity

[evanshortiss]

Is your feature request related to a problem? Please describe.

Yes. I'm trying to query a string field, but my query fails since it's case sensitive. For example the DB contains "GITHUB", but my search contains "github".

Describe the solution you'd like

The ability to toggle case sensitivity for a query using a Boolean.

Describe alternatives you've considered

Could regular expressions be an option? So instead of findJunctions (filter: { name: { contains: "BREA" } }) a developer could pass findJunctions (filter: { name: { regex "/brea/ig" } }).

[machi1990]

Automatically generated comment to notify maintainers
/cc @craicoverflow, @machi1990, @wtrocki

[craicoverflow]

The ability to toggle case sensitivity for a query using a Boolean.

I've thought about this and though it would be easy enough to add, the filter input fields are purely to map to an underlying database table/collection - adding case sensitivity to the filter would also mix configuration into it this. We don't want to make the inputs too complex.

In your particular use case, do you see the need to combine {name: { contains: "BREA" }} with other conditions, or is this solely as a search query?
If the latter, this would be a great additional plugin:

• https://www.postgresql.org/docs/9.5/textsearch.html
• https://docs.mongodb.com/manual/text-search/

[wtrocki]

Yes. Text search is one of the proposed goals on roadmap post 1.0.
Doing any search, filtering on general entities now requires building complex filtering.

I'm thinking if there is workaround we can provide here.
Having custom resolver for this case with direct operation on knex/mongo is the obvious one.

[wtrocki]

Actually we can see if we can do something like Hasura done:
https://hasura.io/docs/1.0/graphql/core/queries/query-filters.html#text-search-or-pattern-matching-operators-like-similar-etc

[evanshortiss]

@craicoverflow exactly, this is a search query on a string field and supporting the DB-level text search would be ideal since it removes most ambiguity.

great additional plugin

I'm not incredibly famiilar with how Graphback internals operate; are the various filters implemented as plugins? Once a plugin is authored it can be exposed as a filter in the schema, similar to what @wtrocki linked?

[craicoverflow]

Yes, the various filters that you see are applied to the schema through the SchemaCRUDPlugin, this is a default plugin that is automatically executed on startup.

What this plugin does:

1. Creates the GraphQL schema with filters, queries, mutations, subscriptions using the data model you defined in the transformSchema plugin hook.
2. Generates the appropriate resolvers for each query, mutation, subscription and relationship field through the createResolvers plugin hook. These resolvers interface with the GraphbackCRUDService CRUD interface to interface with the database.

This plugin-first approach makes it possible for anyone to add their own plugins, or for us to extend it in the future with relative ease. Our docs have an example plugin setup guide.

Data synhronisation is not embedded into the core of Graphback, instead it is a plugin: https://github.com/aerogear/graphback/blob/master/packages/graphback-datasync/src/DataSyncPlugin.ts#L20

[evanshortiss]

That's very slick! I'll need to dig into it.

Do you think it's best to implement filters like this at the app level, and not Graphback level?

[wtrocki]

I think this specific issue - especially similar or ilike makes sense to be part of the core

[machi1990]

I think this specific issue - especially similar or ilike makes sense to be part of the core

+100

[CoreyKovalik]

+1000, we are actually creating a normalized field on models i.e. lowercase_name for this use case