Information on triggers seems a bit scarce so far. The blog entry on
http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-0-prototype-triggers-support
mentions them as being usable for maintaining materialized views, since
they'll be handled similarly to logged/atomic batches - is that enough to
ensure that values in materialized views remain accurate?
Or does "atomic" in this context really mean atomic, isolated and
linearized per node - much like updates of indexed columns are handled too?
("indexed" here being secondary indices.)
Also, the document mentions triggers being "partition-level". Does this
mean trigger code (or rather the generated mutations of a trigger) cannot
manipulate more than one partition (and thus also cannot manipulate more
than one columnfamily)? How can materialized views be maintained without
being able to write to 2 columnfamilies (the cf with the actual values, and
the cf with the pre-aggregated ones)?
Finally, one more question about the future of triggers: Since it is
planned for 3.0 to have user defined functions (UDFs) in some PL/SQL-like
language, will it (eventually) be possible to write triggers in this
language too? Or will triggers always have to be directly loaded into the
JVM processes of the Cassandra instances?
It would be great if there was some way to be able to load trigger code
from the client-side without having to manipulate the code and/or libraries
on the server-side for scenarios where Cassandra is being used as a hosted
service (PaaS).
I realize that triggers are still experimental, but this looks like an
exciting new feature.
