> Could this just be commit log reply of the truncate?
Nevermind :)
--
/ Peter Schuller (@scode, http://worldmodscode.wordpress.com)
Could this just be commit log reply of the truncate?
--
/ Peter Schuller (@scode, http://worldmodscode.wordpress.com)
It's weird,
The table was part of a KS "Index" which I deleted in the last week.
I do not know how did it come back.
I have deleted it again and run repair on all the nodes on the cluster and
now it seems ok.
Thanks
Michael
-Original Message-
From: aaron morton [mailto:aa...@thelastpick
On Mon, Jan 2, 2012 at 12:55 PM, Jonathan Ellis wrote:
> On Mon, Jan 2, 2012 at 10:53 AM, Eric Evans wrote:
>> In SQL, PRIMARY KEY is a modifier to a column spec, and here PRIMARY
>> KEY(user_id, posted_at, posted_by) reads like a PRIMARY modifier
>> applied to a KEY() function. It's also a litt
On Mon, Jan 2, 2012 at 10:53 AM, Eric Evans wrote:
> In SQL, PRIMARY KEY is a modifier to a column spec, and here PRIMARY
> KEY(user_id, posted_at, posted_by) reads like a PRIMARY modifier
> applied to a KEY() function. It's also a little strange the way it
> appears in the grouping of column spe
Maybe the ship on this has sailed, but I am a bit miffed on "create
table". CQL is going out of its way to make things so easy for people. But
if someone does not understand the concept of a column family making it
easy for them to design something that is an anti-pattern is odd to me.
As an admi
On Sat, Dec 31, 2011 at 1:12 PM, Jonathan Ellis wrote:
> On Fri, Dec 30, 2011 at 12:30 PM, Eric Evans wrote:
>>> CREATE TABLE timeline (
>>> user_id int,
>>> posted_at uuid,
>>> body string,
>>> posted_by string,
>>> PRIMARY KEY(user_id, posted_at, posted_by),
>>> VALUE(body)
>>
What version of cassandra and what OS ?
It sort of looks like it tried to delete a secondary in CF that was defined in
the system KS.
Turn the logging up to DEBUG and see what happens.
Hope that helps.
Aaron
-
Aaron Morton
Freelance Developer
@aaronmorton
http://www.thelast
