Sylvain,
If you're interested, why don't you create a new ticket and assign it
to yourself. I'd be happy to help you figure out which parts of the
codebase need to be touched.
-Kelvin
btw, I'm working on Issue #580 which will add versioning to Cassandra.
An aspect of this feature is that I am
You're right, if the TTL will be dynamically set, then we'd need to
make room for it. Otherwise, if it's globally set, we could save that
space.
-Kelvin
On Wed, Jan 13, 2010 at 1:16 PM, Kelvin Kakugawa wrote:
> Are you thinking about storing the expiration time explicitly?
for a long (or 4 for an int,
> which should actually be plenty of resolution for this use case) to
> each Column object.
>
> On Wed, Jan 13, 2010 at 4:57 PM, Kelvin Kakugawa wrote:
>> An alternative implementation that may be worth exploring would be to
>> modify IColumn&#
An alternative implementation that may be worth exploring would be to
modify IColumn's isMarkedForDelete() method to check TTL.
It probably wouldn't be as performant as straight dropping SSTables.
You'd probably also need to periodically compact old tables to remove
expired rows. However, on the
Cassandra, right now, doesn't use vector clocks internally. However,
an implementation is being worked on, here:
https://issues.apache.org/jira/browse/CASSANDRA-580
-Kelvin
On Sun, Dec 6, 2009 at 10:41 AM, Ran Tavory wrote:
> As a Cassandra newbe, after having read the Dynamo paper, I was wonde
