[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840985#comment-13840985
]
Jonathan Ellis commented on CASSANDRA-4448:
---
This was removed in CASSANDRA-4734, between 1.2.0b1 and 1.2.0b2. So not only
was this not removed in 1.2.10 but it was never included in 1.2.0-final.
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
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0 beta 1
Attachments: 4448.txt
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 was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13840997#comment-13840997
]
David Webb commented on CASSANDRA-4448:
---
Here is a schema from DSE 3.1.3 / C* 1.2.6.6 that includes them. This is just
to let you know that I think they did sneak in there for a while. Some tools
like the Pentaho Cassandra connector were depending on their existence, and it
appears the were removed somewhere between 1.2.8 and 1.2.10. I cannot tell for
sure. Thanks for shedding light on the situation and we will proceed as if
they will not exists ever again. :) The connector will be updated soon. Thanks
Jonathan.
{code}
[cqlsh 3.1.2 | Cassandra 1.2.6.6 | CQL spec 3.0.0 | Thrift protocol 19.36.0]
Use HELP for help.
cqlsh use system
... ;
cqlsh:system describe table schema_columnfamilies;
CREATE TABLE schema_columnfamilies (
keyspace_name text,
columnfamily_name text,
bloom_filter_fp_chance double,
caching text,
column_aliases text,
comment text,
compaction_strategy_class text,
compaction_strategy_options text,
comparator text,
compression_parameters text,
default_read_consistency text,
default_validator text,
default_write_consistency text,
gc_grace_seconds int,
id int,
key_alias text,
key_aliases text,
key_validator text,
local_read_repair_chance double,
max_compaction_threshold int,
min_compaction_threshold int,
populate_io_cache_on_flush boolean,
read_repair_chance double,
replicate_on_write boolean,
subcomparator text,
type text,
value_alias text,
PRIMARY KEY (keyspace_name, columnfamily_name)
) WITH
bloom_filter_fp_chance=0.01 AND
caching='KEYS_ONLY' AND
comment='ColumnFamily definitions' AND
dclocal_read_repair_chance=0.00 AND
gc_grace_seconds=8640 AND
read_repair_chance=0.00 AND
replicate_on_write='true' AND
populate_io_cache_on_flush='false' AND
compaction={'class': 'SizeTieredCompactionStrategy'} AND
compression={'sstable_compression': 'SnappyCompressor'};
{code}
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
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0 beta 1
Attachments: 4448.txt
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 was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841007#comment-13841007
]
Jonathan Ellis commented on CASSANDRA-4448:
---
If you upgraded from 1.2.0b1, we didn't bother ripping them out.
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
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0 beta 1
Attachments: 4448.txt
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 was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13841010#comment-13841010
]
Jonathan Ellis commented on CASSANDRA-4448:
---
Ah, I see -- the actual columns weren't removed until cb0a0cd this August. But
they've been doing absolutely nothing in the meantime.
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
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0 beta 1
Attachments: 4448.txt
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 was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454942#comment-13454942
]
Sylvain Lebresne commented on CASSANDRA-4448:
-
The thing is, I don't think this option is of any use for thrift, since the
consistency level is not optional in the thrift calls. In fact this would ask
special support for the thrift client to not screw up the setting. So it sound
simpler to me to not expose it at all on the thrift side.
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
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0
Attachments: 4448.txt
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454945#comment-13454945
]
Jonathan Ellis commented on CASSANDRA-4448:
---
bq. the consistency level is not optional in the thrift calls
Good point. +1 from me.
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
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0
Attachments: 4448.txt
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454303#comment-13454303
]
Yuki Morishita commented on CASSANDRA-4448:
---
Patch lgtm, +1.
I just note that these two CF params are first ones that only available through
CQL3.
No thrift CfDef definition and no CQL2 CFPropDefs definition.
But this should be fine since CQL3 is going to be default from 1.2.
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
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0
Attachments: 4448.txt
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13454449#comment-13454449
]
Jonathan Ellis commented on CASSANDRA-4448:
---
Should probably include in CfDef :(
CQL2 doesn't need it though.
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
Assignee: Sylvain Lebresne
Labels: cql3
Fix For: 1.2.0
Attachments: 4448.txt
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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13419037#comment-13419037
]
Michaël Figuière commented on CASSANDRA-4448:
-
{quote}If you're writing application code, you should not be writing raw CQL;
you should be using a higher-level, idiomatic API{quote}
Hibernate let users execute queries using either their their own SQL-ish query
language (HQL) or their QueryBuilder API (Criteria). Actually as far as I can
observe, most heavy-weight business applications that rely on Hibernate to
execute many different kind of queries typically mostly use HQL as a proper
String query often ends up being more readable and easier to maintain than a
chain of methods. This different case might lead to different habits, but we
should still consider CQL Language as a major API for applications.
{quote}There can be more than one such code, if only because a lot of people
need to access their DB from multiple languages.{quote}
I think this is an important point: this feature allow for a central
enforcement point for CL for applications that rely on default, thus
simplifying the headache of changing the common CL.
Furthermore I guess some users will wish to decouple their application from CL
configuration to allow them for some behavior or performance tuning over time.
Typically I can imagine a DBA that want to trade some consistency for
performance as a graceful degradation strategy will be happy to just have to
push an {{ALTER}} command.
Not having it I guess many developers would follow the
_parameterize-it-just-in-case_ strategy and this would lead to some additional
properties in their {{.properties}} files, in the case of Java apps.
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
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418370#comment-13418370
]
Jonathan Ellis commented on CASSANDRA-4448:
---
If you're playing with cqlsh, on the rare occasions that you need to specify CL
doing so manually is not a big deal. But if you're writing application code,
you should not be writing raw CQL; you should be using a higher-level,
idiomatic API (such as the one pycassa provides), which can generate CQL
specifying CL with no work on your part.
Granted, such higher-level APIs do not yet exist for CQL, but I think this is a
misfeature given that we will get to that point in the next few months.
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
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418406#comment-13418406
]
Sylvain Lebresne commented on CASSANDRA-4448:
-
bq. But if you're writing application code, you should not be writing raw CQL
I don't know, I don't think we should be the judge of that. If you are using a
jdbc like driver, it makes perfect sense in my opinion to have most of your
query being hardcoded prepared statements and maybe a few
'stmt.executeQuery(SELECT * FROM Users)' here and there, because after all,
that's fairly clean.
That is, I'm not pretending that everyone should do it this way, but I very
much dislike the idea of forcing people to have a pycassa like API to have a
decent experience. Especially considering that adding those default
consistencies setting per-cf is fairly straightforward.
On top of that, I actually think that even for pycassa-like API it makes sense.
I think that more often than not, tables have a natural default consistency
settings (which doesn't mean no query will overwrite it btw), and so I think it
is more convenient to set that once at the table creation rather that having to
call setReadConsistencyLevel() and setWriteConsistencyLevel() every time you
create your ColumnFamily object in the application code.
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
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418439#comment-13418439
]
Rick Shaw commented on CASSANDRA-4448:
--
I understand Jonathan's point, but I agree with Sylvain at least in the JDBC
case. It is especially true for a client like JDBC which really is not designed
to have any DB specific controls. It relies on the DBs implementation of
feature extensions in the script (CQL in this case). We are kinda stuck with
the design of the existing interfaces which would not offer much leeway in this
case.
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
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418442#comment-13418442
]
Jonathan Ellis commented on CASSANDRA-4448:
---
bq. It is especially true for a client like JDBC which really is not designed
to have any DB specific controls
Modern Java apps use JDBC as a low-level driver. Nobody writes raw JDBC code
at the app layer.
bq. I think it is more convenient to set that once at the table creation rather
that having to call setReadConsistencyLevel() and setWriteConsistencyLevel()
every time you create your ColumnFamily object in the application code
But you create CF objects exactly once and then import them elsewhere.
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
[jira] [Commented] (CASSANDRA-4448) CQL3: allow to define a per-cf default consistency level
[
https://issues.apache.org/jira/browse/CASSANDRA-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13418702#comment-13418702
]
Colin Taylor commented on CASSANDRA-4448:
-
{quote}
Modern Java apps use JDBC as a low-level driver. Nobody writes raw JDBC code at
the app layer.
{quote}
364,000 google results for stackoverflow jdbc suggests otherwise. Sure most
don't, but the statement that nobody does is completely false. There are many
recovering Hibernate users rehabilitating themselves using JDBC for a start.
Similarly CQL seems to be a welcome relief from Hector frankly:
final HColumnComposite, ByteBuffer logColumn = new
HColumnImplComposite, ByteBuffer(new CompositeSerializer(), new
ByteBufferSerializer());
Hmm.. pretty. Furthermore we know CQL will track trunk fairly closely so we can
test new features.
Why don't we ask the list if they want/expect to write CQL?
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
