Re: Alter table

2018-12-20 Thread Rahul Singh
If you use collections such as a map you could get by with just upserts. A collection in a column gives you the ability to have “flexible” schema for your “documents” as in mongo while the regular fields can act as “records” as in a more Traditional table. Rahul Singh Chief Executive Officer m

Re: Alter table

2018-12-17 Thread Peter Corless
Alter table would change columns (the structure) of a table. Adding or deleting a column, for instance. Upserts would add (or edit) rows of an existing table. ALTER TABLE vs. UPDATE

Re: Alter table

2018-08-01 Thread Jeff Jirsa
(My advice stands, I still believe it to be safe in all modern versions not impacted by 13004, but) There’s little difference between adding columns and removing columns - if you’re afraid of writes while you add columns, you should be afraid of writes while you remove columns. (But I don’t th

Re: Alter table

2018-08-01 Thread Visa
Thanks for all the inputs! We’ll stick to the current approach then. How about dropping columns - If we also stop writes beforehand, we should be safe from data alignment issue after dropping columns? Thanks, Li > On Jul 31, 2018, at 04:14, James Shaw wrote: > > in a heavy transaction PROD en

Re: Alter table

2018-07-31 Thread James Shaw
in a heavy transaction PROD env, it is risk, considering c* has a lot of bugs. the DDL has to be replicated to all nodes, use nodetool describecluster to check schema version same on all nodes, if not, you may restart that node which DDL not replicated. in new version, DDL is none or all, you ma

Re: Alter table

2018-07-30 Thread Jeff Jirsa
This is safe (and normal, and good) in all versions except those impacted by https://issues.apache.org/jira/browse/CASSANDRA-13004 So if you're on 2.1, 2.2, or 3.11 you're fine If you're on 3.0 between 3.0.0 and 3.0.13, you should upgrade first (to newest 3.0, probably 3.0.17) If you're on a vers

Re: Alter table gc_grace_seconds

2017-10-04 Thread Gábor Auth
Hi, On Wed, Oct 4, 2017 at 8:39 AM Oleksandr Shulgin < oleksandr.shul...@zalando.de> wrote: > If you have migrated ALL the data from the old CF, you could just use > TRUNCATE or DROP TABLE, followed by "nodetool clearsnapshot" to reclaim the > disk space (this step has to be done per-node). > Un

Re: Alter table gc_grace_seconds

2017-10-03 Thread Oleksandr Shulgin
On Sun, Oct 1, 2017 at 4:14 PM, Gábor Auth wrote: > Hi, > > On Sun, Oct 1, 2017 at 3:44 PM Varun Barala > wrote: > >> This is the property of table and It's not written in sstables. If you >> change gc_grace, It'll get applied for all the data. >> > > Hm... I've migrated lot of data from `number

Re: Alter table gc_grace_seconds

2017-10-02 Thread Gábor Auth
Hi, On Mon, Oct 2, 2017 at 1:43 PM Varun Barala wrote: > Either you can change min_threshold to three in your case or you can > change compaction strategy for this table. > I've changed: alter table number_item with compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompaction

Re: Alter table gc_grace_seconds

2017-10-02 Thread Varun Barala
lto:jus...@instaclustr.com] > *Sent:* Montag, 02. Oktober 2017 08:32 > *To:* user@cassandra.apache.org > *Subject:* Re: Alter table gc_grace_seconds > > > > >> * You should not try on real clusters directly. > > >Why not? :) > > It's highly recommended that you complet

RE: Alter table gc_grace_seconds

