core/src/test/java/io/questdb/test/griffin/engine/functions/groupby/GeomeanDoubleGroupByFunctionFactoryTest.java (1)

71-91: Normalize the new SQL to the test style guide.

The added statements use lowercase SQL keywords, and the longer CTAS/query in testGeomeanAgainstExpAvgLnFormula() would be clearer as text blocks. Please keep new test SQL in the repository’s standard format. As per coding guidelines, "In SQL statements within test code, use UPPERCASE for SQL keywords" and "Use multiline strings for longer statements (multiple INSERT rows, complex queries) and to assert multiline query results".

Also applies to: 116-152

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@core/src/test/java/io/questdb/test/griffin/engine/functions/groupby/GeomeanDoubleGroupByFunctionFactoryTest.java`
around lines 71 - 91, The test uses lowercase inline SQL and a single-line
string for a longer CTAS/query; update the statements in
testGeomeanAgainstExpAvgLnFormula() to follow the project style by converting
SQL keywords to UPPERCASE and using multiline text blocks for the CTAS and the
SELECT used in assertSql; specifically replace the execute("create table tab as
(... )") call with a multiline string containing UPPERCASE keywords (e.g.,
CREATE TABLE AS SELECT FROM LONG_SEQUENCE) and similarly make the SELECT passed
to assertSql a text block with all SQL keywords uppercased, leaving the expected
result string unchanged, and ensure you apply the same changes to the other
occurrence noted (lines 116-152) for consistency.

core/src/test/java/io/questdb/test/griffin/WindowJoinTest.java (1)

120-132: Extract a helper for encoded-sort plan prefixes.

This rename touched a lot of assertions for a pure plan-node label change. Pulling the "Encode sort" / "Encode sort light" prefixes into a small helper would make future planner-label churn much less noisy in this file.

♻️ Example shape

+    private static String encodeSortPlan(String keys, String body) {
+        return "Encode sort\n" +
+                "  keys: [" + keys + "]\n" +
+                body;
+    }
+
+    private static String encodeSortLightPlan(String keys, String body) {
+        return "Encode sort light\n" +
+                "  keys: [" + keys + "]\n" +
+                body;
+    }

Also applies to: 4374-4429

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@core/src/test/java/io/questdb/test/griffin/WindowJoinTest.java` around lines
120 - 132, Refactor repeated plan-prefix strings by extracting a helper method
(e.g., encodeSortPrefix or getEncodeSortPrefix) that returns either "Encode
sort\n" or "Encode sort light\n" based on a parameter, then replace all
hard-coded occurrences in WindowJoinTest (including the multi-line expected
strings around the Async Window Fast Join blocks at the locations shown and the
similar block at lines ~4374-4429) to call this helper so assertions concatenate
the helper result with the rest of the expected plan text; update test helper
usages where the prefix is needed so future label renames are handled in one
place.

core/src/test/java/io/questdb/test/griffin/SecurityTest.java (2)

560-560: Avoid pinning these assertions to the EncodedSort implementation name.

These checks will start failing on harmless renames/refactors even if the memory-limit behavior is still correct. If the intent is to validate the failure mode, assert a stable fragment like memory exceeded or an error code, and keep plan/path assertions separate.

Also applies to: 809-809, 1092-1092, 1156-1156

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@core/src/test/java/io/questdb/test/griffin/SecurityTest.java` at line 560,
Replace assertions that match the full implementation name "memory exceeded in
EncodedSort" with a stable fragment such as "memory exceeded" (e.g. change the
Assert.assertTrue(...contains("memory exceeded in EncodedSort")) calls in
SecurityTest.java to assert on "memory exceeded"). Keep any plan/path or
implementation-name checks as separate assertions if you still need to validate
the execution plan; update the occurrences around the Assert.assertTrue calls at
the noted spots (lines with Assert.assertTrue(ex.toString().contains(...))) so
they check the generic error text or an error code rather than the concrete
class name.

---

1148-1156: This change no longer exercises the tree fallback path.

ORDER BY sym1, count() stays within the encoded-key path described in this PR, so this test now validates EncodedSort rather than the tree-resize scenario implied by testTreeResizesWithImplicitGroupBy. Please keep a separate case that forces the fallback sorter, or rename this test if that coverage moved elsewhere.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@core/src/test/java/io/questdb/test/griffin/SecurityTest.java` around lines
1148 - 1156, The current assertion in testTreeResizesWithImplicitGroupBy now
hits EncodedSort (query "select sym1, count() from tb1 order by sym1, count()")
and no longer triggers the tree-resize fallback; either add a separate assertion
that will force the fallback sorter (for example run the same aggregation but
order only by the aggregate like "select sym1, count() from tb1 order by
count()" or otherwise change the ORDER BY to one that does not use the
encoded-key path) or rename the test to reflect it now targets EncodedSort;
update the test body around the existing execute/query call and the
Assert.assertTrue checking for "memory exceeded in EncodedSort" (or add a new
try/catch block) so there is a distinct case that exercises the tree-resize
fallback path referenced by testTreeResizesWithImplicitGroupBy.

