[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16453748#comment-16453748
]
Benjamin Lerer edited comment on CASSANDRA-7622 at 4/26/18 10:45 AM:
---------------------------------------------------------------------
{quote}I don't think I see the benefit to that schema, you have to have a
schema change or dynamic schema for whenever a new metric is added?
{quote}
At the end of the day you have 2 alternatives. Either you expect the users to
know the type of every metric and face a big bunch of {{NULL}} values for some
queries or you follow the approach that the database industry has chosen which
could result in a schema change with new versions.
There are no perfect solutions.
Relational database users have lived with the second alternative for years, are
used to it. In my opinion is also the more user friendly option.
Now, in the case of the table metrics it might make sense to split them in
sub-group like: storage, access, compaction and repair.
{quote}Reminder there have been cases where metrics dont appear until execution
(not currently but in past), so its not unheard of for the metric set to change
at runtime.
{quote}
That is a bug and should not impact the design.
{quote}
And requiring {{EXPAND ON;}} to explore what metrics exist I think would be a
high bar for a lot of people who don't even know the command exists, which is
also session wide not just for the query.{quote}
It is a really useful feature. There are a lot of case where your results do
not fit the display. Maybe we should simply advertise it more.
We should also change CQLSH to support it a the query level like the *\G* of
the MySQL console.
was (Author: blerer):
{quote}I don't think I see the benefit to that schema, you have to have a
schema change or dynamic schema for whenever a new metric is added?
{quote}
At the end of the day you have 2 alternatives. Either you expect the users to
know the type of every metric and face a big bunch of {{NULL}} values for some
queries or you follow the approach that the database industry has chosen which
could result in a schema change with new versions.
There are no perfect solutions.
Relational database users have lived with the second alternative for years, are
used to it. In my opinion is also the more user friendly option.
Now, in the case of the table metrics it might make sense to split them in
sub-group like: storage, access, compaction and repair.
{quote}Reminder there have been cases where metrics dont appear until execution
(not currently but in past), so its not unheard of for the metric set to change
at runtime.
{quote}
That is a bug and should not impact the design.
And requiring {{EXPAND ON;}} to explore what metrics exist I think would be a
high bar for a lot of people who don't even know the command exists, which is
also session wide not just for the query.\{quote}
It is a really useful feature. There are a lot of case where your results do
not fit the display. Maybe we should simply advertise it more.
We should also change CQLSH to support it a the query level like the *\G* of
the MySQL console.
> Implement virtual tables
> ------------------------
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
> Reporter: Tupshin Harper
> Assignee: Chris Lohfink
> Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any
> table that would be backed by an API, rather than data explicitly managed and
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml
> configuration information. So it would be an alternate approach to
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not
> presupposing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
