Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Message-ID: <56EA186D.5020009@gmail.com>
Date: Wed, 16 Mar 2016 22:37:33 -0400
From: Josh Elser <josh.elser@gmail.com>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: dev@accumulo.apache.org
Subject: Re: delete + insert case
References: <1458160433777-16375.post@n5.nabble.com>
 <CAGUtCHobuRe4Ak3Mb2P83hpus-4qRs-Kjg6yT77-Z5JKQRujUw@mail.gmail.com>
 <56E9D454.8080901@gmail.com> <1458170988999-16379.post@n5.nabble.com>
In-Reply-To: <1458170988999-16379.post@n5.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Server-assigned timestamps are done per-batch. This is getting back to 
what Keith suggested. It's not that Accumulo isn't "setting the 
timestamp properly" like you suggest, this is just how server-assigned 
time works.

If you submit a delete and an update, without timestamps, in the same 
batch (without a flush inbetween) they'll get the same timestamp, and 
the delete will override the update.

tl;dr Use Keith's approach if you can't compute an increasing value for 
the timestamp.

z11373 wrote:
> Thanks Keith/Josh!
>
> @Josh: the client API I use in my code is the one without passing that long
> timestamp, so Accumulo should assign the timestamp in time ordered manner,
> right?
>  From my service app log file, I see the add always being called after
> delete, so it should work if Accumulo set the timestamp properly, but there
> could be possibility they are assigned same timestamp, hence the behavior is
> not predictable?
> I prefer not to assign timestamp from my code if possible.
>
>
> Thanks,
> Z
>
>
>
> --
> View this message in context: http://apache-accumulo.1065345.n5.nabble.com/delete-insert-case-tp16375p16379.html
> Sent from the Developers mailing list archive at Nabble.com.