core/src/main/java/io/questdb/std/Vect.java (1)

419-419: Place sortEncodedEntries() in the alphabetical sort* section.

The new method was inserted before sortArrayColumn(), which breaks the required ordering for public static members in Java files.

As per coding guidelines, **/*.java: "Group Java class members by kind (static vs. instance) and visibility, sorted alphabetically."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@core/src/main/java/io/questdb/std/Vect.java` at line 419, The new native
method sortEncodedEntries(long addr, long count, int keyLongs) in class Vect
should be relocated into the alphabetical block of public static sort* methods:
move its declaration so it appears in the same section as and alphabetically
among other sort* methods (for example placing it after sortArrayColumn() or
wherever it fits alphabetically), preserving the native modifier and signature.

core/src/main/java/io/questdb/cairo/CairoConfigurationWrapper.java (1)

1559-1562: Move isSqlParquetRowGroupPruningEnabled() into the alphabetical isSqlP... block.

This delegation is fine, but its current placement comes after all isSqlParallel* members, so the class no longer follows the required member ordering for Java files.

As per coding guidelines, **/*.java: "Group Java class members by kind (static vs. instance) and visibility, sorted alphabetically."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@core/src/main/java/io/questdb/cairo/CairoConfigurationWrapper.java` around
lines 1559 - 1562, The method isSqlParquetRowGroupPruningEnabled() is misplaced
after the isSqlParallel* members, breaking the alphabetical grouping; move the
entire method (public boolean isSqlParquetRowGroupPruningEnabled()) into the
existing alphabetical isSqlP... block among the other isSqlParquet*/isSqlP*
methods so members remain grouped and alphabetized by name consistent with the
class's Java member ordering rules.

core/src/test/java/io/questdb/test/griffin/engine/groupby/SampleByTest.java (1)

6279-6326: Use UPPERCASE for SQL keywords in test SQL statements.

The SQL statements use lowercase keywords (select, from, sample by, fill), which does not follow the coding guidelines for test code.

♻️ Proposed fix

             assertSql(
                     """
                             ts\tavg
                             2017-12-30T00:00:00.000000Z\t72.5
                             2018-01-04T00:00:00.000000Z\t264.5
                             2018-01-09T00:00:00.000000Z\t432.5
                             """,
-                    "select ts, avg(x) from fromto\n" +
-                            "sample by 5d"
+                    "SELECT ts, avg(x) FROM fromto\n" +
+                            "SAMPLE BY 5d"
             );
             assertSql(
                     """
                             ts\tavg
                             2017-12-20T00:00:00.000000Z\tnull
                             2017-12-25T00:00:00.000000Z\tnull
                             2017-12-30T00:00:00.000000Z\t72.5
                             2018-01-04T00:00:00.000000Z\t264.5
                             2018-01-09T00:00:00.000000Z\t432.5
                             """,
-                    "select ts, avg(x) from fromto\n" +
-                            "sample by 5d from '2017-12-20' fill(null)"
+                    "SELECT ts, avg(x) FROM fromto\n" +
+                            "SAMPLE BY 5d FROM '2017-12-20' FILL(null)"
             );
             assertSql(
                     """
                             ts\tavg
                             2017-12-20T00:00:00.000000Z\tnull
                             2017-12-25T00:00:00.000000Z\tnull
                             2017-12-30T00:00:00.000000Z\t72.5
                             2018-01-04T00:00:00.000000Z\t264.5
                             2018-01-09T00:00:00.000000Z\t432.5
                             2018-01-14T00:00:00.000000Z\tnull
                             2018-01-19T00:00:00.000000Z\tnull
                             2018-01-24T00:00:00.000000Z\tnull
                             2018-01-29T00:00:00.000000Z\tnull
                             """,
-                    "select ts, avg(x) from fromto\n" +
-                            "sample by 5d from '2017-12-20' to '2018-01-31' fill(null)"
+                    "SELECT ts, avg(x) FROM fromto\n" +
+                            "SAMPLE BY 5d FROM '2017-12-20' TO '2018-01-31' FILL(null)"
             );

As per coding guidelines: "In SQL statements within test code, use UPPERCASE for SQL keywords (CREATE TABLE, INSERT, SELECT ... AS ... FROM, etc.)"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@core/src/test/java/io/questdb/test/griffin/engine/groupby/SampleByTest.java`
around lines 6279 - 6326, In testSampleByFromToFillNull, update the SQL literals
passed to assertSql so all SQL keywords are UPPERCASE: change "select" to
"SELECT", "from" to "FROM", "sample by" to "SAMPLE BY", "from '...'"/ "to '...'"
to "FROM '...'" / "TO '...'", and "fill(null)" to "FILL(NULL)" in the three
assertSql calls (the queries that reference the fromto table); keep string
literals like dates and identifiers unchanged.

core/src/test/java/io/questdb/test/griffin/OrderByEncodeSortTest.java (1)

89-102: Use UPPERCASE for SQL keywords.

Per coding guidelines, SQL keywords in test code should be UPPERCASE. The query and DDL statements use lowercase select, from, create table, case, when, then, else, end, as.

