Thanks Robert, but I don’t insert NULL values, but thanks anyway.
On 15 Jun 2015, at 19:16 , Robert Wille
mailto:rwi...@fold3.com>> wrote:
You can get tombstones from inserting null values. Not sure if that’s the
problem, but it is another way of getting tombstones in your data.
On Jun 15, 201
Thanks Bryan.
I believe I have a different problem with the Datastax 2.1.6 driver.
My problem is not that I make huge selects.
My problem seems more to occur on some inserts. I inserts MANY rows and with
the version 2.1.6 of the driver I seem to be loosing some records.
But thanks anyway I will r
You can get tombstones from inserting null values. Not sure if that’s the
problem, but it is another way of getting tombstones in your data.
On Jun 15, 2015, at 10:50 AM, Jean Tremblay
mailto:jean.tremb...@zen-innovations.com>>
wrote:
Dear all,
I identified a bit more closely the root cause o
Theres your problem, you're using the DataStax java driver :) I just ran
into this issue in the last week and it was incredibly frustrating. If you
are doing a simple loop on a "select * " query, then the DataStax java
driver will only process 2^31 rows (e.g. the Java Integer Max
(2,147,483,647)) b
Dear all,
I identified a bit more closely the root cause of my missing data.
The problem is occurring when I use
com.datastax.cassandra
cassandra-driver-core
2.1.6
on my client against Cassandra 2.1.6.
I did not have the problem when I was using the driver 2.1.4 with C* 2.1.4.
Interestingly
Hi Jean,
The problem of that Warning is that you are reading too many tombstones per
request.
If you do have Tombstones without doing DELETE it because you probably
TTL'ed the data when inserting (By mistake? Or did you set
default_time_to_live in your table?). You can use nodetool cfstats to see
Nope. No secondary index. Just a slice query on the PK.
On Tuesday, October 7, 2014, Robert Coli wrote:
> On Tue, Oct 7, 2014 at 3:11 PM, Owen Kim > wrote:
>
>> Sigh, it is a bit grating. I (genuinely) appreciate your acknowledgement
>> of that. Though, I didn't intend for the question to be
On Tue, Oct 7, 2014 at 3:11 PM, Owen Kim wrote:
> Sigh, it is a bit grating. I (genuinely) appreciate your acknowledgement
> of that. Though, I didn't intend for the question to be "about"
> supercolumns.
>
(Yep, understand tho that if you hadn't been told that advice before, it
would grate a lo
Sigh, it is a bit grating. I (genuinely) appreciate your acknowledgement of
that. Though, I didn't intend for the question to be "about" supercolumns.
It is possible I'm hitting an odd edge case though I'm having trouble
reproducing the issue in a controlled environment since there seems to be a
t
On Tue, Oct 7, 2014 at 2:03 PM, Owen Kim wrote:
> I'm aware. I've had the system up since pre-composite columns and haven't
> had the cycles to do a major data and schema migration.
>
> And that's not "slightly" non-responsive.
>
"There may be unknown bugs in the code you're using, especially be
I'm aware. I've had the system up since pre-composite columns and haven't
had the cycles to do a major data and schema migration.
And that's not "slightly" non-responsive.
On Tue, Oct 7, 2014 at 1:49 PM, Robert Coli wrote:
> On Tue, Oct 7, 2014 at 1:38 PM, Owen Kim wrote:
>
>> I'm running Cass
On Tue, Oct 7, 2014 at 1:38 PM, Owen Kim wrote:
> I'm running Cassandra 1.2.16 with supercolumns and Hector.
>
Slightly non-responsive response :
In general supercolumn use is not recommended. It makes it more difficult
to get support when one uses a feature no one else uses.
=Rob
12 matches
Mail list logo
