Does anyone know of any strategies for tracking the created date of a row or column, without a checkAndPut() type of solution? I am trying to avoid reading from the table to see if the value already exists before putting. One thought I had was to store a timestamp of every update as a column, but that might bloat my rows.

do you really care about each update? you can store the created_at field as
a column and use that to decide whether to put or not. the other option is
to do a get with a time range less than the value you are looking for. if
you get something back, then you don't need to go any further.

thanks

On Thu, Feb 23, 2012 at 3:57 PM, Bryan Keller <[EMAIL PROTECTED]> wrote:

> Does anyone know of any strategies for tracking the created date of a row
> or column, without a checkAndPut() type of solution? I am trying to avoid
> reading from the table to see if the value already exists before putting.
> One thought I had was to store a timestamp of every update as a column, but
> that might bloat my rows.

I'm thinking I could implement a coprocessor to do this. I'm still on 0.90.4 ATM, but it's a thought going forward. I haven't played around with coprocessors yet though so not sure if this is feasible.

On Feb 23, 2012, at 4:05 PM, T Vinod Gupta wrote:

> do you really care about each update? you can store the created_at field as
> a column and use that to decide whether to put or not. the other option is
> to do a get with a time range less than the value you are looking for. if
> you get something back, then you don't need to go any further.
>
> thanks
>
> On Thu, Feb 23, 2012 at 3:57 PM, Bryan Keller <[EMAIL PROTECTED]> wrote:
>
>> Does anyone know of any strategies for tracking the created date of a row
>> or column, without a checkAndPut() type of solution? I am trying to avoid
>> reading from the table to see if the value already exists before putting.
>> One thought I had was to store a timestamp of every update as a column, but
>> that might bloat my rows.