absurdfarce commented on code in PR #2045:
URL: 
https://github.com/apache/cassandra-java-driver/pull/2045#discussion_r2920835606


##########
integration-tests/src/test/java/com/datastax/oss/driver/core/cql/PreparedStatementCachingIT.java:
##########
@@ -295,17 +298,20 @@ private void invalidationTestInner(
 
   Consumer<CqlSession> setupCacheEntryTestBasic =
       (session) -> {
-        session.execute("CREATE TYPE test_type_1 (a text, b int)");
-        session.execute("CREATE TYPE test_type_2 (c int, d text)");
-        session.execute("CREATE TABLE test_table_1 (e int primary key, f 
frozen<test_type_1>)");
-        session.execute("CREATE TABLE test_table_2 (g int primary key, h 
frozen<test_type_2>)");
+        session.execute("CREATE TYPE test_type_caching_1 (a text, b int)");
+        session.execute("CREATE TYPE test_type_caching_2 (c int, d text)");
+        session.execute(
+            "CREATE TABLE test_table_caching_1 (e int primary key, f 
frozen<test_type_caching_1>)");
+        session.execute(
+            "CREATE TABLE test_table_caching_2 (g int primary key, h 
frozen<test_type_caching_2>)");

Review Comment:
   Wait, is that how that works?  I remembered that working differently.  My 
recollection was that CcmBridge just controlled the ccm interaction and that 
the session rule was the entity that constrained ops to a given keyspace.
   
   Yeah, as I read this SessionRule [can create a new 
keyspace](https://github.com/apache/cassandra-java-driver/blob/4.19.2/test-infra/src/main/java/com/datastax/oss/driver/api/testinfra/session/SessionRule.java#L151-L156)
 if the user specifies it in the builder but this IT [does not currently do 
so](https://github.com/apache/cassandra-java-driver/blob/4.19.2/integration-tests/src/test/java/com/datastax/oss/driver/core/cql/PreparedStatementCachingIT.java#L77-L84)
 and this PR doesn't change that behaviour.
   
   I do agree we need a new keyspace per test (since without that the `create 
type` calls will definitely stomp on each other) but I don't think we're quite 
there yet are we?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to