clintropolis commented on code in PR #18262:
URL: https://github.com/apache/druid/pull/18262#discussion_r2220028735
##########
processing/src/test/java/org/apache/druid/segment/CursorFactoryProjectionTest.java:
##########
@@ -1343,6 +1351,61 @@ public void
testProjectionSelectionMissingColumnOnBaseTableToo()
Assert.assertArrayEquals(new Object[]{"b", null, 12L, 13.2},
results.get(1).getArray());
}
+ @Test
+ public void testTimeseriesQueryAllGranularityCanMatchNonTimeDimProjection()
Review Comment:
it would be nice to have a test for a timeseries query that doesn't match a
projection and also doesn't expect any sort of failure (but still runs against
a non-time ordered segment since there isn't any coverage for that in
`TimeseriesQueryRunnerTest`).
##########
processing/src/test/java/org/apache/druid/segment/CursorFactoryProjectionTest.java:
##########
@@ -1343,6 +1351,61 @@ public void
testProjectionSelectionMissingColumnOnBaseTableToo()
Assert.assertArrayEquals(new Object[]{"b", null, 12L, 13.2},
results.get(1).getArray());
}
+ @Test
+ public void testTimeseriesQueryAllGranularityCanMatchNonTimeDimProjection()
+ {
+ final TimeseriesQuery query = Druids.newTimeseriesQueryBuilder()
+ .dataSource("test")
+
.intervals(ImmutableList.of(Intervals.ETERNITY))
+ .granularity(Granularities.ALL)
+ .aggregators(new
LongSumAggregatorFactory("c_sum", "c"))
+
.context(ImmutableMap.of(QueryContexts.USE_PROJECTION, "b_c_sum"))
+ .build();
+
+ final CursorBuildSpec buildSpec =
TimeseriesQueryEngine.makeCursorBuildSpec(query, null);
+ try (final CursorHolder cursorHolder =
projectionsCursorFactory.makeCursorHolder(buildSpec)) {
+ final Cursor cursor = cursorHolder.asCursor();
+ int rowCount = 0;
+ while (!cursor.isDone()) {
+ rowCount++;
+ cursor.advance();
+ }
+ Assert.assertEquals(4, rowCount);
+ }
+
+ final Sequence<Result<TimeseriesResultValue>> resultRows =
timeseriesEngine.process(
+ query,
+ projectionsCursorFactory,
+ projectionsTimeBoundaryInspector,
+ null
+ );
+
+ final List<Result<TimeseriesResultValue>> results = resultRows.toList();
+ Assert.assertEquals(1, results.size());
+ final RowSignature querySignature =
query.getResultRowSignature(RowSignature.Finalization.YES);
+ Assert.assertArrayEquals(new Object[]{TIMESTAMP, 19L},
getResultArray(results.get(0), querySignature));
+ }
+
+ @Test
+ public void testTimeseriesQueryOrderByNotCompatibleWithProjection()
+ {
+ final TimeseriesQuery query = Druids.newTimeseriesQueryBuilder()
+ .dataSource("test")
+
.intervals(ImmutableList.of(Intervals.ETERNITY))
+ .granularity(Granularities.DAY)
+ .descending(true)
+ .aggregators(new
LongSumAggregatorFactory("c_sum", "c"))
+
.context(ImmutableMap.of(QueryContexts.USE_PROJECTION, "c_sum_daily"))
+ .build();
+
+ final CursorBuildSpec buildSpec =
TimeseriesQueryEngine.makeCursorBuildSpec(query, null);
+ DruidException e = Assert.assertThrows(
+ DruidException.class,
+ () -> projectionsCursorFactory.makeCursorHolder(buildSpec));
+ Assert.assertEquals(DruidException.Category.INVALID_INPUT,
e.getCategory());
+ Assert.assertEquals("Projection[c_sum_daily] specified, but does not
satisfy query", e.getMessage());
Review Comment:
This is the reason why I don't think we should have made that change in
`AggregateProjectionSpec` - why shouldn't this be allowed? The segment
projection has the same granularity as the query, so it should produce the same
results, does it not for some reason?
##########
processing/src/main/java/org/apache/druid/data/input/impl/AggregateProjectionSpec.java:
##########
@@ -175,8 +174,8 @@ public String toString()
private static ProjectionOrdering computeOrdering(VirtualColumns
virtualColumns, List<DimensionSchema> groupingColumns)
{
if (groupingColumns.isEmpty()) {
- // call it time ordered, there is no grouping columns so there is only 1
row for this projection
- return new ProjectionOrdering(Cursors.ascendingTimeOrder(), null);
+ // no ordering since there is only 1 row for this projection
+ return new ProjectionOrdering(List.of(), null);
Review Comment:
why this change? This is effectively time ordered within the constraints of
the segment granularity, it should still be able to participate in time order
required queries (like when the query granularity is equal to the segment
granularity)
--
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]