Edward, Michal, Thanks very much for the answers. I hadn't really thought before about how Cassandra would implement the TTL feature. I had foolishly assumed that it would be like a delete (which I would eventually be able to trigger on to execute another action) but it makes sense how it is really implemented.
I will need to find another way outside of Cassandra to implement my "do something if not deleted before TTL requirement" (ugh). Anyway, thanks again for the clarification. Gareth On Thu, Jun 13, 2013 at 2:19 AM, Michal Michalski <mich...@opera.com> wrote: > I understood it as a "run trigger when column gets deleted due to TTL", so > - as you said - it doesn't sound like something that can be done. > > Gareth, TTL'd columns in Cassandra are not really removed after TTL - they > are just ignored from that time (so they're not returned by queries), but > they still exist as long as they're not tombstoned and then removed after > grace period. Cassandra doesn't know about the exact moment they become > "outdated" due to TTL. It could be doable to do something when they get > converted to tombstone, but I don't think it's the use case you're looking > for. > > M. > > > I do not understand what feature you suggesting. Columns can already have >> a >> ttl. Are you speaking of a ttl column that could delete something beside >> itself. >> > > That does not sound easy because a ttl comment is dorment until read or >> compacted. >> >> On Tuesday, June 11, 2013, Gareth Collins <gareth.o.coll...@gmail.com> >> wrote: >> >>> Hello Edward, >>> I am curious - What about triggering on a TTL timeout delete (something I >>> >> am most interested in doing - perhaps it doesn't make sense?)? Would you >> say that is something the user should implement themselves? Would you see >> intravert being able to do something with this at some later point >> (somehow?)? >> >>> thanks, >>> Gareth >>> On Tue, Jun 11, 2013 at 2:34 PM, Edward Capriolo <edlinuxg...@gmail.com> >>> >> wrote: >> >>> >>>> This is arguably something you should do yourself. I have been >>>> >>> investigating integrating vertx and cassandra together for a while to >> accomplish this type of work, mainly to move processing close to data and >> eliminate large batches that can be computed from a single map of data. >> >>> >>>> >>>> https://github.com/zznate/**intravert-ug/wiki/Service-** >> Processor-for-trigger-like-**functionality<https://github.com/zznate/intravert-ug/wiki/Service-Processor-for-trigger-like-functionality> >> >>> >>>> On Tue, Jun 11, 2013 at 5:06 AM, Tanya Malik <sonichedg...@gmail.com> >>>> >>> wrote: >> >>> >>>>> Thanks Romain. >>>>> >>>>> On Tue, Jun 11, 2013 at 1:44 AM, Romain HARDOUIN < >>>>> >>>> romain.hardo...@urssaf.fr> wrote: >> >>> >>>>>> Not yet but Cassandra 2.0 will provide experimental triggers: >>>>>> https://issues.apache.org/**jira/browse/CASSANDRA-1311<https://issues.apache.org/jira/browse/CASSANDRA-1311> >>>>>> >>>>>> >>>>>> Tanya Malik <sonichedg...@gmail.com> a écrit sur 11/06/2013 04:12:44 >>>>>> : >>>>>> >>>>>> De : Tanya Malik <sonichedg...@gmail.com> >>>>>>> A : user@cassandra.apache.org, >>>>>>> Date : 11/06/2013 04:13 >>>>>>> Objet : Coprosessors/Triggers in C* >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Does C* support something like co-processor functionality/triggers >>>>>>> >>>>>> to >> >>> run client-supplied code in the address space of the server? >>>>>>> >>>>>> >>>> >>> >>> >> >