2017-10-02 Thread Steinmaurer, Thomas
ect: Re: Alter table gc_grace_seconds >> * You should not try on real clusters directly. >Why not? :) It's highly recommended that you complete a full repair before the GC grace period expires, otherwise it's possible you could experience zombie data (i.e. data that was pre

Re: Alter table gc_grace_seconds

2017-10-02 Thread Gábor Auth
Hi, On Mon, Oct 2, 2017 at 8:41 AM Varun Barala wrote: > Might be possible C* is not compacting the sstables [ > https://stackoverflow.com/questions/28437301/cassandra-not-compacting-sstables > ] > Oh, the other CF-s in the same keyspace are compacted, but the `number_item` not. [cassandra@dc0

Re: Alter table gc_grace_seconds

2017-10-02 Thread Gábor Auth
Hi, On Mon, Oct 2, 2017 at 8:32 AM Justin Cameron wrote: > >> * You should not try on real clusters directly. > >Why not? :) > > It's highly recommended that you complete a full repair before the GC > grace period expires, otherwise it's possible you could experience zombie > data (i.e. data tha

Re: Alter table gc_grace_seconds

2017-10-01 Thread Varun Barala
+1 Justing, Might be possible C* is not compacting the sstables [ https://stackoverflow.com/questions/28437301/cassandra-not-compacting-sstables ]. You can this fact by doing below procedure:- *Run this before compaction:-* ls /var/lib/cassandra/data/mat/number_item-*/ Store result to some file

Re: Alter table gc_grace_seconds

2017-10-01 Thread Justin Cameron
>> * You should not try on real clusters directly. >Why not? :) It's highly recommended that you complete a full repair before the GC grace period expires, otherwise it's possible you could experience zombie data (i.e. data that was previously deleted coming back to life) See http://thelastpickle

Re: Alter table gc_grace_seconds

2017-10-01 Thread Gábor Auth
Hi, On Mon, Oct 2, 2017 at 5:55 AM Varun Barala wrote: > *select gc_grace_seconds from system_schema.tables where keyspace_name = > 'keyspace' and table_name = 'number_item;* > cassandra@cqlsh:mat> DESCRIBE TABLE mat.number_item; CREATE TABLE mat.number_item ( nodeid uuid, type text,

Re: Alter table gc_grace_seconds

2017-10-01 Thread Varun Barala
Can you share result of query:- *select gc_grace_seconds from system_schema.tables where keyspace_name = 'keyspace' and table_name = 'number_item;* Thanks!! On Mon, Oct 2, 2017 at 3:42 AM, Gábor Auth wrote: > Hi, > > On Sun, Oct 1, 2017 at 9:36 PM Varun Barala > wrote: > >> * You should not t

Re: Alter table gc_grace_seconds

2017-10-01 Thread Gábor Auth
Hi, On Sun, Oct 1, 2017 at 9:36 PM Varun Barala wrote: > * You should not try on real clusters directly. > Why not? :) Did you change gc_grace for all column families? > Not, only on the `number_item` CF. > But not in the `number_item` CF... :( > Could you please explain? > I've tried the t

Re: Alter table gc_grace_seconds

2017-10-01 Thread Varun Barala
* You should not try on real clusters directly. Did you change gc_grace for all column families? > But not in the `number_item` CF... :( Could you please explain? Thanks!! On Mon, Oct 2, 2017 at 2:24 AM, Gábor Auth wrote: > Hi, > > On Sun, Oct 1, 2017 at 7:44 PM Varun Barala > wrote: > >> So

Re: Alter table gc_grace_seconds

2017-10-01 Thread Gábor Auth
Hi, On Sun, Oct 1, 2017 at 7:44 PM Varun Barala wrote: > Sorry If I misunderstood the situation. > Ok, I'm confused... :/ I've just tested it on the same cluster and the compact removed the marked_deleted rows. But not in the `number_item` CF... :( Cassandra 3.11.0, two DC (with 4-4 nodes).

Re: Alter table gc_grace_seconds

2017-10-01 Thread Varun Barala
Sorry If I misunderstood the situation. { "type" : "row", "position" : 146160, "clustering" : [ "humidity", "97781fd0-9dab-11e7-a3d5-7f6ef9a844c7" ], "deletion_info" : { "marked_deleted" : "2017-09-25T11:51:19.165276Z", "local_delete_time" : "2017-09-25T11:51:19Z" }, "cells" : [ ] } H

Re: Alter table gc_grace_seconds

2017-10-01 Thread Gábor Auth
Hi, On Sun, Oct 1, 2017 at 6:53 PM Jonathan Haddad wrote: > The TTL is applied to the cells on insert. Changing it doesn't change the > TTL on data that was inserted previously. > Is there any way to purge out these tombstoned data? Bye, Gábor Auth

Re: Alter table gc_grace_seconds

2017-10-01 Thread Gábor Auth
Hi, On Sun, Oct 1, 2017 at 6:53 PM Jonathan Haddad wrote: > The TTL is applied to the cells on insert. Changing it doesn't change the > TTL on data that was inserted previously. > Oh! So that the tombstoned cell's TTL is equals with the CF's gc_grace_seconds value and the repair will be remove

Re: Alter table gc_grace_seconds

2017-10-01 Thread Jonathan Haddad
The TTL is applied to the cells on insert. Changing it doesn't change the TTL on data that was inserted previously. On Sun, Oct 1, 2017 at 6:23 AM Gábor Auth wrote: > Hi, > > The `alter table number_item with gc_grace_seconds = 3600;` is sets the > grace seconds of tombstones of the future modif

Re: Alter table gc_grace_seconds

2017-10-01 Thread Varun Barala
* Which C* version are you using? * How many nodes are there in this cluster? These tombstones will not be deleted if they are not older than gc_grace_seconds. On Sun, Oct 1, 2017 at 10:14 PM, Gábor Auth wrote: > Hi, > > On Sun, Oct 1, 2017 at 3:44 PM Varun Barala > wrote: > >> This is the pr

Re: Alter table gc_grace_seconds

2017-10-01 Thread Gábor Auth
Hi, On Sun, Oct 1, 2017 at 3:44 PM Varun Barala wrote: > This is the property of table and It's not written in sstables. If you > change gc_grace, It'll get applied for all the data. > Hm... I've migrated lot of data from `number_item` to `measurement` CF because of scheme upgrade. During the m

Re: Alter table gc_grace_seconds

2017-10-01 Thread Varun Barala
Hi, This is the property of table and It's not written in sstables. If you change gc_grace, It'll get applied for all the data. Thanks!! C* stores this info inside schema_columnfamilies Regards, Varun Barala On Sun, Oct 1, 2017 at 9:23 PM, Gábor Auth wrote: > Hi, > > The `alter table number_it

Re: alter table issues on 2.0.10

2014-10-15 Thread DuyHai Doan
I found this JIRA with similar error message ( https://issues.apache.org/jira/browse/CASSANDRA-6276), not sure it applies to your case, and especially the issue is supposed to be fixed in 2.0.10 (your current version). Consider filling a new JIRA if you can reproduce the issue On Mon, Oct 13, 20

Re: alter table issues on 2.0.10

2014-10-12 Thread tommaso barbugli
Here is the full stack trace ERROR [Native-Transport-Requests:5802] 2014-10-12 22:48:12,237 QueryMessage.java (line 131) Unexpected error during query java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.RuntimeException: org.apache.cassandra.exceptions.ConfigurationExcep

Re: alter table issues on 2.0.10

2014-10-12 Thread DuyHai Doan
Hello Tommaso Can you give the full exception stack trace? Consider also filing a JIRA, it looks pretty fishy... On Sun, Oct 12, 2014 at 10:53 PM, tommaso barbugli wrote: > Hi, > it actually seems to be worse than what I thought; I get an exception in > cassandra logs every time I try to creat

Re: alter table issues on 2.0.10

2014-10-12 Thread tommaso barbugli
Hi, it actually seems to be worse than what I thought; I get an exception in cassandra logs every time I try to create a new table. Cql query: CREATE TABLE shard12 ("feed_id" ascii, "activity_id" timeuuid, "activities" blob, "created_at" timestamp, "group" ascii, "updated_at" timestamp, "seen_at"

Re: Alter table drop column seems not working

2013-04-04 Thread julien Campan
You are right, the documentation says that this action is not supported. I was surprised because the "auto completion" in cqlsh allows you to try it and, moreover, you have an example of a drop column when you use "help alter_drop". Maybe it would be nice to change at least the documentation and

Re: Alter table drop column seems not working

2013-04-03 Thread aaron morton
I dont think it's supported http://www.datastax.com/docs/1.2/cql_cli/cql/ALTER_TABLE#dropping-typed-col Anyone else know? Cheers - Aaron Morton Freelance Cassandra Consultant New Zealand @aaronmorton http://www.thelastpickle.com On 3/04/2013, at 8:11 PM, julien Campan wrote: