Skip to content

change connection schema after USE is executed #2138

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
chernser merged 5 commits into from
Feb 12, 2025
Merged

change connection schema after USE is executed #2138

chernser merged 5 commits into from
Feb 12, 2025
+20 −0

Conversation

@gfunc
Copy link
Contributor

@gfunc gfunc commented Feb 11, 2025

Summary

enable USE database; statement for JDBC V2
Closes #2137

Checklist

Delete items not relevant to your PR:

  • Closes #2137
  • Unit and integration tests covering the common scenarios were added

@chernser
Copy link
Contributor

chernser commented Feb 11, 2025

Good day, @gfunc !
Thank you for the wonderful contribution! We will review it shortly!

@chernser chernser requested a review from Paultagoras February 11, 2025 14:29
@chernser
Copy link
Contributor

chernser commented Feb 11, 2025

@gfunc
The tests have failed:

java.sql.SQLException: Code: 57. DB::Exception: Table clickhouse_java_152aac8b_test_1739292947239.strings already exists. (TABLE_ALREADY_EXISTS) (version 23.8.16.16 (official build)) 
	at com.clickhouse.jdbc.internal.ExceptionUtils.toSqlState(ExceptionUtils.java:64)
	at com.clickhouse.jdbc.internal.ExceptionUtils.toSqlState(ExceptionUtils.java:39)
	at com.clickhouse.jdbc.StatementImpl.executeUpdate(StatementImpl.java:237)
	at com.clickhouse.jdbc.StatementImpl.executeUpdate(StatementImpl.java:204)
	at com.clickhouse.jdbc.StatementTest.testSwitchDatabase(StatementTest.java:548)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:569)
	at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:136)
	at org.testng.internal.invokers.TestInvoker.invokeMethod(TestInvoker.java:658)
	at org.testng.internal.invokers.TestInvoker.invokeTestMethod(TestInvoker.java:219)
	at org.testng.internal.invokers.MethodRunner.runInSequence(MethodRunner.java:50)
	at org.testng.internal.invokers.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:923)
	at org.testng.internal.invokers.TestInvoker.invokeTestMethods(TestInvoker.java:192)
	at org.testng.internal.invokers.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.invokers.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
	at org.testng.TestRunner.privateRun(TestRunner.java:808)
	at org.testng.TestRunner.run(TestRunner.java:603)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:429)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:423)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:383)
	at org.testng.SuiteRunner.run(SuiteRunner.java:326)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:95)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1249)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1169)
	at org.testng.TestNG.runSuites(TestNG.java:1092)
	at org.testng.TestNG.run(TestNG.java:1060)
	at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:155)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:169)
	at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:88)
	at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:137)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:385)
	at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
	at org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:507)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:495)
Caused by: com.clickhouse.client.api.ServerException: Code: 57. DB::Exception: Table clickhouse_java_152aac8b_test_1739292947239.strings already exists. (TABLE_ALREADY_EXISTS) (version 23.8.16.16 (official build)) 
	at com.clickhouse.client.api.internal.HttpAPIClientHelper.readError(HttpAPIClientHelper.java:364)
	at com.clickhouse.client.api.internal.HttpAPIClientHelper.executeRequest(HttpAPIClientHelper.java:414)
	at com.clickhouse.client.api.Client.lambda$query$10(Client.java:1[623](https://github.com/ClickHouse/clickhouse-java/actions/runs/13260591506/job/37040964375?pr=2138#step:7:624))
	at com.clickhouse.client.api.Client.runAsyncOperation(Client.java:2006)
	at com.clickhouse.client.api.Client.query(Client.java:1666)
	at com.clickhouse.client.api.Client.query(Client.java:1564)
	at com.clickhouse.jdbc.StatementImpl.executeUpdate(StatementImpl.java:230)

Would you please take a look?

@gfunc
Copy link
Contributor Author

gfunc commented Feb 12, 2025

Hi @chernser, Thanks for your lightning-fast response!
I've run the test added with multiple versions of ClickHouse before this PR in Intellij and JDK17, and will take a detailed look at the GitHub workflow and run these test locally

@gfunc
Copy link
Contributor Author

gfunc commented Feb 12, 2025

fixed by renaming table and database.

@chernser chernser merged commit e37c105 into ClickHouse:main Feb 12, 2025
23 of 28 checks passed
@chernser
Copy link
Contributor

chernser commented May 1, 2025 •
edited
Loading

@gfunc
I've came across your changes about database. Currently USE database affects connection. I think, that it should affect only statement level because:

  • child may not change parent instance
  • changing database will affect other statements from same connection what may cause a race condition.

Do you have a use-case when it should be connection wide?

Thanks!

@gfunc
Copy link
Contributor Author

gfunc commented May 8, 2025

Hi @chernser
The initial thought was to set USE at the statement level in this PR. However, as I mentioned in another PR, I noticed that the unit test for use had failed, tracing down to this code

clickhouse-java/jdbc-v2/src/main/java/com/clickhouse/jdbc/StatementImpl.java

Line 124 in 76dbe35

mergedSettings.setDatabase(connection.getSchema());

I assumed we are using the Connection schema instead of this Statement schema, and we could change it back to statement level by making sure all database usages in StatementImpl came from this.schema.

As for my thoughts on this issue, apologies for not having too much experience, I think we should be able to use the same connection for multiple "sessions". I am up for making USE effective only at the Statement level.

@chernser
Copy link
Contributor

chernser commented May 19, 2025

@gfunc thank you for the explanation!
This is fine - JDBC is quite complex when it come to usage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@chernser chernser chernser approved these changes

+1 more reviewer

@Paultagoras Paultagoras Paultagoras approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

[jdbc-v2] Set database statement not taking effect

3 participants

@gfunc @chernser @Paultagoras