[jira] [Resolved] (CASSANDRA-8141) Versioned rows

["Robert Stupp (JIRA)" <ji...@apache.org>]

     [ 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)