imply-cheddar commented on code in PR #16249:
URL: https://github.com/apache/druid/pull/16249#discussion_r1575624661
##########
quidem:
##########
Review Comment:
I'm a little scared of "binaries" just sitting in the top level directory.
How do you feel about moving this to like `dev/bin/`?
##########
sql/pom.xml:
##########
@@ -192,6 +192,22 @@
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>
+ <dependency>
+ <groupId>net.hydromatic</groupId>
+ <artifactId>quidem</artifactId>
+ <version>0.11</version>
Review Comment:
This version should be in the parent pom rather than a child pom.
##########
sql/src/test/java/org/apache/druid/sql/calcite/util/SqlTestFramework.java:
##########
@@ -570,6 +570,7 @@ private SqlTestFramework(Builder builder)
// test pulls in a module, then pull in that module, even though we are
// not the Druid node to which the module is scoped.
.ignoreLoadScopes()
+ .addModule(binder ->
binder.bind(Closer.class).toInstance(resourceCloser))
Review Comment:
What's depending on a `Closer` to be injected? There should likely be some
other way of achieving this.
##########
sql/src/test/java/org/apache/druid/sql/calcite/util/SqlTestFramework.java:
##########
@@ -570,6 +570,7 @@ private SqlTestFramework(Builder builder)
// test pulls in a module, then pull in that module, even though we are
// not the Druid node to which the module is scoped.
.ignoreLoadScopes()
+ .addModule(binder ->
binder.bind(Closer.class).toInstance(resourceCloser))
Review Comment:
Looks like it's the AvaticaServer. That should have its lifecycle managed
more closely/explicitly. Just relying on a closer like this generates a
pattern in code that leads to resource leaks and poor lifecycle management (I
realize that it's probably safe in this one test, but the pattern itself gets
seen and then repeated).
You should either mark it as `@LifecycleManaged`, if the test is getting a
Lifecycle object, calling `.start()` and `.stop()` on it, then this will end up
registering the object with that `Lifecycle` just naturally. This is the best
pattern.
If the test isn't using the `Lifecycle` object, then it should be explicitly
getting the `AvaticaServer` instance out of the Injector and closing it
explicitly in the `close` method.
##########
sql/src/test/java/org/apache/druid/quidem/DruidQuidemTestBase.java:
##########
@@ -0,0 +1,207 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.druid.quidem;
+
+import com.google.common.io.Files;
+import net.hydromatic.quidem.CommandHandler;
+import net.hydromatic.quidem.Quidem;
+import net.hydromatic.quidem.Quidem.Config;
+import net.hydromatic.quidem.Quidem.ConfigBuilder;
+import org.apache.calcite.test.DiffTestCase;
+import org.apache.calcite.util.Closer;
+import org.apache.calcite.util.Util;
+import org.apache.commons.io.filefilter.TrueFileFilter;
+import org.apache.commons.io.filefilter.WildcardFileFilter;
+import org.apache.druid.java.util.common.FileUtils;
+import org.apache.druid.java.util.common.IAE;
+import org.apache.druid.java.util.common.RE;
+import org.apache.druid.java.util.common.StringUtils;
+import org.junit.jupiter.api.TestInstance;
+import org.junit.jupiter.params.ParameterizedTest;
+import org.junit.jupiter.params.provider.MethodSource;
+
+import java.io.File;
+import java.io.FileFilter;
+import java.io.FileNotFoundException;
+import java.io.IOException;
+import java.io.Reader;
+import java.io.Writer;
+import java.util.ArrayList;
+import java.util.Collections;
+import java.util.List;
+
+import static org.junit.jupiter.api.Assertions.fail;
+
+/**
+ * Execute Quidem tests in Druid.
+ *
+ * How these tests work:
+ * <ol>
+ * <li>Test cases are in .iq files - contract of these files is that they
+ * produce themselves if it was executed without errors</li>
+ * <li>Executor (this class) picks up these files and runs them as part of unit
+ * testruns</li>
+ * <li>System under test is connected via an adapter which looks like a JDBC
+ * driver</li>
+ * </ol>
+ *
+ * Example usage:
+ * <ol>
+ * <li>Write new .iq test as a under the appropriate directory; with command
for
+ * expectations but without specifying them.</li>
+ * <li>Run the test - it will produce a ".iq.out" file next to the ".iq"
+ * one.</li>
+ * <li>Copy over the .iq.out to .iq to accept the changes</li>
+ * </ol>
+ *
+ * To shorten the above 2 steps
+ *
+ */
+@TestInstance(TestInstance.Lifecycle.PER_CLASS)
+public abstract class DruidQuidemTestBase
+{
+
+ public static final String IQ_SUFFIX = ".iq";
+ /**
+ * System property name for "overwrite mode"; note: empty value is treated as
+ * true
+ */
+ private static final String OVERWRITE_PROPERTY = "quidem.overwrite";
+
+ private static final String PROPERTY_FILTER = "quidem.filter";
+
+ private FileFilter filter = TrueFileFilter.INSTANCE;
+
+ private DruidQuidemRunner druidQuidemRunner;
+
+ public DruidQuidemTestBase()
+ {
+ String filterStr = System.getProperty(PROPERTY_FILTER, null);
+ if (filterStr != null) {
+ if (!filterStr.endsWith("*") && !filterStr.endsWith(IQ_SUFFIX)) {
+ filterStr = filterStr + IQ_SUFFIX;
+ }
+ filter = new WildcardFileFilter(filterStr);
+ }
+ druidQuidemRunner = new DruidQuidemRunner();
+ }
+
+ /** Creates a command handler. */
+ protected CommandHandler createCommandHandler()
+ {
+ return Quidem.EMPTY_COMMAND_HANDLER;
+ }
+
+ @ParameterizedTest
+ @MethodSource("getFileNames")
+ public void test(String testFileName) throws Exception
+ {
+ File inFile = new File(getTestRoot(), testFileName);
+
+ final File outFile = new File(inFile.getParentFile(), inFile.getName() +
".out");
+ druidQuidemRunner.run(inFile, outFile);
+ }
+
+ public static class DruidQuidemRunner
+ {
+ public DruidQuidemRunner()
+ {
+ }
+
+ public void run(File inFile) throws Exception
+ {
+ File outFile = new File(inFile.getParent(), inFile.getName() + ".out");
+ run(inFile, outFile);
+ }
+
+ public void run(File inFile, final File outFile) throws Exception
+ {
+ FileUtils.mkdirp(outFile.getParentFile());
+ try (Reader reader = Util.reader(inFile);
+ Writer writer = Util.printWriter(outFile);
+ Closer closer = new Closer()) {
+
+ DruidQuidemConnectionFactory connectionFactory = new
DruidQuidemConnectionFactory();
+ ConfigBuilder configBuilder = Quidem.configBuilder()
+ .withConnectionFactory(connectionFactory)
+ // this is not nice - but it makes it possible to do queryContext
+ // changes
Review Comment:
A nit about the comment, "this is not nice" will make the next developer
that comes along believe that there is something wrong with the code. But,
like, have no clue what is wrong. Like, what's "not nice"? Why is it "not
nice"? Either leave out the statement and just say "we include the
connectionFactory again so that it can see queryContext changes" or update the
comment to include an explanation of what's sub-optimal and what future work
could be done to make it better.
Sorry for being anal about "just a comment" but when developers are reading
new code, they tend to put a ton of faith in the comments written in that code,
even though the comments are often an after-thought/just a random thing written
and forgotten by the original developer.
--
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]
