You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hbase.apache.org by Ted Yu <yu...@gmail.com> on 2010/05/20 01:53:06 UTC
delete operation that can be rolled back
Hi,
We are implementing delete operation that can be rolled back. I.e. we don't
want to delete particular row immediately before a set of rows are
processed.
I want to get wisdom from the community for the best practice.
Thanks
Re: delete operation that can be rolled back
Posted by Angus He <an...@gmail.com>.
> The pseudo code is on client side.
> But the second loop may involve scanning hbase table, depending on the
> number of deleted rows.
I was wondering why the scanning on the hbase table may be involved.
Have you flushed the changes of the rows marked in the first loop to
hbase table yet?
--
Regards
Angus
Re: delete operation that can be rolled back
Posted by Ted Yu <yu...@gmail.com>.
The pseudo code is on client side.
But the second loop may involve scanning hbase table, depending on the
number of deleted rows.
So I wanted to know if there is better solution.
Cheers
On Wed, May 19, 2010 at 6:00 PM, Jonathan Gray <jg...@facebook.com> wrote:
> Why do you need a server-side, rollback-able delete? Seems like the client
> pseudo-code works fine as you describe. (mark the row deleted by adding it
> to a local list of rows to be deleted)
>
> > -----Original Message-----
> > From: Ted Yu [mailto:yuzhihong@gmail.com]
> > Sent: Wednesday, May 19, 2010 5:28 PM
> > To: user@hbase.apache.org
> > Subject: Re: delete operation that can be rolled back
> >
> > pseudo code:
> > for every row in a set
> > mark the row deleted but not calling HBase delete
> > if certain condition is satisfied, bail out of loop
> > for every marked row in previous loop
> > delete it in HBase
> >
> > I know some deletion in second loop may fail, but that's another topic.
> >
> > Thanks
> >
> > On Wed, May 19, 2010 at 5:21 PM, Jonathan Gray <jg...@facebook.com>
> > wrote:
> >
> > > I'm not sure I understand what you're asking or trying to do.
> > >
> > > Can you lay out the order of events / what you want to happen? I
> > don't see
> > > where you roll something back.
> > >
> > > Thanks.
> > >
> > > > -----Original Message-----
> > > > From: Ted Yu [mailto:yuzhihong@gmail.com]
> > > > Sent: Wednesday, May 19, 2010 4:53 PM
> > > > To: hbase-user@hadoop.apache.org
> > > > Subject: delete operation that can be rolled back
> > > >
> > > > Hi,
> > > > We are implementing delete operation that can be rolled back. I.e.
> > we
> > > > don't
> > > > want to delete particular row immediately before a set of rows are
> > > > processed.
> > > >
> > > > I want to get wisdom from the community for the best practice.
> > > >
> > > > Thanks
> > >
>
RE: delete operation that can be rolled back
Posted by Jonathan Gray <jg...@facebook.com>.
Why do you need a server-side, rollback-able delete? Seems like the client pseudo-code works fine as you describe. (mark the row deleted by adding it to a local list of rows to be deleted)
> -----Original Message-----
> From: Ted Yu [mailto:yuzhihong@gmail.com]
> Sent: Wednesday, May 19, 2010 5:28 PM
> To: user@hbase.apache.org
> Subject: Re: delete operation that can be rolled back
>
> pseudo code:
> for every row in a set
> mark the row deleted but not calling HBase delete
> if certain condition is satisfied, bail out of loop
> for every marked row in previous loop
> delete it in HBase
>
> I know some deletion in second loop may fail, but that's another topic.
>
> Thanks
>
> On Wed, May 19, 2010 at 5:21 PM, Jonathan Gray <jg...@facebook.com>
> wrote:
>
> > I'm not sure I understand what you're asking or trying to do.
> >
> > Can you lay out the order of events / what you want to happen? I
> don't see
> > where you roll something back.
> >
> > Thanks.
> >
> > > -----Original Message-----
> > > From: Ted Yu [mailto:yuzhihong@gmail.com]
> > > Sent: Wednesday, May 19, 2010 4:53 PM
> > > To: hbase-user@hadoop.apache.org
> > > Subject: delete operation that can be rolled back
> > >
> > > Hi,
> > > We are implementing delete operation that can be rolled back. I.e.
> we
> > > don't
> > > want to delete particular row immediately before a set of rows are
> > > processed.
> > >
> > > I want to get wisdom from the community for the best practice.
> > >
> > > Thanks
> >
Re: delete operation that can be rolled back
Posted by Ted Yu <yu...@gmail.com>.
pseudo code:
for every row in a set
mark the row deleted but not calling HBase delete
if certain condition is satisfied, bail out of loop
for every marked row in previous loop
delete it in HBase
I know some deletion in second loop may fail, but that's another topic.
Thanks
On Wed, May 19, 2010 at 5:21 PM, Jonathan Gray <jg...@facebook.com> wrote:
> I'm not sure I understand what you're asking or trying to do.
>
> Can you lay out the order of events / what you want to happen? I don't see
> where you roll something back.
>
> Thanks.
>
> > -----Original Message-----
> > From: Ted Yu [mailto:yuzhihong@gmail.com]
> > Sent: Wednesday, May 19, 2010 4:53 PM
> > To: hbase-user@hadoop.apache.org
> > Subject: delete operation that can be rolled back
> >
> > Hi,
> > We are implementing delete operation that can be rolled back. I.e. we
> > don't
> > want to delete particular row immediately before a set of rows are
> > processed.
> >
> > I want to get wisdom from the community for the best practice.
> >
> > Thanks
>
RE: delete operation that can be rolled back
Posted by Jonathan Gray <jg...@facebook.com>.
I'm not sure I understand what you're asking or trying to do.
Can you lay out the order of events / what you want to happen? I don't see where you roll something back.
Thanks.
> -----Original Message-----
> From: Ted Yu [mailto:yuzhihong@gmail.com]
> Sent: Wednesday, May 19, 2010 4:53 PM
> To: hbase-user@hadoop.apache.org
> Subject: delete operation that can be rolled back
>
> Hi,
> We are implementing delete operation that can be rolled back. I.e. we
> don't
> want to delete particular row immediately before a set of rows are
> processed.
>
> I want to get wisdom from the community for the best practice.
>
> Thanks