Project planning

[lukaseder]

So, @jexp and @michael-simons, how would you like to plan the project to streamline our work? I know you said this doesn't (yet) have to become a full-blown product, @jexp, though I still think we could get the furthest, if we have a product mindset. For example, we'll probably need:

• [x] Define an API (can be a draft) that should be implemented for both ways
  • [x] SQL to Cypher
  • [ ] Cypher to SQL
• [x] That test suite using the text based test files
  • [x] Set up the infrastructure to run those tests
  • [x] Implement 1-2 example tests e.g. for SELECT 1 style queries, implement above API to pass these tests
• [x] Add a CLI to support the API from the command line, e.g. using picocli?

Once the above is done, the yak shaving of implementing all sorts of features can begin. (That's the part where I can be of assistance)

[jexp]

I'm not sure if we need both directions for a MVP?

What were you thinking in terms of API?

basically Translator.with(config).using(schema).translate(sql).toString()

Yes on the rest, I'd probably keep the CLI for later as it would be an optional (extra module)

• [ ] API including package structure?

Later we can do

• [x] CLI
• [x] CI
• [ ] Modules

[michael-simons]

I would actually start with the CLI or put it very much on top of things, it's just easier to play around with. The API will evolve eventually.

I can set up some test infra or make a suggestion

[jexp]

Ok, I'm good with that, so we'd have a build that also would generate a binary, or just an fat-jar to start with?

It would be great if you could set up the test infra @michael-simons

[michael-simons]

Test infra is done, also select 1 and a bit of CI. For the latter to work, we must wait until we have jOOQ 3.18

[lukaseder]

I'm not sure if we need both directions for a MVP?

I think we should do that. The earlier we find out whether there are issues, the better. This doesn't mean that the Cypher to SQL translation needs to be sophisticated from the start. It just means we know early on what to expect from it.

What were you thinking in terms of API?

basically Translator.with(config).using(schema).translate(sql).toString()

Yes, that sort of thing. How will users interact with the API? It won't be set in stone, but we need a draft now to get started.

API including package structure?

Do we need several packages? I can't yet think of many things that aren't just the pattern matching and the CLI logic.

I would actually start with the CLI or put it very much on top of things, it's just easier to play around with. The API will evolve eventually.

I agree, which is why I added it. Apart from the tests, it's the first consumer of the API, dogfooding it.

Ok, I'm good with that, so we'd have a build that also would generate a binary, or just an fat-jar to start with?

We can do that later, I think? If there's a CLI with a main(), then the utility can be used e.g. using maven-exec-plugin, gradle, or jbang to auto pull dependencies

Test infra is done, also select 1 and a bit of CI. For the latter to work, we must wait until we have jOOQ 3.18

I'll soon integrate this project in jOOQ's own CI. You won't get fast feedback cycle with that yet, but I will.

[michael-simons]

I added a CLI based on PicoCLI and renamed the SqlToCypher class in the progress.

[michael-simons]

Quite happy that both jOOQ and Cypher-DSL (and PicoCLI) are happy in the module path… Other libraries needed a bit of treatment and now we have jlink packages, too… :)

[michael-simons]

This project will live on under https://github.com/neo4j/neo4j-jdbc (See the translator package https://github.com/neo4j/neo4j-jdbc/tree/main/neo4j-jdbc-translator). The default translator can be used to create a CLI, if someone wants this.

I am gonna clone relevant issues (I cannot transfer them because this repo here and the JDBC repo are under different orgs and I might get angry words if I just drop this project under tld neo4j org).