Full-text search about graphql

[Dekhnar]

Any news ?

Hey, no news on this one yet. It's mainly because we would need a migrations toolset to insert and or remove the indexes.

Any plan for managing it (days, months, year) ?

We have thought about adding support for it without the need for migrations, though we realize it would be cumbersome and a disappointment for the users who are less experienced with adding indexes to their database. For now, this isn't high on our priority, and I apologize that we can't give you any timeframe.

Ok, no problems, I hope it will be implemented some day.
Thanks for your transparency et explanations.
Will find a workaround as said above.

[darrellwarde]

You're right @MeetSnowmaker, our initial target audience was indeed newcomers who were starting a fresh database based on their GraphQL type definitions, so a lot of our direction has been driven by that. However, that is not going to be the case forever, it's just a matter of balancing priorities given that we are only a small team.

We're beginning to discuss ideas such as directives which will allow you to map your type definitions to pre-existing underlying indexes to expose features such as this. We don't particularly want to manage these indexes in the same way that the old library did as we don't believe calling a function on every server start to assert indexes is a sustainable model of operations.

Please rest assured, we are thinking about these advanced features, it just takes us a little while to get there.

[MeetSnowmaker]

Since the @search directive was conflicting with the isFederated I manually hacked in the indexes on startup similar to the included searchShema(). I still used the directive for the schema and resolver generation, but this way I could include multiple fields as well.

const session = driver.session();

console.log('dropping stuff');
await session.writeTransaction(async (tx) => {
  console.log(`tx.run('db.index.fulltext.drop(name)`);
  tx.run(
    `
  CALL db.indexes() YIELD name, provider WHERE provider = "fulltext-1.0"
  CALL db.index.fulltext.drop(name)
  RETURN TRUE
  `,
  );
  console.log(`tx.commit()`);
  await tx.commit();
});
console.log('dropped stuff');

console.log('creating stuff');
await session.writeTransaction(async (tx) => {
  tx.run(
    `
    CALL db.index.fulltext.createNodeIndex("GraphEditorCanvasSearchIndex",["GraphEditorCanvas"],["name","description"])
    RETURN TRUE
    `,
  );
  tx.run(
    `
    CALL db.index.fulltext.createNodeIndex("ConceptSearchIndex",["Concept"],["primaryName","primaryCode"])
    RETURN TRUE
    `,
  );

  await tx.commit();
});
console.log('created stuff');

While we are waiting for official consideration, I think you could extend the type query with the desired cypher search expression that uses your where argument and the index you made.

I for one prefer to separate search and resolver logic to separate micro services in bigger projects, that way its enough to return primary keys on the search round and the owner service will resolve them in bulk with a dataloader. It also makes it agnostic to packages that generate default resolvers based on their own logic.

[Dekhnar]

Any news ?

[danstarns]

Any news ?

Hey, no news on this one yet. It's mainly because we would need a migrations toolset to insert and or remove the indexes.

[Dekhnar]

Any news ?

Hey, no news on this one yet. It's mainly because we would need a migrations toolset to insert and or remove the indexes.

Any plan for managing it (days, months, year) ?

[danstarns]

Any news ?

Hey, no news on this one yet. It's mainly because we would need a migrations toolset to insert and or remove the indexes.

Any plan for managing it (days, months, year) ?

We have thought about adding support for it without the need for migrations, though we realize it would be cumbersome and a disappointment for the users who are less experienced with adding indexes to their database. For now, this isn't high on our priority, and I apologize that we can't give you any timeframe.

[trondaal]

Imho opinion the problem is not the lack of a specific @search directive, but more the lack of filtering and sorting on objects returned from @cypher statements. Defining your own @cypher statement with CALL db.index.fulltext.queryNodes is rather trivial and already supported, but not being able to user this result in the same way as other result is a major shortcoming (that was conveniently solved using @search in neo4j-graphql-js).

[MeetSnowmaker]

I think this whole stuff could be resolved with a custom resolver parsing the search expression and pagination for the OGM.

To be honest, the whole schema driven on the fly autogenerated stuff is a good idea implemented in the wrong domain. A dynamically programmable db connector should use a datamodel (what we do in the schema right now) for client generation ( OGM ) and db configuration (schema push in dev and generated customizable migration files based on difference with a migrate toolkit as mentioned above) a crud schema file you can you to get the idea of what is this, and maybe some best practice tips and tricks and code snippets.

I dont want to badmouth or anything, I love this project, I love neo4j and I want it to work. After working with Prisma professionally the last 3 years I followed it evolving to a somewhat mature product and would like to see this lib reach the same granularity and function set while being driven by the apex graphDB. I'm using this lib for 3 Proof of concept projects at the moment and I still love it, but I basically have to override everything to suit an actual business logic middleware and only use the generated OGM client (wich is awesome btw). Its just that I feel the current implementation is way to directed towards being easy to learn for newcomers by doing many things automatically behind the curtains instead of by having a well written documentation and demo projects on how to implement it into an already existing concept // infrastructure.

[litewarp]

I wasn't a user of the previous library, so I can't comment on how things used to work. But after glancing at some of the former code for this feature I'm curious how this was implemented in the past.

• Specifically, was the search index only per single field?

• Was the return object an instance of the queried "Node", or could it be polymorphic (i.e., a union or interface)?

• Could you combine the search params with a where? (doesn't look like it).

• Would the library return nested nodes or relationships?

• Could you sort and/or paginate over the results?

I agree that fuzzy searching at the db level is useful, so I'm curious if this could be implemented as a graphql-tools transform plugin. The hardest thing I can think of at the moment is projecting nested nodes and relationships and handling sorting as this might require replicating good potions of the translate function. But adding indexes and modifying the schema to add search arguments would not be too difficult.

[rcbevans]

To start with I'd love to see a @search(indexName: "<name>") directive which can be used to generate a where filter which would start the traversal with the nodes from a full text search result set rather than generic MATCH (this:Type).

As mentioned, it's easy to add a cypher field which calls the full text index, but you then lose the awesome expressive filters that the library generates to narrow down the results.

[luchillo17]

I can't understand completely but if I get it right, we either use FullText or we use Regex to do case insensitive matching, is that correct?