paul-rogers commented on issue #11659:
URL: https://github.com/apache/druid/issues/11659#issuecomment-913239896
@FrankChen021, thanks for the explanation. I guess my response is more
philosophical than technical.
Druid claims to support SQL, and SQL is a standard. Supporting SQL means
supporting the standard with, of course, the subtle adjustments and variations
needed for each system. The standard was created as an aggregation of many use
cases: the standard reviewed and supported those use cases so that each vendor
doesn't have to repeat that process. And, as a user, if Druid claims to support
SQL, then I should be able to use my knowledge of SQL with Druid without having
to justify each SQL feature I might want to use.
Of course, Druid need not support SQL. Some tools offer a "Whatever Query
Language", such as a "Druid Query Language" (DQL) which is SQL-like, but picks
and chooses which features to support. It confusing for Druid to use the "SQL"
term for its "DQL", if the language isn't really SQL. As I said, this is
philosophical; we won't resolve it here.
In my case, segments are listed in Druid's own `segments` table using string
timestamps. I want to run a single query that finds the range of (published)
data for a table. This should be easy to do with standard SQL:
```sql
SELECT
MIN("start") AS "earliestData",
MAX("end") AS "latestData"
FROM sys.segments
WHERE datasource = 'whatever'
AND is_published = 1
AND is_overshadowed = 0
```
SQL is designed to allow such queries. Having contributed to a couple of
query engines, I've seen that the `MIN` and `MAX` "aggregate" functions are not
hard to implement (I won't say "easy" because nothing in a query engine is
easy).
From the user perspective, it should not matter what "kind" of column I use
(dimension or metric). In fact, here, it is Druid itself that chose how to
represent the columns. (In the `sys` tables, does it even make sense to ask
which columns are metrics and which are dimensions? How would I even know?)
Maybe the problem has to do with the special way that Druid handles the
`sys` tables? Maybe they are not "really" tables? Maybe some documentation
would help to say that "here is a list of Druid SQL features not supported in
system tables..."
--
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]