♻️ Example fix for one test

-                "select * from x order by a asc;",
-                "create table x as (" +
-                        "select" +
-                        " cast (case" +
-                        "     when x < 10 then x" +
-                        "     when x >= 10 and x < 15 then null" +
-                        "     else x - 25" +
-                        " end as date) as a" +
-                        " from long_sequence(25)" +
-                        ")",
+                "SELECT * FROM x ORDER BY a ASC",
+                "CREATE TABLE x AS (" +
+                        "SELECT" +
+                        " CAST(CASE" +
+                        "     WHEN x < 10 THEN x" +
+                        "     WHEN x >= 10 AND x < 15 THEN NULL" +
+                        "     ELSE x - 25" +
+                        " END AS DATE) AS a" +
+                        " FROM long_sequence(" + 25 + "))",

As per coding guidelines: "In SQL statements within test code, use UPPERCASE for SQL keywords".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@core/src/test/java/io/questdb/test/griffin/OrderByEncodeSortTest.java` around
lines 89 - 102, The SQL literals in OrderByEncodeSortTest.java use lowercase
keywords; update the two string literals (the query string "select * from x
order by a asc;" and the DDL passed as the second argument) to use UPPERCASE SQL
keywords (e.g., SELECT, FROM, ORDER BY, ASC, CREATE TABLE AS, CAST, CASE, WHEN,
THEN, ELSE, END, AS) while preserving identifiers, expressions and spacing so
the test behavior is unchanged.

core/src/test/java/io/questdb/test/griffin/OrderByEncodeSortFuzzTest.java (1)

43-69: Use UPPERCASE for SQL keywords in test code.

Per coding guidelines, SQL keywords should be UPPERCASE in test code. Consider updating select, case, when, then, else, end, from to their uppercase equivalents.

♻️ Suggested change

             execute(
-                    "CREATE TABLE fuzz_sort AS (SELECT" +
-                            " rnd_boolean() col_bool," +
+                    "CREATE TABLE fuzz_sort AS (SELECT " +
+                            "rnd_boolean() col_bool," +
                             ...
-                            " FROM long_sequence(" + rowCount + ")) TIMESTAMP(ts)"
+                            " FROM long_sequence(" + rowCount + ")) TIMESTAMP(ts)"

The CREATE TABLE, AS, SELECT, FROM, and TIMESTAMP keywords should remain uppercase (they already are), but ensure consistency throughout.

As per coding guidelines: "In SQL statements within test code, use UPPERCASE for SQL keywords".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@core/src/test/java/io/questdb/test/griffin/OrderByEncodeSortFuzzTest.java`
around lines 43 - 69, The SQL in OrderByEncodeSortFuzzTest uses lowercase SQL
keywords (e.g., "select", "from", "timestamp") inconsistent with project
guidelines; update the CREATE TABLE statement inside the test so all SQL
keywords are UPPERCASE (SELECT, FROM, TIMESTAMP and any other keywords like
CASE/WHEN/THEN/ELSE/END if present) while leaving function names (rnd_*), column
names, and symbols unchanged; locate the SQL string in OrderByEncodeSortFuzzTest
(the execute(...) call that creates fuzz_sort) and replace the lowercase
keywords with their uppercase equivalents for consistency.

core/src/test/java/io/questdb/test/griffin/OrderByEncodeSortTest.java (1)

125-134: Please normalize the new SQL fixtures to the test conventions.

These setup/query strings are still using lowercase keywords and manual string concatenation. Converting them to multiline strings with UPPERCASE SQL will make the new cases much easier to scan and keep consistent with the rest of the suite. As per coding guidelines "In SQL statements within test code, use UPPERCASE for SQL keywords (CREATE TABLE, INSERT, SELECT ... AS ... FROM, etc.)" and "Use multiline strings for longer statements (multiple INSERT rows, complex queries) and to assert multiline query results".

Also applies to: 172-181, 322-331, 369-378, 416-425, 463-472, 702-713, 738-749, 787-796, 834-843, 894-903

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@core/src/test/java/io/questdb/test/griffin/OrderByEncodeSortTest.java` around
lines 125 - 134, Normalize the SQL fixtures in OrderByEncodeSortTest by
replacing the concatenated lowercase strings with Java text-block multiline
strings and using UPPERCASE for SQL keywords; for example replace the query
string "select * from x order by a asc;" with a multiline text block "SELECT *
FROM x ORDER BY a ASC;" and replace the long CREATE TABLE ... AS (...)
concatenation with a single multiline text block where keywords like CREATE
TABLE, AS, SELECT, CAST, CASE, WHEN, THEN, ELSE, END, FROM are uppercased and
the expression is formatted across lines for readability. Apply this same
conversion pattern to the other occurrences called out in the review (the blocks
around lines 172-181, 322-331, 369-378, 416-425, 463-472, 702-713, 738-749,
787-796, 834-843, 894-903) so all SQL fixtures in OrderByEncodeSortTest use
multiline text blocks and UPPERCASE keywords.