[
https://issues.apache.org/jira/browse/CASSANDRA-14345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duarte Nunes updated CASSANDRA-14345:
-------------------------------------
Description:
Given the following table:
{code:java}
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
{code}
The following fails:
{code:java}
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
However, MVs don't appear to have this restriction:
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
{code:java}
v | p | c
---+---+---
| a | 2
{code}
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
{code:java}
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
was:
Given the following table:
{code:java}
cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
'replication_factor': 1};
cqlsh> create table t (p text, c int, v text, primary key (p));
cqlsh> use ks;
{code}
The following fails:
{code:java}
cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be empty"{code}
However, MVs don't appear to have this restriction:
create materialized view mv as select * from t where v is not null and p is not
null and c is not null primary key (v, p);
insert into t (p, c, v) values ('a', 2, '');
select * from mv;
{code:java}
v | p | c
---+---+---
| a | 2
{code}
I guess this is because an empty value can't be distinguished from null at the
protocol level, but this distinction can be made internally.
I think the behavior should be made consistent, if nothing else because
querying the MV for the empty key is impossible:
{code:java}
cqlsh:ks> select * from mv where v = '';
InvalidRequest: Error from server: code=2200 [Invalid query] message="Key may
not be
empty"{code}
> Empty partition keys allowed in MV, but not in normal table
> -----------------------------------------------------------
>
> Key: CASSANDRA-14345
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14345
> Project: Cassandra
> Issue Type: Bug
> Components: Materialized Views
> Reporter: Duarte Nunes
> Priority: Major
> Labels: materializedviews
>
> Given the following table:
>
> {code:java}
> cqlsh> create keyspace ks WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': 1};
> cqlsh> create table t (p text, c int, v text, primary key (p));
> cqlsh> use ks;
> {code}
> The following fails:
> {code:java}
> cqlsh:ks> insert into t (p, c, v) values ('', 2, '');
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
> However, MVs don't appear to have this restriction:
> create materialized view mv as select * from t where v is not null and p is
> not
> null and c is not null primary key (v, p);
> insert into t (p, c, v) values ('a', 2, '');
> select * from mv;
> {code:java}
> v | p | c
> ---+---+---
> | a | 2
> {code}
> I guess this is because an empty value can't be distinguished from null at
> the protocol level, but this distinction can be made internally.
> I think the behavior should be made consistent, if nothing else because
> querying the MV for the empty key is impossible:
> {code:java}
> cqlsh:ks> select * from mv where v = '';
> InvalidRequest: Error from server: code=2200 [Invalid query] message="Key
> may not be empty"{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
