Mailing-List: contact dev-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@accumulo.apache.org
Message-ID: <56E9CAFF.3070809@gmail.com>
Date: Wed, 16 Mar 2016 17:07:11 -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>
In-Reply-To: <1458160433777-16375.post@n5.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Make sure that your insert has a newer timestamp than the delete does. 
Otherwise, the delete will mask any inserts with smaller timestamps 
until it is compacted away (which is essentially an unknown to you as a 
client).

e.g.

1. delete A ts=5
2. add A ts=6
3. add B ts=whatever

z11373 wrote:
> Hi,
> I have object abstraction class which delete/add operation will eventually
> translate to calling Accumulo writer.putDelete and writer.put
> To achieve higher throughput, the code will only call writer.flush per
> request (my implementation knows when it's end of request), instead of
> flushing per each delete or add operation.
> In this case we have client request calling my service which for example
> would be:
> 1. delete A
> 2. add A
> 3. add B
>
> I'd expect the end result would be both row id A and B exists in the table,
> but apparently it's only B. I already checked from the log, the order the
> code being executed is delete first before add operation. However, I guess
> since I call flush after all putDelete and put calls being made, Accumulo
> somehow make putDelete 'win' (in same flush cycle), is that correct? If yes,
> how to workaround this without sacrificing performance.
>
>
> Thanks,
> Z
>
>
>
> --
> View this message in context: http://apache-accumulo.1065345.n5.nabble.com/delete-insert-case-tp16375.html
> Sent from the Developers mailing list archive at Nabble.com.