Proposal of restructuring code (RFC)

[zhicwu]

As the project grows, in order to better manage the code, expectations and dependencies, I hope we can re-organize the repository by creating multiple modules. With that, we no longer have to put all ideas into one single lib, trying to make it both a JDBC driver and Java client for ClickHouse. Instead, we'll follow JDBC specification in clickhouse-jdbc module for standard update/delete operation, synchronous execution, and escape syntax like {d '2020-02-17'}(which is same as toDate('2021-02-17') by the way) etc. On the other hand, we'll stick with the "clickhouse-way" when implementing clickhouse-client module, so that it behaves like any other clickhouse clients.

• optionally new package name(and maven groupId): ru.yandex.clickhouse -> tech.clickhouse
• new directories(and maybe a separate repo like clickhouse-java later)

  |
  |-- clickhouse-client
  |-- clickhouse-http-client
  |-- clickhouse-grpc-client
  |-- clickhouse-native-client
  |-- clickhouse-jdbc
  |-- clickhouse-jdbc-ext (tentative)
  |-- clickhouse-gql (tentative)
  |-- clickhouse-r2dbc (tentative)
  |...
  

• modules and API layers
  
• how to approach?
  I hope we can implement the new structure starting from 0.3.0, but it's primarily about moving code from src to clickhouse-jdbc/src and pile up code into other modules. This ensures we can produce binary compatible package in 0.3 series. And then, starting from 0.4.0, I hope we can optionally change package name and refactor clickhouse-jdbc module by leveraging code from clickhouse-client module etc., which will introduce different binary packages.

Please feel free to comment and I'll start to create PR if no concern.

[den-crane]

I am OK with all of this.

[alexey-milovidov]

I am totally Ok with all the proposed changes.

[enqueue]

While I do see a benefit in having clearer module structures, I think there is other stuff to do for 0.3.0 before trying to break things up this way, see Roadmap 2021 #537

[zhicwu]

Update:

• renamed clickhouse-native-client to clickhouse-tcp-client for two reasons: 1) naming consistency; and 2) native is a reserved keyword in module-info.java.
• applied new group id tech.clickhouse in OSSRH-65794
• applied new group id com.clickhouse in OSSRH-73453
• will add clickhouse-graphql(instead of clickhouse-gql), clickhouse-r2dbc, and clickhouse-jdbc-ext 3 modules in the future when needed