[
https://issues.apache.org/jira/browse/CASSANDRA-8141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Stupp resolved CASSANDRA-8141.
-------------------------------------
Resolution: Won't Fix
Although a "time travel" query is often useful and having native support for
that in C* would be awesome, it would add too much complexity to the whole code
base. In particular memtables, (all kinds of) repairs, memtable, read-path and
lots more would need to be changed heavily. So, resolving as "won't fix".
> Versioned rows
> --------------
>
> Key: CASSANDRA-8141
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8141
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Robert Stupp
>
> People still talk about "global locks" and "distributed transactions". I
> think that introducing such things is both painful to implement and dangerous
> for a distributed application.
> But it could be manageable to introduce "versioned rows".
> By "versioned rows" I mean to issue a SELECT against data that was valid at a
> specified timestamp - something like {{SELECT ... WITH
> READTIME=1413724696473}}.
> In combination with something like {{UPDATE ... IF NOT MODIFIED SINCE
> 1413724696473}} it could be powerful. (Sure, this one could be already be
> achieved by the application today.)
> It's just an idea I'd like to discuss.
> We already have such a thing like "versioned rows" implicitly since we have
> the "old" data in the SSTables. Beside that it could be necessary to:
> * don't throw away old columns/rows for some configurable timespan
> * extend the row cache to optionally maintain "old" data
> * (surely something more)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
