accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-803) Add Reverse Logical Time as a Time Type
Date Wed, 17 Oct 2012 17:52:04 GMT


Keith Turner commented on ACCUMULO-803:

bq. I like the setting of timestamp transformation in the Mutation, but do you think people
might want to set multiple different transformations for different column updates in the same

I like it too, but the bulk import aspect is still tormenting me.  I was being miserly with
computation and storage when thinking about setting it at the mutation level.  Eric just modified
mutation so that the system timstamp is set once per mutation.  It used to set the same timestamp
for each column.  I wanted to maintain this slight boost in ingest performance.  I suppose
we could still set the timestamp once permutation and just interpret it differently if a flag
is set for the column when getTimestamp() is called.

For bulk import, if the user request logical time, it will set the same timestamp for all
keys in the file.   We could make it reverse this timestamp for all keys in the file.  But
I have not thought of a simple method for do  something more granular.  Seems like the two
are options are modify the Key written by bulk import or modify the special iterator that
sets timestamps on bulk imported files when they are read.  Don't really like this options.
 But we don't have to support anything more granular for bulk import.

> 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