Micha,

I did not had the time to look into your problem yet.
Could you open a JIRA ticket to be sure that we do not forget about this
problem? I will look into it as soon as I can.

On Mon, Jan 30, 2017 at 5:12 PM, Benjamin Lerer <benjamin.le...@datastax.com
> wrote:

> I do not see why you should get that problem with a replication factor of
> 2.
> I will look into it.
>
> On Mon, Jan 30, 2017 at 5:06 PM, Micha <mich...@fantasymail.de> wrote:
>
>> OK, thanks, that was good!
>>
>> You have allocated the keyspace with replication factor 3. If I do this
>> it works on my cluster too!
>>
>> If I try this in a new keyspace with replication factor 2 I get the same
>> result as before, nearly at least, this time 58 rows.
>>
>> I can reproduce this: 3-node cluster and replication factor 3 -> it works
>> 3-node cluster and replication factor 2 (or 1) -> wrong result.
>>
>>
>> Are there restrictions on the replication factor?  Does this matter as
>> the index is stored locally (as I have read)?
>>
>> I did use cqlsh and also get the same result when using the java api.
>>
>> Thanks for helping,
>>  Michael
>>
>>
>> On 30.01.2017 16:50, Benjamin Lerer wrote:
>> > So, far I do not have any sucess in trying to reproduce the problem.
>> > I created a 3 node clusters using 3.9  with ccm and used CQLSH to
>> reproduce
>> > the problem but I only got back one row:
>> >
>> > cqlsh> create KEYSPACE test WITH replication = {'class':
>> 'SimpleStrategy',
>> > 'replication_factor': 3};
>> > cqlsh> use test;
>> > cqlsh:test> create table demo (id text, id2 bigint static, added
>> timestamp,
>> > source
>> >         ... text static, dest text, primary key (id, added));
>> > cqlsh:test> create index on demo (id2);
>> > cqlsh:test> insert into demo (id, id2, added, source, dest) values
>> ('id1',
>> > 22,
>> >         ... '2017-01-28', 'src1', 'dst1');
>> > cqlsh:test> select * from demo where id2=22;
>> >
>> >  id  | added                           | id2 | source | dest
>> > -----+---------------------------------+-----+--------+------
>> >  id1 | 2017-01-27 23:00:00.000000+0000 |  22 |   src1 | dst1
>> >
>> > (1 rows)
>> > cqlsh:test>
>> >
>> > Did you use CQLSH to reproduce the problem or another client?
>> >
>> >
>>
>
>

Reply via email to