CASSANDRA-5376: CQL IN clause on last key not working when schema includes set,list or map
Hi, "CASSANDRA-5376: CQL IN clause on last key not working when schema includes set,list or map" is marked resolved in 1.2.4 but i still see the issue (not an Assertion Error, but an query validation message) was the issue resolved only to report proper error message or was it fixed to support retrieving collections when query contains IN clause of partition/cluster (last) columns? If it was fixed properly to support retrieving collections with IN clause, then is it a bug in 3.7 release that i get the same message? Could you please explain, if it not fixed as intended, if there are plans to support this in future? Thanks & Regards, Samba
Re: CASSANDRA-5376: CQL IN clause on last key not working when schema includes set,list or map
any update on this issue? the quoted JIRA issue (CASSANDRA-5376) is resolved as fixed in 1.2.4 but it is still not possible (even in 3.7) to use IN operator in queries that fetch collection columns. is the fix only to report better error message that this is not possible or was it fixed then but the issue resurfaced in regression? could you please confirm one way or the other? Thanks and Regards, Samba On Tue, Sep 6, 2016 at 6:34 PM, Samba wrote: > Hi, > > "CASSANDRA-5376: CQL IN clause on last key not working when schema > includes set,list or map" > > is marked resolved in 1.2.4 but i still see the issue (not an Assertion > Error, but an query validation message) > > was the issue resolved only to report proper error message or was it fixed > to support retrieving collections when query contains IN clause of > partition/cluster (last) columns? > > If it was fixed properly to support retrieving collections with IN clause, > then is it a bug in 3.7 release that i get the same message? > > Could you please explain, if it not fixed as intended, if there are plans > to support this in future? > > Thanks & Regards, > Samba >
Re: CASSANDRA-5376: CQL IN clause on last key not working when schema includes set,list or map
Thanks Tyler, for identifying that this can be fixed now. Here is the JIRA ticket : CASSANDRA-12654 : If this is just removing the now obsolete check, then I hope this makes to 3.10 release. Regards, Samba On Fri, Sep 16, 2016 at 1:33 AM, Tyler Hobbs wrote: > That ticket was just to improve the error message. From the comments on > the ticket: > > "Unfortunately, handling collections is slightly harder than what > CASSANDRA-5230 <https://issues.apache.org/jira/browse/CASSANDRA-5230> > aimed for, because we can't do a name query. So this will have to wait for > CASSANDRA-4762 <https://issues.apache.org/jira/browse/CASSANDRA-4762>. In > the meantime, we should obviously not throw an assertion error so attaching > a patch to improve validation." > > However, it seems like this would be possible to support in Cassandra > 3.x. We probably just need to remove the check and verify that it actually > works. Can you open a new JIRA ticket for this? > > On Thu, Sep 15, 2016 at 12:49 PM, Samba wrote: > >> any update on this issue? >> >> the quoted JIRA issue (CASSANDRA-5376) is resolved as fixed in 1.2.4 but >> it is still not possible (even in 3.7) to use IN operator in queries that >> fetch collection columns. >> >> is the fix only to report better error message that this is not possible >> or was it fixed then but the issue resurfaced in regression? >> >> could you please confirm one way or the other? >> >> Thanks and Regards, >> Samba >> >> >> On Tue, Sep 6, 2016 at 6:34 PM, Samba wrote: >> >>> Hi, >>> >>> "CASSANDRA-5376: CQL IN clause on last key not working when schema >>> includes set,list or map" >>> >>> is marked resolved in 1.2.4 but i still see the issue (not an Assertion >>> Error, but an query validation message) >>> >>> was the issue resolved only to report proper error message or was it >>> fixed to support retrieving collections when query contains IN clause of >>> partition/cluster (last) columns? >>> >>> If it was fixed properly to support retrieving collections with IN >>> clause, then is it a bug in 3.7 release that i get the same message? >>> >>> Could you please explain, if it not fixed as intended, if there are >>> plans to support this in future? >>> >>> Thanks & Regards, >>> Samba >>> >> >> > > > -- > Tyler Hobbs > DataStax <http://datastax.com/> >
Re: Cannot restrict clustering columns by IN relations when a collection is selected by the query
please see CASSANDRA-12654
On Sat, Oct 22, 2016 at 3:12 AM, DuyHai Doan wrote:
> So the commit on this restriction dates back to 2.2.0 (CASSANDRA-7981).
>
> Maybe Benjamin Lerer can shed some light on it.
>
> On Fri, Oct 21, 2016 at 11:05 PM, Jeff Carpenter <
> jeff.carpen...@choicehotels.com> wrote:
>
>> Hello
>>
>> Consider the following schema:
>>
>> CREATE TABLE rates_by_code (
>> hotel_id text,
>> rate_code text,
>> rates set,
>> description text,
>> PRIMARY KEY ((hotel_id), rate_code)
>> );
>>
>> When executing the query:
>>
>> select rates from rates_by_code where hotel_id='AZ123' and rate_code IN
>> ('ABC', 'DEF', 'GHI');
>>
>> I receive the response message:
>>
>> Cannot restrict clustering columns by IN relations when a collection is
>> selected by the query.
>>
>> If I select a non-collection column such as "description", no error
>> occurs.
>>
>> Why does this restriction exist? Is this a restriction that is still
>> necessary given the new storage engine? (I have verified this on both 2.2.5
>> and 3.0.9.)
>>
>> I looked for a Jira issue related to this topic, but nothing obvious
>> popped up. I'd be happy to create one, though.
>>
>> Thanks
>> Jeff Carpenter
>>
>>
>>
>>
>
Multi Master replication : rejoining a node after split network
Hi all, We are evaluating Cassandra for a geographically distributed deployment that requires multi master replication. We have a few questions regarding how replication is handled in Cassandra, like: 1. Which mechanism is used to replicate the changes from one system to another: statement distribution or recording the changeset via triggers or storing the changeset in transaction log? 2. Since replication is continuous copying of changes from one node to another, these changes would have to be snapshotted in order to sustain temporary network failures so that replication can resume after the network problem is healed. is there a mechanism to define how long we can store/archive the snaphotted changes before we discard and would demand a recreation of node from the scratch rather than rejoin 3. What options are available for conflict resolution since we are talking about master-master replication across tens of nodes? 4. If a node is rejoined after a split network where same records would have been modified on multiple nodes, is there a mechanism to merge the data, resolve conflicts and eventually reach to a consistent state? Thanks and Regards, Samba
Re: Multi Master replication : rejoining a node after split network
Thanks Aaron and Romain, very useful information indeed; and yes there is no alternative to personally trying out and dirtying our hands. Regards, Samba
