hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gerke Ephorus <gerke.epho...@gmail.com>
Subject Re: org.apache.hadoop.hbase.client.HTable.exists changes my Get-object
Date Thu, 06 Nov 2014 07:55:23 GMT
Hi St.Ack,

thanks for the quick reply.

Three things (hope I counted right):
* we used the API that was available in 0.92.x which already allowed
specifying more than just the row-key. We specifically check for existence
of a cell via a ROWCOL bloom-filter.
* Is the *get* in 0.98.x just as fast as using an *exists* followed by a
*get* upon-exists-returning-true? (the sole reason for using
exists-before-get in some cases)
* I filled an issue for the challenge with the exists call:
https://issues.apache.org/jira/browse/HBASE-9612.

Thanks,
Gerke


On Thu, Nov 6, 2014 at 2:48 AM, Stack <stack@duboce.net> wrote:

> The cited exists has been around a while:
> https://issues.apache.org/jira/browse/HBASE-1544
>
> You used to use this this one?
>
> + * @deprecated As of hbase 0.20.0, replaced by {@link #exists(Get)}
> */
> public boolean exists(final byte [] row) throws IOException {
>
> They do the same thing essentially.
>
> The fact that we are changing the passed in Get should minimally be
> documented in API.  We shouldn't.  Its a bug. Easy to fix.  Want to file an
> issue?
>
> Thanks,
> St.Ack
>
>
> On Wed, Nov 5, 2014 at 7:53 AM, Gerke Ephorus <gerke.ephorus@gmail.com>
> wrote:
>
> > Hi all,
> >
> > we are in the process of upgrading HBase from 0.92.x to 0.98.6.x and run
> > into this code in the HBase-client:
> >   /**
> >    * {@inheritDoc}
> >    */
> >   @Override
> >   public boolean exists(final Get get) throws IOException {
> >     get.setCheckExistenceOnly(true);
> >     Result r = get(get);
> >     assert r.getExists() != null;
> >     return r.getExists();
> >   }
> >
> > We used to use this exists-call as this was way faster in case of a
> > BloomFilter-miss. But maybe that has changed?
> >
> > The code shows that the get-object passed-in is changed. Now I understand
> > that it might not make sense to re-use the get-object after the exists
> > returns true, but I explained the reason for doing so anyway above.
> >
> > Can anyone throw some light on this, please?
> >
> > I was just wondering if it might make sense to add a notice in the
> API-doc
> > that tell that the passed-in object will be changed during the call. Or
> > maybe add a 'set-back-to-old-value' try-finally-construction.
> >
> > with kind regards,
> > Gerke
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message