accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Drew Farris (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-803) Add Reverse Logical Time as a Time Type
Date Fri, 26 Oct 2012 19:27:12 GMT


Drew Farris commented on ACCUMULO-803:

I agree, I don't feel comfortable allowing users to set column family ordering on a per mutation

With the API you propose, do you feel that fifo ordering would be best achieved by manipulating
timestamps as is done the original patch? If so, does this introduce any strangeness in the
relationship between typeType and fifoColumnFamilies? Could it make sense to use TimeType.MILLIS
and a fifo column family? Perhaps yes.

I feel a little uncomfortable with the fact that column families are dynamic but we would
require the user to specify a set of column families at creation time if they want fifo behavior.
This seems to run counter to the spirit of column families (and how they're used) in Accumulo.

One way to solve this problem would be to add setColumnFamilyOrdering(String cf, boolean fifo)
(or something like it) to TableOperations. This might not be a good idea because we run into
the same problem we have with Mutations: the user could shoot themselves in the foot if they
set the ordering on a column family to be different than the default for a table that already
contains data. 

So, I have to admit that I lean closest to the original mechanism, but I could be biased because
I'm the patch author :)


> Add Reverse Logical Time as a Time Type
> ---------------------------------------
>                 Key: ACCUMULO-803
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: tserver
>    Affects Versions: 1.5.0
>            Reporter: Drew Farris
>            Assignee: Drew Farris
>            Priority: Minor
>         Attachments: ACCUMULO-803.patch, ACCUMULO-803.patch
> In a context where we are doing aggregation/combination of multiple values for a given
key it may be useful to iterate over the values associated with that key in the order in which
the mutations were applied (FIFO), instead of the FILO order that seems to occur when using
> I encountered when implemeting a checkAndPut operation that would ensure that the previous
value was expected before putting a new value. In this case, if the previous value was not
as expected, the mutation would be ignored. 
> Perhaps it is useful in a general case?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message