Support for FalkorDB instead of (now deprecated) RedisGraph? about quarkus

[quarkus-bot]

/cc @Ladicek (redis), @cescoffier (redis), @machi1990 (redis)

[cescoffier]

I don't understand how the copy command is related to Redis Graph. It seems, according to your example, to be a command of the group key.

If copy is a command supported by the base Redis, we can add it.

[flowt-au]

Thanks Clement. I will go back and look again. I think I misunderstood something because I am not clear now. Sorry. ;-)

[cescoffier]

I confirm, COPY is the base command: https://redis.io/docs/latest/commands/copy/

[gkorland]

COPY is not supported by FalkorDB only GRAPH.COPY see: https://docs.falkordb.com/commands/graph.copy.html

[flowt-au]

Thanks @cescoffier and @gkorland. I will do some more testing to see how to best get the new FalkorDB functionality without completely abandoning the Quarkus approach. I will try using the Vertx client directly for the "new" Falkor functionality.

Much appreciated,
Murray

[cescoffier]

There are two approaches:

• building an entirely new extension for FalkorDB - I believe it would be the better approach. It can provide its own dev service and so on
• adding a falkorDB group to the Redis client extension, based on the graph group. While this would require less work, it would complicate the user and internal code a lot (need 2 dev services, 2 connection pools, 2 underlying clients, etc.).

Thus, I would go with the first approach. We can create a quarkiverse repository to host the extension if you are willing to contribute.

[flowt-au]

@cescoffier Thanks Clement. I have started on the first suggestion.

As a starting point I am building a class that wraps JFalkorDB to provide both blocking and reactive methods. So far, so good. JFalkorDB wraps Jedis. I was hoping to make a "drop-in" replacement for the Quarkus Redis Datasource but since JFalkor returns different classes in the query response than does the Quarkus / Vertx response I have elected to go with the JFalkorDB class pattern. Processing the responses shouldn't be too different, mostly just different method names so VSCode / CoPilot should be of help there.

I will test against my current code base and graphs to confirm and document the migration path. Hopefully it won't be too messy! I have named things so as not to clash with the Quarkus Redis classnames and my plan is to implement both so I can incrementally convert my code, then remove the Redis extension. That means others could still use the Quarkus Redis extension for the other Redis modules and the Quarkus Falkor extension for graph.

Once that works I will read the "Write my own Quarkus Extension" guide and see how I go with that. Then yes, I would love to hand it over to the experts so others can benefit! ;-)

FalkorDB is looking very promising. One soon-to-be-released change supports maps / "nested json" as node properties so that will allow a graph-based JSON store type of thing which I am hanging out for.

Thanks again for your help and advice.
Murray

[cescoffier]

Unfortunately Jedis is not really reactive, in the sense that it dispatches on its own thread pool and does not adhere to the event loop model used by Quarkus.

It is still possible to use it, but will require some wrapping to always go back to the event loop.

[flowt-au]

Yes, so this is what I am doing as a quick and dirty test so far, which works, but I haven't been watching the thread, I must admit.

The blocking query:

public ResultSet graphQuery(String key, String query) {
  ResultSet result = null;
  try {
    Graph graph = driver.graph(key);

    ResultSet response = graph.query(query);
    
    // Debugging code removed...

    // Return the response
    result = response;
  } catch (Exception e) {
    throw e;
  }
  return result;
}

The reactive version:

    private FalkorGraphCommands blocking;

    public ReactiveFalkorGraphCommands(FalkorGraphCommands falkorGraphCommandsBlocking) {
      this.blocking = falkorGraphCommandsBlocking;
    }

    public Uni<ResultSet> graphQuery(String key, String query) {
      return Uni.createFrom().item(() -> {
        return blocking.graphQuery(key, query);
      });
    }

Perhaps I need to do something else? Tomorrow I will check the threads to see if I stay on the same one or not. That part is a bit of a mystery to me. I need to understand this better.

Thanks,
Murray

[flowt-au]

Final comment here: The test does all stay on the "Test runner thread" from the start of the test, to the reactive function, to the blocking function, back to the reactive, back to the test runner. So, looks like it is going to be ok, as far as I can see.