Hi Stefan ,
Yes ,you are right, That is why I send the second email stating that we are
not going to support cloning triggers in CREATE TABLE LIKE .
Štefan Miklošovič 于2025年2月10日周一 18:12写道：
> Hi Maxwell,
>
> even the issues mentioned in CASSANDRA-20287 are fixed, I still do not
&
Hi Maxwell,
even the issues mentioned in CASSANDRA-20287 are fixed, I still do not
think we should support the copying of triggers. Reasons I think we should
not support that are:
1) According to this comment (1) Triggers API is considered beta and can
change. Unless we promote trigger's AP
Referring to the opinions of most people, we ignore the cloning of triggers
just for the CREATE TABLE LIKE feature.
guo Maxwell 于2025年2月10日周一 16:39写道：
> Then we don’t support trigger until CASSANDRA-20287 is fixed, and this
> rule applies to custom index , too. right ?
>
>
> Sam
uded in a snapshot:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata#CEP21:TransactionalClusterMetadata-SnapshottingMetadataLog
> >
> > I also think it's reasonable to not include triggers (or other custom
> fields) in the
remove the trigger from the
> classpath until the trigger drop epoch has been included in a snapshot:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata#CEP21:TransactionalClusterMetadata-SnapshottingMetadataLog
>
> I also think it'
gMetadataLog
>
> I also think it's reasonable to not include triggers (or other custom
> fields) in the clone, but if users need to sort out what parts of their
> original table were copied to their clone it's not as convenient to have a
> separate command for it.
>
the trigger from the classpath until the
trigger drop epoch has been included in a snapshot:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata#CEP21:TransactionalClusterMetadata-SnapshottingMetadataLog
I also think it's reasonable to not include
can still create it by hand. I don't see anything wrong with
that. In general I think we should be very cautious about this and not
support it if we just can't say that it will all work in 100% of scenarios.
On Mon, Feb 3, 2025 at 6:14 PM Abe Ratnofsky wrote:
> I think it would be reas
I think it would be reasonable to copy the triggers. The ITrigger interface
provides a Partition with metadata() to find which table the original mutation
was issued for. In the example AuditTrigger, the destination audit table is
configurable but if a user attaches AuditTrigger to an existing
Thank you everyone, then I will skip triggers.
Bernardo Botella 于2025年2月1日周六 07:01写道：
> +1 on skipping triggers if we can’t make sure that it will work in every
> scenario.
> The experience of copying a table and having a broken result is definitely
> something to avoid.
>
+1 on skipping triggers if we can’t make sure that it will work in every
scenario.
The experience of copying a table and having a broken result is definitely
something to avoid.
Kind regards,
Bernardo
> On Jan 31, 2025, at 10:49 AM, Brandon Williams wrote:
>
> I agree, and trigge
I agree, and triggers are an expert feature anyway so I wouldn't
expect them to be copied.
Kind Regards,
Brandon
On Fri, Jan 31, 2025 at 12:46 PM Štefan Miklošovič
wrote:
>
> Thank you Maxwell for reaching ML with this.
>
> I was talking to Maxwell about a feature where CREATE
Thank you Maxwell for reaching ML with this.
I was talking to Maxwell about a feature where CREATE TABLE LIKE would also
support triggers.
create table ks.tb_copy like ks.tb with triggers
"with triggers" would be added to CQL grammar and it would "copy" what that
trigg
ed and load the corresponding class to do
something similar to preprocessing on the write path.
So my question here is : Are we fine with the current implementation here,
Should we support triggers in new features ?
I encountered this problem recently, we are also discussing whether we need
to cont
I checked and cassandra channel was created by zznate at apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
e.org
Subject: Re: [EXTERNAL] Re: Triggers
Fair enough, do not hesitate to join us on Slack if you have questions, I bet
there are a lot of people willing to gladly answer your questions and concerns
about Cassandra and how it differs from your relational world. Nothing bad
about a mailing list as
>
> Hi,
>
> why can't this be achieved by batches? Do I miss something fundamental
> here? Batches may write to different tables right ... I am just
> missing the point of using triggers for this.
>
> I add specifics to Brian's first paragraph, this is covered
, December 15, 2020 1:38 PM
> To: dev@cassandra.apache.org
> Subject: Re: [EXTERNAL] Re: Triggers
>
> On Tue, 15 Dec 2020 at 14:24, Greg Oliver
> wrote:
> >
> > Why not batches: I thought that it might be best that read and write models
> > are in different key
to a relational database.
-Original Message-
From: Stefan Miklosovic
Sent: Tuesday, December 15, 2020 1:38 PM
To: dev@cassandra.apache.org
Subject: Re: [EXTERNAL] Re: Triggers
On Tue, 15 Dec 2020 at 14:24, Greg Oliver wrote:
>
> Why not batches: I thought that it might be best that rea
how people recommend manifesting the query
> model(s). No luck so far.
>
> Why trigger? Because according to the docs, a trigger runs atomically with
> the original write.
>
> But - as Benjamin Lerer says below - triggers don't work as expected? Still
> would like to know
see how people recommend manifesting the query
model(s). No luck so far.
Why trigger? Because according to the docs, a trigger runs atomically with the
original write.
But - as Benjamin Lerer says below - triggers don't work as expected? Still
would like to know the right ways and wrong ways to
Hi,
why can't this be achieved by batches? Do I miss something fundamental
here? Batches may write to different tables right ... I am just
missing the point of using triggers for this.
I add specifics to Brian's first paragraph, this is covered by
CASSANDRA-13985 -
https://github.
>> escreveu:
>>
>> Can't see it in the email. What's the slide #?
>>
>> From: Andrew Cobley (Staff)
>> Sent: Tuesday, December 15, 2020 12:26 PM
>> To: dev@cassandra.apache.org
>> Subject: [EXTERNAL] Re: Triggers
>>
&g
to the project development of
Cassandra.
Em ter., 15 de dez. de 2020 às 09:28, Greg Oliver
escreveu:
> Can't see it in the email. What's the slide #?
>
> From: Andrew Cobley (Staff)
> Sent: Tuesday, December 15, 2020 12:26 PM
> To: dev@cassandra.apache.org
> Subject: [
Can't see it in the email. What's the slide #?
From: Andrew Cobley (Staff)
Sent: Tuesday, December 15, 2020 12:26 PM
To: dev@cassandra.apache.org
Subject: [EXTERNAL] Re: Triggers
Yes that's right. I remember this illustration:
[Diagram Description automatically generate
sig-sc>
One of the UK's top 20 universities<http://uod.ac.uk/sig-strapline>
The Guardian University Guide 2021
[Covid code of conduct icons]<http://uod.ac.uk/sig-cvc>
From: Paul Chandler
Date: Tuesday, 15 December 2020 at 12:16
To: dev@cassandra.apache.org
Subject: Re: Trigg
of
> the solution.
>
> With Cassandra (and I'm definitely new to it), as I learn more it looks like
> a set of materialized views might be a way to achieve the goal.
>
> Thoughts?
>
> From: Andrew Cobley (Staff)
> Sent: Tuesday, December 15, 2020 11:57 AM
>
Tuesday, December 15, 2020 11:57 AM
To: dev@cassandra.apache.org
Subject: [EXTERNAL] Re: Triggers
I may be wrong, but isn't the correct pattern for this to use two data centres?
You write to one data centre, replicate to the other and read from that one.
Or am misunderstanding ?
Andy
[Un
-sc>
One of the UK's top 20 universities<http://uod.ac.uk/sig-strapline>
The Guardian University Guide 2021
[Covid code of conduct icons]<http://uod.ac.uk/sig-cvc>
From: Benjamin Lerer
Date: Tuesday, 15 December 2020 at 11:50
To: dev@cassandra.apache.org
Subject: Re: Triggers
Hi Greg
Hi Greg,
Things are more tricky in an eventually consistent distributed system than
they are in a relational database. Even if the C* triggers were perfect
(and they are not) and your write and read tables were exactly the same,
there is no guarantee that all the updates created by the trigger
message saying "don't do it unless you really know
what you're doing" pops up.
Why? What are the cases for and against using triggers in Cassandra? What are
the edge cases to avoid? What is the happy path?
Thanks,
Greg
MV partitioner would calculate the PK of the
> > >> base
> > >> > table (which is always possible) and then apply the regular
> > partitioner.
> > >> >
> > >> > I'll create a proper
apply the regular
>>> partitioner.
>>> >
>>> > I'll create a proper Jira for it on monday. Currently it's sunday here
>>> and
>>> > my family wants me back so just a few thoughts on this right now.
>>>
y wants me back so just a few thoughts on this right now.
> >> >
> >> > Any feedback is appreciated!
> >> >
> >> > 2017-03-05 6:34 GMT+01:00 Edward Capriolo :
> >> >
> >> > > On Sat, Mar 4, 2017 at 10
t;> > >
>> > > >
>> > > >
>> > > >
>> > > > > On Mar 4, 2017, at 7:06 AM, Edward Capriolo <
>> edlinuxg...@gmail.com>
>> > > > wrote:
>> > > > >
>> > > > >> On Fri
gt; > > wrote:
> > > > >
> > > > >> On Fri, Mar 3, 2017 at 12:04 PM, Jeff Jirsa
> > wrote:
> > > > >>
> > > > >> On Fri, Mar 3, 2017 at 5:40 AM, Edward Capriolo <
> > > edlinuxg...@gmail.com>
> > > > &g
dward Capriolo <
> > edlinuxg...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>>
> > > >>> I used them. I built do it yourself secondary indexes with them.
> They
> > > >> have
> > > >>> th
m. I built do it yourself secondary indexes with them. They
> > >> have
> > >>> there gotchas, but so do all the secondary index implementations.
> Just
> > >>> because datastax does not write about something. Lets see like 5
> years
> > >> ago
>> wrote:
> >>
> >>>
> >>> I used them. I built do it yourself secondary indexes with them. They
> >> have
> >>> there gotchas, but so do all the secondary index implementations. Just
> >>> because datastax does n
exes with them. They
>> have
>>> there gotchas, but so do all the secondary index implementations. Just
>>> because datastax does not write about something. Lets see like 5 years
>> ago
>>> there was this: https://github.com/hmsonline/cassandra-triggers
>>
ndexes with them. They
>> have
>> > there gotchas, but so do all the secondary index implementations. Just
>> > because datastax does not write about something. Lets see like 5 years
>> ago
>> > there was this: https://github.com/hmsonline/cassandra-triggers
ons. Just
> > because datastax does not write about something. Lets see like 5 years
> ago
> > there was this: https://github.com/hmsonline/cassandra-triggers
> >
> >
> Still in use? How'd it work? Production ready? Would you still do it that
> way in 2017?
>
&g
Does Cassandra itself use triggers internally for something?
That would make a pretty good case for triggers being ready for production
use.
Otherwise, it would tend to be a neglected feature because active
developers would have no good reason to add features to it other than just
make the test
> there was this: https://github.com/hmsonline/cassandra-triggers
>
>
Still in use? How'd it work? Production ready? Would you still do it that
way in 2017?
> There is a fairly large divergence to what actual users do and what other
> groups 'say' actual users do in
On Thu, Mar 2, 2017 at 2:10 PM, Kant Kodali wrote:
> +1
>
> On Thu, Mar 2, 2017 at 11:04 AM, S G wrote:
>
> > Hi,
> >
> > I am not able to find any documentation on the current state of triggers
> > being production ready.
> >
> > The post at
&
There wasn't much work done on triggers since they "came out". Basically it
was always marked as experimental and never got to a usable production
ready state. CDC is going to become a new way of doing things that made you
look into triggers.
Other than that as Jeff said, I nev
As far as I know, I've never met anyone who wrote and used their own
triggers in production. I imagine the number of people doing so is very
small, regardless of version.
On Thu, Mar 2, 2017 at 11:04 AM, S G wrote:
> Hi,
>
> I am not able to find any documentation on the cu
+1
On Thu, Mar 2, 2017 at 11:04 AM, S G wrote:
> Hi,
>
> I am not able to find any documentation on the current state of triggers
> being production ready.
>
> The post at
> http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-
> 0-prototype-triggers-support
Hi,
I am not able to find any documentation on the current state of triggers
being production ready.
The post at
http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-0-prototype-triggers-support
says that "The current implementation is experimental, and there is some
work to do b
Hi,
1. Are Cassandra Triggers Thread Safe? what happens if two writes invoke
the trigger where the trigger is trying to modify same row in a partition?
2. Had anyone used it successfully on production? If so, any issues? (I am
using the latest version of C* 3.10)
3. I have partitions that are
I know that, but in all the example that I have seen online, they are
getting an object of actuall 'ColumnFamily'. I was wondering why I am
getting a UsortedClumns instead of ColumnFamily.
and thanks for pointing out column iterator to me. that is gonna be
usefull ;)
On 10/28/2013 01:28 PM,
UnsortedColumns is a subclass of CF that only supports iterating
through the cells, not random access.
On Mon, Oct 28, 2013 at 2:36 PM, kaveh minooie wrote:
> Hi
>
> I am not sure if, stricly speaking, this is a dev list issue, but i figured
> I would probably have a better chance here than user
Hi
I am not sure if, stricly speaking, this is a dev list issue, but i
figured I would probably have a better chance here than user list. I am
using cassandra 2.0.1 and I am trying to write a trigger, but I am
having an issue. in the augment function:
public Collection augment(ByteBuffer key
Out of interest some questions…
When writing through triggers how do you handle the CL guarantee ? Is the CL
level checked once at the start or checked for each embedded code invocation ?
Do you still guarantee the (non counter) writes as idempotent ? i.e. do the
triggers need to be
ion, triggers/stored procedures are an absolute requirement for
> any distributed database.
>
> We've been using stored procedures in Cassandra now for a while, we've
> made modifications such that we don't really write directly anymore but
> pass everything through either a de
In my opinion, triggers/stored procedures are an absolute requirement for any
distributed database.
We've been using stored procedures in Cassandra now for a while, we've made
modifications such that we don't really write directly anymore but pass
everything through either a
Praveen,
We are certainly interested. To get things moving we implemented an add-on for
Cassandra to demonstrate the viability (using AOP):
https://github.com/hmsonline/cassandra-triggers
Right now the implementation executes triggers asynchronously, allowing you to
implement a java interface
I found that Triggers are coming in Cassandra 1.2 (
https://issues.apache.org/jira/browse/CASSANDRA-1311) but no mention of any
StoreProc like pattern.
I know this has been discussed so many times but never met with
any initiative. Even Groovy was staged out of the trunk.
Cassandra is great for
I just posted to the user list, but figured I would post here as well.
We had a big session today designing application-level triggers using a new
column family as a distributed commit log.
When I got back to my desk, I re-googled Cassandra triggers, and re-read:
https://issues.apache.org/jira
Just wanted to let people who follow the user list know that if there is
interest in something like plugins, triggers, or coprocessors on the
server-side with Cassandra, the ticket to follow or get involved with (code,
comments, etc) is CASSANDRA-1311:
https://issues.apache.org/jira/browse
; Jeremy, thanks for starting the discussion! We don't follow the dev list
>>> closely so it was a good idea to email it directly.
>>>>
>>>> It really seems to be about the same. To unify the discussions, we
>>> propose to list the features of each solution
1, at 10:36 AM, Maxim Grinev wrote:
>>
>> > Hi all,
>> >
>> > Jeremy, thanks for starting the discussion! We don't follow the dev list
>> closely so it was a good idea to email it directly.
>> >
>> > It really seems to be about the same.
it directly.
> >
> > It really seems to be about the same. To unify the discussions, we
> propose to list the features of each solution and compare them feature by
> feature. Here is the feature list for triggers:
> > • Triggers are set on a column family.
> It really seems to be about the same. To unify the discussions, we propose to
> list the features of each solution and compare them feature by feature. Here
> is the feature list for triggers:
> • Triggers are set on a column family. Triggers are executed for each
> mutati
64 matches
Mail list logo
