Thanks for reporting and confirming the issue.
I was able to reproduce it without problems.
I have open https://issues.apache.org/jira/browse/CASSANDRA-11208
I will have a quick look at it tomorrow.
Benjamin
On Mon, Feb 22, 2016 at 4:10 PM, Andres de la Peña <adelap...@stratio.com>
wrote:
> Hi,
>
> I have found the same problem. It seems that it happens when the fetch size
> is greater than or equals to the number of returned rows. The problem is
> that the first row of each page is the last row of the previous page. It
> can also be easily reproduced with cqlsh:
>
> CREATE KEYSPACE test with replication = {'class' : 'SimpleStrategy',
> 'replication_factor' : '1' };
> USE test;
> CREATE TABLE test (rc int, pk int, PRIMARY KEY ((pk)));
> INSERT INTO test (pk, rc) VALUES (1, 1);
> INSERT INTO test (pk, rc) VALUES (2, 2);
> INSERT INTO test (pk, rc) VALUES (3, 3);
> INSERT INTO test (pk, rc) VALUES (4, 4);
> INSERT INTO test (pk, rc) VALUES (5, 5);
> INSERT INTO test (pk, rc) VALUES (6, 6);
> PAGING 4;
> SELECT * FROM test WHERE pk IN (1, 2, 3); -- Ok
> PAGING 3;
> SELECT * FROM test WHERE pk IN (1, 2, 3); -- Wrong
> PAGING 2;
> SELECT * FROM test WHERE pk IN (1, 2, 3); -- Wrong
>
> The output of the last query is:
>
> pk | rc
> ----+----
> 1 | 1
> 2 | 2
>
> ---MORE---
> pk | rc
> ----+----
> 2 | 2
> 3 | 3
>
> ---MORE---
> pk | rc
> ----+----
> 3 | 3
>
> Regards,
>
> 2016-02-22 8:54 GMT+00:00 Benjamin Lerer <benjamin.le...@datastax.com>:
>
> > Thanks for reporting the problem.
> > I will look into it.
> >
> > Regards,
> >
> > Benjamin
> >
> > On Sun, Feb 21, 2016 at 3:19 PM, Luis Ángel Vicente Sánchez <
> > langel.gro...@gmail.com> wrote:
> >
> > > I think I have found an issue when you have a simple column family
> with a
> > > simple primary key (no clustering keys) and you use the IN clause. This
> > > problem only happens with Cassandra 3.x, in Cassandra 2.x works just
> > fine.
> > >
> > > You can reproduce this issue by checking out this project:
> > >
> > > https://github.com/lvicentesanchez/cassandra-3.x-error
> > >
> > > It's written in Scala but I have provided instructions on how to run
> the
> > > program.
> > >
> > > I will copy here the content of README.md where I explain the problem:
> > >
> > > # cassandra-3.x-error #
> > >
> > > This repository reproduces an error in Cassandra 3.x when the fetch
> size
> > is
> > > smaller than the number of rows in a column family. For the shake of
> this
> > > demo, fetch size would be 2 and the number of rows 3.
> > >
> > > ## Pre-steps ##
> > >
> > > 1. Use `src/main/cql/script.cql` to create the key space and column
> > > families.
> > > 2. Modify contact point and port in
> > `src/main/scala/CassandraError.scala`.
> > > 3. Modify contact point and port in `src/main/scala/CassandraOk.scala`.
> > > 4. Open `sbt` by executing `./sbt` in the root of the project.
> > >
> > > ## Error ##
> > >
> > > Execute `runMain CassandraError`. We would get this in our terminal:
> > >
> > > ```
> > > [info] Measure(1,11)
> > > [info] Measure(2,7)
> > > [info] Measure(2,7)
> > > [info] Measure(3,23)
> > > [info] Measure(3,23)
> > > ```
> > >
> > > If we run the same program against Cassandra 2.x, we would get this:
> > >
> > > ```
> > > [info] Measure(1,11)
> > > [info] Measure(2,7)
> > > [info] Measure(3,23)
> > > ```
> > >
> > > We were expecting Cassandra 3.x to produce the same output as Cassandra
> > > 2.x. It seems that there is an issue with simple primary keys,
> pagination
> > > and the IN clause.
> > >
> > > ## Ok ##
> > >
> > > Execute `runMain CassandraOk`. Whether we ran it against Cassandra 2.x
> or
> > > Cassandra 3.x, we would get this in our terminal:
> > >
> > > ```
> > > [info] Measure(1,0,11)
> > > [info] Measure(2,0,7)
> > > [info] Measure(3,0,23)
> > > ```
> > >
> > > Should I create an issue?
> > >
> > > Regards,
> > >
> > > Luis
> > >
> >
>
>
>
> --
> Andrés de la Peña
>
> Vía de las dos Castillas, 33, Ática 4, 3ª Planta
> 28224 Pozuelo de Alarcón, Madrid
> Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd
> <https://twitter.com/StratioBD>*
>
