[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14153350#comment-14153350
]
Sylvain Lebresne commented on CASSANDRA-8005:
---------------------------------------------
bq. I'm suggesting augmenting it
Ok, gotcha. I read "Get closer to allowing drivers to not have to fetch the
schema tables" as "remove from existing drivers the need to read schema table"
and that's definitively my bad.
I'm still not convinced this is worth adding though. As I said, for serious
drivers that do read schema tables to provide programmatically friendly access
to the schema, adding a proper {{toString()}} is very little trouble (and it's
imo simpler/better for these driver to just regenerate the string from their
internal handling of the schema rather than to do an additional request to the
server). So this would be presumably useful for drivers that don't want to
provide programmatic access to the schema, but still want to dump it as string?
Honestly, I'd rather encourage drivers author to provide programmatic access to
the schema (and subsequantly to ouptut this schema as a string): provided we
make decoding schema table less of a back art (aka CASSANDRA-6717), I don't
think it's a big deal and it's more user friendly.
bq. I still think the other three points need to be addressed.
bq. Get closer to allowing drivers to not have to fetch the schema tables
To sum what's above, provided we have CASSANDRA-6717, I don't think fetching
schema tables is a big deal and I'm fine having that as a requirement for a
driver that want to output schemas.
bq. Support writing out schemas where it makes sense.
I don't see how this is better done by this feature than by the existing
{{KeyspaceMetadata.exportAsString}} method the java driver already provided.
bq. Have instantaneous support for new schema features in cqlsh. (You currently
have to update the bundled python driver.)
That's the one point I'll admit would be better served by an opaque string
returned by the server. That said, I do think there is value in having drivers
provide programmatic acces to schemas, and as soon as you have that, you do
have to adapt to new stuff that are added server side. So granted, if used by
cqlsh this feature would avoid having to wait for the python driver to be
updated, but since the python driver will have to be updated at some point
anyway, I'm not sold that this point warrant a new protocol feature.
> Server-side DESCRIBE
> --------------------
>
> Key: CASSANDRA-8005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8005
> Project: Cassandra
> Issue Type: New Feature
> Components: API
> Reporter: Tyler Hobbs
> Priority: Minor
> Labels: cql3
> Fix For: 3.0
>
>
> The various {{DESCRIBE}} commands are currently implemented by cqlsh, and
> nearly identical implementations exist in many drivers. There are several
> motivations for making {{DESCRIBE}} part of the CQL language:
> * Eliminate the (fairly complex) duplicate implementations across drivers and
> cqlsh
> * Get closer to allowing drivers to not have to fetch the schema tables.
> (Minor changes to prepared statements are also needed.)
> * Have instantaneous support for new schema features in cqlsh. (You
> currently have to update the bundled python driver.)
> * Support writing out schemas where it makes sense. One good example of this
> is backups. You need to restore the schema before restoring data in the case
> of total loss, so it makes sense to write out the schema alongside snapshots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
