Re: Multi-Tenancy and shared records

[Billy Watson]

I ran into this too with other code. Make sure you’re on the same API.
HBase 2’s APIs changed heavily so you may have to do some googling for docs
to convert the above code into something usable in your version of the
HBase API.

Also for your original problem, I’m not sure if Apache Ranger supports
row-level yet in their HBase plugin but you can certainly add that
functionality to make what you’re talking about a LOT easier to maintain.

Good luck,

Billy Watson

On Tue, Oct 15, 2019 at 23:05 Simon Mottram 
wrote:

> Hi Ankit
>
> Getting stuck into this, but I am having trouble finding out how to
> persist the ACL mutations
>
> The updates to the mutations aren't being persisted as far as I can
> tell.  I see in your code you are using htable.batch().
>
> I'm struggling to find a way to that object,  I can get a PTable from
> the connection using the byte[] tablename but PTable doesn't have the
> batch() method.
>
> I'm also unclear on how the htable.batch() method works with
> connection.commit().  Is commit required?
>
> I have a horrible feeling that the mutations require an Hbase
> connection rather than Phoenix and I have to go direct to Hbase API
>
> Best Regards and thanks for the help
>
> Simon
>
>
> On Wed, 2019-09-04 at 19:06 -0700, Ankit Singhal wrote:
> > >>would it be best to
> > use the HBase API for creating the data.
> > yes, you can use HBase API but you need to ensure that Phoenix Data
> > type APIs are used to
> > convert your column values into bytes and also while creating a
> > composite key(if applicable).
> > otherwise you would not be able to read data from Phoenix when using
> > different data types
> > other than varchar or unsigned_bigint.
> >
> > >> The sparse nature of the data means
> > that I will be constantly adding new columns, not sure if Phoenix
> > would
> > have a problem with that.
> > Phoenix supports dynamic columns so you should not have a problem
> > with that.
> >
> > Regards,
> > Ankit Singhal
> >
> > On Wed, Sep 4, 2019 at 6:24 PM Simon Mottram <
> > simon.mott...@cucumber.co.nz> wrote:
> > > Hi Ankit
> > >
> > > Thats very useful, many thanks.
> > >
> > > Before I dive into using Phoenix (which has given me a torrid time
> > > over
> > > the last few days!), is using Phoenix the best option given that
> > > I'm
> > > doing some low level access to Cell information, or would it be
> > > best to
> > > use the HBase API for creating the data.
> > >
> > > We would of course use Phoenix for querying the tables, I'm just
> > > wondering if the import of data would be better handled via the
> > > native
> > > HBase API.
> > >
> > > I think I only need to set labels or use the ACL system, everything
> > > else should be straight forward.  The sparse nature of the data
> > > means
> > > that I will be constantly adding new columns, not sure if Phoenix
> > > would
> > > have a problem with that.
> > >
> > > Best Regards
> > >
> > > Simon
> > >
> > > On Tue, 2019-09-03 at 16:30 -0700, Ankit Singhal wrote:
> > > > >> If not possible I guess we have to look at doing something at
> > > the
> > > > HBase
> > > > level.
> > > > As Josh said, it's not yet supported in Phoenix, Though you may
> > > try
> > > > using cell-level security of HBase with some Phoenix internal API
> > > and
> > > > let us know if it works for you.
> > > > Sharing a sample code if you wanna try.
> > > >
> > > > /**
> > > > * Do writes using cell based ACLs
> > > > **/
> > > > Properties props = new Properties();
> > > > //conf = Hbase conf
> > > > PhoenixConnection conn = (PhoenixConnection)
> > > > QueryUtil.getConnection(props, conf);
> > > > conn.setAutoCommit(false);
> > > > conn.createStatement().executeUpdate("");
> > > > final Iterator>> iterator =
> > > > pconn.getMutationState().toMutations(false);
> > > > while (iterator.hasNext()) {
> > > > Pair> kvPair = iterator.next();
> > > > List mutationList = kvPair.getSecond();
> > > > byte[] tableName = kvPair.getFirst();
> > > > for (Mutation mutation : mutationList) {
> > > > //perms is user->permissions map
> > > >  

Re: Phoenix 4.2.2log files

[Billy Watson]

phoenix should log to the hbase logs, if I'm not mistaken

William Watson
Software Engineer
(904) 705-7056 PCS

On Mon, Jan 11, 2016 at 7:34 AM, Gaurav Agarwal 
wrote:

> Hi
> I am using hep sandbox trying to find where to find the log files of
> phoenix .
> Any idea how to log the information
>

Re: Timezones in Phoenix

[Billy Watson]

The unsigned date specifically says, The purpose of this type is to map to
existing HBase data that was serialized using this HBase utility method.
When you stored these values, did you use that method? According to the
docs, If that is not the case, use the regular signed type instead.

I'm not an expert on those data types, but I hope that helps.

William Watson
Software Engineer
(904) 705-7056 PCS

On Thu, Apr 16, 2015 at 7:08 AM, Matthew Johnson matt.john...@algomi.com
wrote:

 Hi all,



 I have a bunch of millisecond timestamps stored in HBase as Long values. I
 have a Phoenix view that reads these values as an UNSIGNED_DATE. Now that
 the clocks have gone forwards, the Phoenix driver has automatically applied
 the timezone change and as a result all of my Long values are being
 converted an hour off. Is there a way to set the timezone in Phoenix so
 that it will read the longs to dates as GMT+ (since this is what the
 millisecond values represent).



 Or, should I create a new view and create it to return an UNSIGNED_LONG,
 and then use the ‘to_date’ function and pass in a timezone? This is less
 convenient as it would mean using the function everywhere where we have
 queries, but is an option.



 Thanks,

 Matt

Re: Querying pre existing HBase table

[Billy Watson]

Just to not steer you in the wrong direction, you do have to create a
table, but you do not have to tell phoenix every column you're going to
query on as of Phoenix 1.2.

http://phoenix.apache.org/dynamic_columns.html

So yes, phoenix needs to know the types, but it doesn't have to know them
up front, FWIW. I'm not sure of your exact use case, obviously.

William Watson
Software Engineer
(904) 705-7056 PCS

On Tue, Apr 7, 2015 at 12:57 PM, anil gupta anilgupt...@gmail.com wrote:

 No, You need to at least define a view for that table. Phoenix wouldnt
 know how to read columns/rowkeys of your table.

 On Tue, Apr 7, 2015 at 4:00 AM, Bradman, Dale dale.brad...@capgemini.com
 wrote:

  Hello,

  Is it possible to issue a SELECT statement on a pre existing HBase
 table without having to create a Phoenix table/view on top of the HBase
 table?

  Thanks, Dale.
 This message contains information that may be privileged or confidential
 and is the property of the Capgemini Group. It is intended only for the
 person to whom it is addressed. If you are not the intended recipient, you
 are not authorized to read, print, retain, copy, disseminate, distribute,
 or use this message or any part thereof. If you receive this message in
 error, please notify the sender immediately and delete all copies of this
 message.




 --
 Thanks  Regards,
 Anil Gupta