[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418996#comment-13418996
]
Sylvain Lebresne commented on CASSANDRA-4448:
---------------------------------------------
bq. nobody should write raw JDBC at the app layer
I still disagree with that. Or rather, I don't care about jdbc particularly,
but I disagree that nobody should using some CQL query directly in their code.
Among other, one of the advantage of a query language is that it is very
readable. Very readable is not only good when you use cqlsh. And using queries
directly doesn't have to mean that your API is low-level. I could definitely
see some simple yet elegant and modern object mapper where you still describe
how to retrieve a given type of object using CQL queries. Such API do have some
advantages over a pycassa-like API. Not only is it hard to beat the clarity and
concision of most CQL query with a programmatic API, but it is also convenient
for debugging to be able to copy-paste your query into cqlsh to test.
Besides, even for relatively low level JDBC-like API, I'm not comfortable
saying that all the developers that uses JDBC or db-api2 directly in their app,
and there is tons of them (even if there is even more that use something else),
are misguided developers that should know better (and for SQL you cannot say
that it's just that they don't have a higher level API available yet).
But another important point is that I think adding this has close to no
downside. It's a few trivial lines of codes, it has no performance impact. And
it hardly complicate the language in a measurable way since 1) those are just
new options of the create table, not some new complex syntactic construction
and 2) these options have self-documented and have a straightforward semantic.
Users that don't care about those options and happen to find them in the doc
will just move along and never use them, no harm done. But I am convinced that
for at least some users their existence will be convenient (*I* would find it
convenient, and having a pycassa-for-java-over-cql wouldn't change that).
bq. But you create CF objects exactly once and then import them elsewhere
What I meant here is that you create a table exactly once, oftentimes not even
in application code. So I believe many people would find it more convenient to
define the default CL that make the most sense for that table at creation,
rather than in all application code that access the table. And there can be
more than one such code, if only because a lot of people need to access their
DB from multiple languages.
I'm not pretending this is a killer feature. But I do am saying that it will be
convenient for at least some users and adding it costs us pretty much nothing.
> CQL3: allow to define a per-cf default consistency level
> --------------------------------------------------------
>
> Key: CASSANDRA-4448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4448
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Sylvain Lebresne
> Labels: cql3
> Fix For: 1.2
>
>
> One of the goal of CQL3 is that client library should not have to parse
> queries to provide a good experience. In particular, that means such client
> (that don't want to parse queries) won't be able to allow the user to define
> a specific default read/write consistency level per-CF, forcing user to
> specific the consistency level with every query, which is not very user
> friendly.
> This ticket suggests the addition of per-cf default read/write consitency
> level. Typically the syntax would be:
> {noformat}
> CREATE TABLE foo (...)
> WITH DEFAULT_READ_CONSISTENCY = QUORUM
> AND DEFAULT_WRITE_CONSISTENCY = QUORUM
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
