date:20180202

Re: Apache Phoenix integration

2018-02-02 Thread Flavio Pompermaier

This is a very great news! But what do you mean exactly with "Apache Drill
is off of it's fork"? When is this deeper integration going to be
released/integrated?
Will Phoenix (eventually) become just a Drill storage plugin, with huge
benefits for both?

On 2 Feb 2018 20:20, "James Taylor"  wrote:

> Good idea - a joint meetup would be great.
>
> On Fri, Feb 2, 2018 at 11:15 AM, Saurabh Mahapatra <
> saurabhmahapatr...@gmail.com> wrote:
>
>> This is absolutely great news! Thanks for sharing, James!
>>
>> We should have this as a presentation in one of our weekly Drill hangout
>> sessions.
>>
>> It’s about time for us to do a meetup. A joint meetup perhaps?
>>
>> Saurabh
>>
>> Sent from my iPhone
>>
>>
>>
>> > On Feb 2, 2018, at 11:13 AM, James Taylor 
>> wrote:
>> >
>> > There's also a much deeper integration between Phoenix + Drill (code
>> named
>> > Drillix) underway that should be possible to complete now that Apache
>> Drill
>> > is off of it's fork and on a later version of Apache Calcite. I'm hoping
>> > that the output of this will be a Phoenix adapter in Drill. See
>> > presentation here[1] and WIP code here[2].
>> >
>> > Thanks,
>> > James
>> >
>> > [1] http://phoenix.apache.org/presentations/Drillix.pdf
>> > [2] https://github.com/jacques-n/drill/tree/phoenix_plugin
>> >
>> >> On Fri, Feb 2, 2018 at 10:21 AM, Kunal Khatua 
>> wrote:
>> >>
>> >> That's great, Flavio!
>> >>
>> >> You can create a Google doc for review and share it on the user list.
>> >>
>> >> @Bridget handles the documentation on the Apache website, so she can do
>> >> the final touches and help it find a home on the website.
>> >>
>> >> -Original Message-
>> >> From: Flavio Pompermaier [mailto:pomperma...@okkam.it]
>> >> Sent: Friday, February 02, 2018 9:04 AM
>> >> To: u...@drill.apache.org
>> >> Cc: James Taylor 
>> >> Subject: Re: Apache Phoenix integration
>> >>
>> >> Eventually I made it to integrate Phoenix with Drill! I debugged
>> remotely
>> >> the drill-embedded via Eclipse and I discovered that the problem was
>> that
>> >> you need some extra jars to make it work!
>> >> Where can I write some documentation about debugging remotely Drill
>> from
>> >> Eclipse and integration with Drill?
>> >>
>> >> On Fri, Feb 2, 2018 at 5:28 PM, Flavio Pompermaier <
>> pomperma...@okkam.it>
>> >> wrote:
>> >>
>> >>> What is the fastest way to debug the JDBC plugin from Eclipse? I don't
>> >>> see anything in the logs that could help...
>> >>> Is it possible to connect directly to the external embedded drill
>> >>> running on my machine if I enable jmx?
>> >>> it seems that the JDBC connection is established correctly but Drill
>> >>> throws an Exception (that is not well unwrapped by Jersey):
>> >>>
>> >>> 2018-02-02 16:54:04,520 [qtp159619134-56] INFO
>> >>> o.a.p.q.ConnectionQueryServicesImpl
>> >>> - HConnection established. Stacktrace for informational purposes:
>> >>> hconnection-0x1b9fe9f8
>> >>> java.lang.Thread.getStackTrace(Thread.java:1552)
>> >>> org.apache.phoenix.util.LogUtil.getCallerStackTrace(LogUtil.java:55)
>> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl.openConnection(
>> >>> ConnectionQueryServicesImpl.java:410)
>> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl.access$400(
>> >>> ConnectionQueryServicesImpl.java:256)
>> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(
>> >>> ConnectionQueryServicesImpl.java:2408)
>> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(
>> >>> ConnectionQueryServicesImpl.java:2384)
>> >>> org.apache.phoenix.util.PhoenixContextExecutor.call(
>> >>> PhoenixContextExecutor.java:76)
>> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(
>> >>> ConnectionQueryServicesImpl.java:2384)
>> >>> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(
>> >>> PhoenixDriver.java:255)
>> >>> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(
>> >>> PhoenixEmbeddedDriver.java:150)
>> >>> org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:221)
>> >>> org.apache.commons.dbcp.DriverConnectionFactory.createConnection(
>> >>> DriverConnectionFactory.java:38)
>> >>> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(
>> >>> PoolableConnectionFactory.java:582)
>> >>> org.apache.commons.dbcp.BasicDataSource.validateConnectionFactory(
>> >>> BasicDataSource.java:1556)
>> >>> org.apache.commons.dbcp.BasicDataSource.createPoolableConnec
>> tionFactor
>> >>> y(BasicDataSource.java:1545)
>> >>> org.apache.commons.dbcp.BasicDataSource.createDataSource(
>> >>> BasicDataSource.java:1388)
>> >>> org.apache.commons.dbcp.BasicDataSource.getConnection(
>> >>> BasicDataSource.java:1044)
>> >>> org.apache.calcite.adapter.jdbc.JdbcUtils$DialectPool.
>> >>> get(JdbcUtils.java:73)
>> >>> org.apache.calcite.adapter.jdbc.JdbcSchema.createDialect(
>> >>> JdbcSchema.java:138)
>> >>>

Anonymous survey: Apache HBase 1.x Usage

2018-02-02 Thread Andrew Purtell

Please take this anonymous survey
 to 
let us know what version of Apache HBase 1.x you are using in production
now or are planning to use in production in the next year or so.

Multiple choices are allowed.

There is no "I'm not using 1.x" choice. Consider upgrading! (smile)

https://www.surveymonkey.com/r/8WQ8QY6


-- 
Best regards,
Andrew

Re: ROW_TIMESTAMP

2018-02-02 Thread Alberto Bengoa

Right. Will do in this way.

Thank you again. :-)


James Taylor wrote
> Yes, I think having your own LAST_UPDATED column would be the best option
> currently.
> 
> On Fri, Feb 2, 2018 at 1:18 PM, Alberto Bengoa 

> alberto@.com

> 
> wrote:
> 
>> Hello James,
>>
>> Thanks for replying.
>>
>> It really seems that PHOENIX-4552 potentially fits to my purpose. I'll
>> track
>> this JIRA to get updates about it.
>>
>> BTW, considering nowadays, there's no option except to update some date
>> type
>> field on client side every upsert?
>>
>> Thank you so much.
>>
>> Alberto
>>
>>
>> James Taylor wrote
>> > Hi Alberto,
>> > Sounds like you need PHOENIX-4552. If you agree, let's continue the
>> > discussion over there.
>> > Thanks,
>> > James
>> >
>> > On Fri, Feb 2, 2018 at 9:05 AM, Alberto Bengoa 
>>
>> > alberto@.com
>>
>> > 
>> > wrote:
>> >
>> >> Hello Folks,
>> >>
>> >> I'm working on a project where we need to identify when a row was
>> changed
>> >> (updated fields). I was wondering if ROW_TIMESTAMP would help me to
>> reach
>> >> this goal.
>> >>
>> >> I created the test table bellow, and inserted some data:
>> >>
>> >> create table test(
>> >>   a integer not null,
>> >>   b integer,
>> >>   last_update date not null
>> >>   CONSTRAINT PK PRIMARY KEY (a, last_update row_timestamp)
>> >> );
>> >>
>> >> upsert into test (a, b) values (1, 1);
>> >> upsert into test (a, b) values (2, 2);
>> >> upsert into test (a, b) values (3, 4);
>> >>
>> >> 0: jdbc:phoenix:> select * from test;
>> >> +++--+
>> >> | A  | B  |   LAST_UPDATE|
>> >> +++--+
>> >> | 1  | 1  | 2018-02-02 16:33:52.345  |
>> >> | 2  | 2  | 2018-02-02 16:33:56.714  |
>> >> | 3  | 4  | 2018-02-02 16:34:00.281  |
>> >> +++--+
>> >> 3 rows selected (0.041 seconds)
>> >>
>> >> So, I've tried to update B value where A = 3;
>> >>
>> >> 0: jdbc:phoenix:> upsert into test (a, b) values (3, 3);
>> >>
>> >> Then, I have one "new" row, not an updated row as I need:
>> >>
>> >> 0: jdbc:phoenix:> select * from test;
>> >> +++--+
>> >> | A  | B  |   LAST_UPDATE|
>> >> +++--+
>> >> | 1  | 1  | 2018-02-02 16:33:52.345  |
>> >> | 2  | 2  | 2018-02-02 16:33:56.714  |
>> >> | 3  | 4  | 2018-02-02 16:34:00.281  |
>> >> | 3  | 3  | 2018-02-02 16:36:31.890  |
>> >> +++--+
>> >> 4 rows selected (0.052 seconds)
>> >>
>> >> I understand that LAST_UPDATE column is part of the PRIMARY KEY and,
>> from
>> >> this perspective, it's in fact should be a NEW row. But, on the other
>> >> hand,
>> >> this not fits my case, because actually I'll have a new row after each
>> >> "update" (and I have lots of updates).
>> >>
>> >> There's any alternative to this on the Phoenix side? I was not
>> expecting
>> >> to have to call a now() function from client side all the time to
>> update
>> >> a
>> >> last_update field.
>> >>
>> >> Maybe another kind of CONSTRAINT that would be used?
>> >>
>> >> Phoenix version 4.7 here.
>> >>
>> >> Thanks in advanced!
>> >>
>> >> Cheers,
>> >> Alberto
>> >>
>> >>
>>
>>
>>
>>
>>
>> --
>> Sent from: http://apache-phoenix-user-list.1124778.n5.nabble.com/
>>





--
Sent from: http://apache-phoenix-user-list.1124778.n5.nabble.com/

Index table in SYSTEM.CATALOG without DATA_TABLE_NAME and INDEX_TYPE

2018-02-02 Thread William Shen

Hi everyone,

I am investigating a strange looking entry in our SYSTEM.CATALOG table. The
row is an index table (TABLE_TYPE = i) but it does not contain any other
index information (no DATA_TABLE_NAME and INDEX_TYPE, etc.).

Has anyone encountered similar situation, or is there any other way to
investigate how the entry was created?

By the way, is there any documentation available on the SYSTEM.CATALOG,
that I can check to make I am understanding the information in this table
correctly?

Thanks!

We are running Phoenix 4.10 (upgraded previous from 4.8 and from 4.6)
Here is a few more details on this strange "index":

SELECT * from system.catalog where table_schem = 'prod' and data_table_name
is null and TABLE_TYPE = 'i';

TENANT_ID

TABLE_SCHEMprod

TABLE_NAME RULES

COLUMN_NAME

COLUMN_FAMILY  IDX_ID_RULES

TABLE_SEQ_NUM  0

TABLE_TYPE i

PK_NAME

COLUMN_COUNT   null

SALT_BUCKETS   null

DATA_TABLE_NAME

INDEX_STATE

IMMUTABLE_ROWS

VIEW_STATEMENT

DEFAULT_COLUMN_FAMILY

DISABLE_WAL

MULTI_TENANT

VIEW_TYPE  null

VIEW_INDEX_ID  null

DATA_TYPE  null

COLUMN_SIZEnull

DECIMAL_DIGITS null

NULLABLE   null

ORDINAL_POSITION   null

SORT_ORDER null

ARRAY_SIZE null

VIEW_CONSTANT

IS_VIEW_REFERENCED

KEY_SEQnull

LINK_TYPE  1

TYPE_NAME

REMARKS

SELF_REFERENCING_COL_NAME

REF_GENERATION

BUFFER_LENGTH  null

NUM_PREC_RADIX null

COLUMN_DEF

SQL_DATA_TYPE  null

SQL_DATETIME_SUB   null

CHAR_OCTET_LENGTH  null

IS_NULLABLE

SCOPE_CATALOG

SCOPE_SCHEMA

SCOPE_TABLE

SOURCE_DATA_TYPE   null

IS_AUTOINCREMENT

INDEX_TYPE null

INDEX_DISABLE_TIMESTAMPnull

STORE_NULLS

BASE_COLUMN_COUNT  null

IS_ROW_TIMESTAMP

TRANSACTIONAL

UPDATE_CACHE_FREQUENCY null

IS_NAMESPACE_MAPPED

AUTO_PARTITION_SEQ

APPEND_ONLY_SCHEMA

GUIDE_POSTS_WIDTH  null

COLUMN_QUALIFIER

IMMUTABLE_STORAGE_SCHEME   null

ENCODING_SCHEMEnull

QUALIFIER_COUNTER  null


We actually have the normal-looking index  IDX_ID_RULES created for the
RULES table, here:

SELECT * from system.catalog where table_schem = 'prod' and data_table_name
= 'RULES' and TABLE_TYPE = 'i';

TENANT_ID

TABLE_SCHEMprod

TABLE_NAME IDX_ID_RULES

COLUMN_NAME

COLUMN_FAMILY

TABLE_SEQ_NUM  0

TABLE_TYPE i

PK_NAME

COLUMN_COUNT   4

SALT_BUCKETS   255

DATA_TABLE_NAMERULES

INDEX_STATEa

IMMUTABLE_ROWS false

VIEW_STATEMENT

DEFAULT_COLUMN_FAMILY

DISABLE_WALfalse

MULTI_TENANT   false

VIEW_TYPE  null

VIEW_INDEX_ID  null

DATA_TYPE  null

COLUMN_SIZEnull

DECIMAL_DIGITS null

NULLABLE   null

ORDINAL_POSITION   null

SORT_ORDER null

ARRAY_SIZE null

VIEW_CONSTANT

IS_VIEW_REFERENCED

KEY_SEQnull

LINK_TYPE  null

TYPE_NAME

REMARKS

SELF_REFERENCING_COL_NAME

REF_GENERATION

BUFFER_LENGTH  null

NUM_PREC_RADIX null

COLUMN_DEF

SQL_DATA_TYPE  null

SQL_DATETIME_SUB   null

CHAR_OCTET_LENGTH  null

IS_NULLABLE

SCOPE_CATALOG

SCOPE_SCHEMA

SCOPE_TABLE

SOURCE_DATA_TYPE   null

IS_AUTOINCREMENT

INDEX_TYPE 1

INDEX_DISABLE_TIMESTAMP0

STORE_NULLSfalse

BASE_COLUMN_COUNT  -1

IS_ROW_TIMESTAMP

TRANSACTIONAL  false

UPDATE_CACHE_FREQUENCY 0

IS_NAMESPACE_MAPPEDfalse

AUTO_PARTITION_SEQ

APPEND_ONLY_SCHEMA false

GUIDE_POSTS_WIDTH  null

COLUMN_QUALIFIER

IMMUTABLE_STORAGE_SCHEME   1

ENCODING_SCHEME2

QUALIFIER_COUNTER  null

Re: ROW_TIMESTAMP

2018-02-02 Thread James Taylor

Yes, I think having your own LAST_UPDATED column would be the best option
currently.

On Fri, Feb 2, 2018 at 1:18 PM, Alberto Bengoa 
wrote:

> Hello James,
>
> Thanks for replying.
>
> It really seems that PHOENIX-4552 potentially fits to my purpose. I'll
> track
> this JIRA to get updates about it.
>
> BTW, considering nowadays, there's no option except to update some date
> type
> field on client side every upsert?
>
> Thank you so much.
>
> Alberto
>
>
> James Taylor wrote
> > Hi Alberto,
> > Sounds like you need PHOENIX-4552. If you agree, let's continue the
> > discussion over there.
> > Thanks,
> > James
> >
> > On Fri, Feb 2, 2018 at 9:05 AM, Alberto Bengoa 
>
> > alberto@.com
>
> > 
> > wrote:
> >
> >> Hello Folks,
> >>
> >> I'm working on a project where we need to identify when a row was
> changed
> >> (updated fields). I was wondering if ROW_TIMESTAMP would help me to
> reach
> >> this goal.
> >>
> >> I created the test table bellow, and inserted some data:
> >>
> >> create table test(
> >>   a integer not null,
> >>   b integer,
> >>   last_update date not null
> >>   CONSTRAINT PK PRIMARY KEY (a, last_update row_timestamp)
> >> );
> >>
> >> upsert into test (a, b) values (1, 1);
> >> upsert into test (a, b) values (2, 2);
> >> upsert into test (a, b) values (3, 4);
> >>
> >> 0: jdbc:phoenix:> select * from test;
> >> +++--+
> >> | A  | B  |   LAST_UPDATE|
> >> +++--+
> >> | 1  | 1  | 2018-02-02 16:33:52.345  |
> >> | 2  | 2  | 2018-02-02 16:33:56.714  |
> >> | 3  | 4  | 2018-02-02 16:34:00.281  |
> >> +++--+
> >> 3 rows selected (0.041 seconds)
> >>
> >> So, I've tried to update B value where A = 3;
> >>
> >> 0: jdbc:phoenix:> upsert into test (a, b) values (3, 3);
> >>
> >> Then, I have one "new" row, not an updated row as I need:
> >>
> >> 0: jdbc:phoenix:> select * from test;
> >> +++--+
> >> | A  | B  |   LAST_UPDATE|
> >> +++--+
> >> | 1  | 1  | 2018-02-02 16:33:52.345  |
> >> | 2  | 2  | 2018-02-02 16:33:56.714  |
> >> | 3  | 4  | 2018-02-02 16:34:00.281  |
> >> | 3  | 3  | 2018-02-02 16:36:31.890  |
> >> +++--+
> >> 4 rows selected (0.052 seconds)
> >>
> >> I understand that LAST_UPDATE column is part of the PRIMARY KEY and,
> from
> >> this perspective, it's in fact should be a NEW row. But, on the other
> >> hand,
> >> this not fits my case, because actually I'll have a new row after each
> >> "update" (and I have lots of updates).
> >>
> >> There's any alternative to this on the Phoenix side? I was not expecting
> >> to have to call a now() function from client side all the time to update
> >> a
> >> last_update field.
> >>
> >> Maybe another kind of CONSTRAINT that would be used?
> >>
> >> Phoenix version 4.7 here.
> >>
> >> Thanks in advanced!
> >>
> >> Cheers,
> >> Alberto
> >>
> >>
>
>
>
>
>
> --
> Sent from: http://apache-phoenix-user-list.1124778.n5.nabble.com/
>

Re: ROW_TIMESTAMP

2018-02-02 Thread Alberto Bengoa

Hello James,

Thanks for replying.

It really seems that PHOENIX-4552 potentially fits to my purpose. I'll track
this JIRA to get updates about it.

BTW, considering nowadays, there's no option except to update some date type
field on client side every upsert? 

Thank you so much.

Alberto


James Taylor wrote
> Hi Alberto,
> Sounds like you need PHOENIX-4552. If you agree, let's continue the
> discussion over there.
> Thanks,
> James
> 
> On Fri, Feb 2, 2018 at 9:05 AM, Alberto Bengoa 

> alberto@.com

> 
> wrote:
> 
>> Hello Folks,
>>
>> I'm working on a project where we need to identify when a row was changed
>> (updated fields). I was wondering if ROW_TIMESTAMP would help me to reach
>> this goal.
>>
>> I created the test table bellow, and inserted some data:
>>
>> create table test(
>>   a integer not null,
>>   b integer,
>>   last_update date not null
>>   CONSTRAINT PK PRIMARY KEY (a, last_update row_timestamp)
>> );
>>
>> upsert into test (a, b) values (1, 1);
>> upsert into test (a, b) values (2, 2);
>> upsert into test (a, b) values (3, 4);
>>
>> 0: jdbc:phoenix:> select * from test;
>> +++--+
>> | A  | B  |   LAST_UPDATE|
>> +++--+
>> | 1  | 1  | 2018-02-02 16:33:52.345  |
>> | 2  | 2  | 2018-02-02 16:33:56.714  |
>> | 3  | 4  | 2018-02-02 16:34:00.281  |
>> +++--+
>> 3 rows selected (0.041 seconds)
>>
>> So, I've tried to update B value where A = 3;
>>
>> 0: jdbc:phoenix:> upsert into test (a, b) values (3, 3);
>>
>> Then, I have one "new" row, not an updated row as I need:
>>
>> 0: jdbc:phoenix:> select * from test;
>> +++--+
>> | A  | B  |   LAST_UPDATE|
>> +++--+
>> | 1  | 1  | 2018-02-02 16:33:52.345  |
>> | 2  | 2  | 2018-02-02 16:33:56.714  |
>> | 3  | 4  | 2018-02-02 16:34:00.281  |
>> | 3  | 3  | 2018-02-02 16:36:31.890  |
>> +++--+
>> 4 rows selected (0.052 seconds)
>>
>> I understand that LAST_UPDATE column is part of the PRIMARY KEY and, from
>> this perspective, it's in fact should be a NEW row. But, on the other
>> hand,
>> this not fits my case, because actually I'll have a new row after each
>> "update" (and I have lots of updates).
>>
>> There's any alternative to this on the Phoenix side? I was not expecting
>> to have to call a now() function from client side all the time to update
>> a
>> last_update field.
>>
>> Maybe another kind of CONSTRAINT that would be used?
>>
>> Phoenix version 4.7 here.
>>
>> Thanks in advanced!
>>
>> Cheers,
>> Alberto
>>
>>





--
Sent from: http://apache-phoenix-user-list.1124778.n5.nabble.com/

Re: Apache Phoenix integration

2018-02-02 Thread James Taylor

Good idea - a joint meetup would be great.

On Fri, Feb 2, 2018 at 11:15 AM, Saurabh Mahapatra <
saurabhmahapatr...@gmail.com> wrote:

> This is absolutely great news! Thanks for sharing, James!
>
> We should have this as a presentation in one of our weekly Drill hangout
> sessions.
>
> It’s about time for us to do a meetup. A joint meetup perhaps?
>
> Saurabh
>
> Sent from my iPhone
>
>
>
> > On Feb 2, 2018, at 11:13 AM, James Taylor 
> wrote:
> >
> > There's also a much deeper integration between Phoenix + Drill (code
> named
> > Drillix) underway that should be possible to complete now that Apache
> Drill
> > is off of it's fork and on a later version of Apache Calcite. I'm hoping
> > that the output of this will be a Phoenix adapter in Drill. See
> > presentation here[1] and WIP code here[2].
> >
> > Thanks,
> > James
> >
> > [1] http://phoenix.apache.org/presentations/Drillix.pdf
> > [2] https://github.com/jacques-n/drill/tree/phoenix_plugin
> >
> >> On Fri, Feb 2, 2018 at 10:21 AM, Kunal Khatua  wrote:
> >>
> >> That's great, Flavio!
> >>
> >> You can create a Google doc for review and share it on the user list.
> >>
> >> @Bridget handles the documentation on the Apache website, so she can do
> >> the final touches and help it find a home on the website.
> >>
> >> -Original Message-
> >> From: Flavio Pompermaier [mailto:pomperma...@okkam.it]
> >> Sent: Friday, February 02, 2018 9:04 AM
> >> To: u...@drill.apache.org
> >> Cc: James Taylor 
> >> Subject: Re: Apache Phoenix integration
> >>
> >> Eventually I made it to integrate Phoenix with Drill! I debugged
> remotely
> >> the drill-embedded via Eclipse and I discovered that the problem was
> that
> >> you need some extra jars to make it work!
> >> Where can I write some documentation about debugging remotely Drill from
> >> Eclipse and integration with Drill?
> >>
> >> On Fri, Feb 2, 2018 at 5:28 PM, Flavio Pompermaier <
> pomperma...@okkam.it>
> >> wrote:
> >>
> >>> What is the fastest way to debug the JDBC plugin from Eclipse? I don't
> >>> see anything in the logs that could help...
> >>> Is it possible to connect directly to the external embedded drill
> >>> running on my machine if I enable jmx?
> >>> it seems that the JDBC connection is established correctly but Drill
> >>> throws an Exception (that is not well unwrapped by Jersey):
> >>>
> >>> 2018-02-02 16:54:04,520 [qtp159619134-56] INFO
> >>> o.a.p.q.ConnectionQueryServicesImpl
> >>> - HConnection established. Stacktrace for informational purposes:
> >>> hconnection-0x1b9fe9f8
> >>> java.lang.Thread.getStackTrace(Thread.java:1552)
> >>> org.apache.phoenix.util.LogUtil.getCallerStackTrace(LogUtil.java:55)
> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl.openConnection(
> >>> ConnectionQueryServicesImpl.java:410)
> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl.access$400(
> >>> ConnectionQueryServicesImpl.java:256)
> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(
> >>> ConnectionQueryServicesImpl.java:2408)
> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(
> >>> ConnectionQueryServicesImpl.java:2384)
> >>> org.apache.phoenix.util.PhoenixContextExecutor.call(
> >>> PhoenixContextExecutor.java:76)
> >>> org.apache.phoenix.query.ConnectionQueryServicesImpl.init(
> >>> ConnectionQueryServicesImpl.java:2384)
> >>> org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(
> >>> PhoenixDriver.java:255)
> >>> org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(
> >>> PhoenixEmbeddedDriver.java:150)
> >>> org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:221)
> >>> org.apache.commons.dbcp.DriverConnectionFactory.createConnection(
> >>> DriverConnectionFactory.java:38)
> >>> org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(
> >>> PoolableConnectionFactory.java:582)
> >>> org.apache.commons.dbcp.BasicDataSource.validateConnectionFactory(
> >>> BasicDataSource.java:1556)
> >>> org.apache.commons.dbcp.BasicDataSource.createPoolableConnectionFactor
> >>> y(BasicDataSource.java:1545)
> >>> org.apache.commons.dbcp.BasicDataSource.createDataSource(
> >>> BasicDataSource.java:1388)
> >>> org.apache.commons.dbcp.BasicDataSource.getConnection(
> >>> BasicDataSource.java:1044)
> >>> org.apache.calcite.adapter.jdbc.JdbcUtils$DialectPool.
> >>> get(JdbcUtils.java:73)
> >>> org.apache.calcite.adapter.jdbc.JdbcSchema.createDialect(
> >>> JdbcSchema.java:138)
> >>> org.apache.drill.exec.store.jdbc.JdbcStoragePlugin.(
> >>> JdbcStoragePlugin.java:103)
> >>> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> >>> sun.reflect.NativeConstructorAccessorImpl.newInstance(
> >>> NativeConstructorAccessorImpl.java:62)
> >>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
> >>> DelegatingConstructorAccessorImpl.java:45)
> >>> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> >>>

Re: Apache Phoenix integration

2018-02-02 Thread James Taylor

There's also a much deeper integration between Phoenix + Drill (code named
Drillix) underway that should be possible to complete now that Apache Drill
is off of it's fork and on a later version of Apache Calcite. I'm hoping
that the output of this will be a Phoenix adapter in Drill. See
presentation here[1] and WIP code here[2].

Thanks,
James

[1] http://phoenix.apache.org/presentations/Drillix.pdf
[2] https://github.com/jacques-n/drill/tree/phoenix_plugin

On Fri, Feb 2, 2018 at 10:21 AM, Kunal Khatua  wrote:

> That's great, Flavio!
>
> You can create a Google doc for review and share it on the user list.
>
> @Bridget handles the documentation on the Apache website, so she can do
> the final touches and help it find a home on the website.
>
> -Original Message-
> From: Flavio Pompermaier [mailto:pomperma...@okkam.it]
> Sent: Friday, February 02, 2018 9:04 AM
> To: u...@drill.apache.org
> Cc: James Taylor 
> Subject: Re: Apache Phoenix integration
>
> Eventually I made it to integrate Phoenix with Drill! I debugged remotely
> the drill-embedded via Eclipse and I discovered that the problem was that
> you need some extra jars to make it work!
> Where can I write some documentation about debugging remotely Drill from
> Eclipse and integration with Drill?
>
> On Fri, Feb 2, 2018 at 5:28 PM, Flavio Pompermaier 
> wrote:
>
> > What is the fastest way to debug the JDBC plugin from Eclipse? I don't
> > see anything in the logs that could help...
> > Is it possible to connect directly to the external embedded drill
> > running on my machine if I enable jmx?
> > it seems that the JDBC connection is established correctly but Drill
> > throws an Exception (that is not well unwrapped by Jersey):
> >
> > 2018-02-02 16:54:04,520 [qtp159619134-56] INFO
> > o.a.p.q.ConnectionQueryServicesImpl
> > - HConnection established. Stacktrace for informational purposes:
> > hconnection-0x1b9fe9f8
> > java.lang.Thread.getStackTrace(Thread.java:1552)
> > org.apache.phoenix.util.LogUtil.getCallerStackTrace(LogUtil.java:55)
> > org.apache.phoenix.query.ConnectionQueryServicesImpl.openConnection(
> > ConnectionQueryServicesImpl.java:410)
> > org.apache.phoenix.query.ConnectionQueryServicesImpl.access$400(
> > ConnectionQueryServicesImpl.java:256)
> > org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(
> > ConnectionQueryServicesImpl.java:2408)
> > org.apache.phoenix.query.ConnectionQueryServicesImpl$12.call(
> > ConnectionQueryServicesImpl.java:2384)
> > org.apache.phoenix.util.PhoenixContextExecutor.call(
> > PhoenixContextExecutor.java:76)
> > org.apache.phoenix.query.ConnectionQueryServicesImpl.init(
> > ConnectionQueryServicesImpl.java:2384)
> > org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(
> > PhoenixDriver.java:255)
> > org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(
> > PhoenixEmbeddedDriver.java:150)
> > org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:221)
> > org.apache.commons.dbcp.DriverConnectionFactory.createConnection(
> > DriverConnectionFactory.java:38)
> > org.apache.commons.dbcp.PoolableConnectionFactory.makeObject(
> > PoolableConnectionFactory.java:582)
> > org.apache.commons.dbcp.BasicDataSource.validateConnectionFactory(
> > BasicDataSource.java:1556)
> > org.apache.commons.dbcp.BasicDataSource.createPoolableConnectionFactor
> > y(BasicDataSource.java:1545)
> > org.apache.commons.dbcp.BasicDataSource.createDataSource(
> > BasicDataSource.java:1388)
> > org.apache.commons.dbcp.BasicDataSource.getConnection(
> > BasicDataSource.java:1044)
> > org.apache.calcite.adapter.jdbc.JdbcUtils$DialectPool.
> > get(JdbcUtils.java:73)
> > org.apache.calcite.adapter.jdbc.JdbcSchema.createDialect(
> > JdbcSchema.java:138)
> > org.apache.drill.exec.store.jdbc.JdbcStoragePlugin.(
> > JdbcStoragePlugin.java:103)
> > sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> > sun.reflect.NativeConstructorAccessorImpl.newInstance(
> > NativeConstructorAccessorImpl.java:62)
> > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
> > DelegatingConstructorAccessorImpl.java:45)
> > java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> > org.apache.drill.exec.store.StoragePluginRegistryImpl.create(
> > StoragePluginRegistryImpl.java:346)
> > org.apache.drill.exec.store.StoragePluginRegistryImpl.createOrUpdate(
> > StoragePluginRegistryImpl.java:239)
> > org.apache.drill.exec.server.rest.PluginConfigWrapper.
> > createOrUpdateInStorage(PluginConfigWrapper.java:57)
> > org.apache.drill.exec.server.rest.StorageResources.
> > createOrUpdatePluginJSON(StorageResources.java:162)
> > org.apache.drill.exec.server.rest.StorageResources.createOrUpdatePlugi
> > n(
> > StorageResources.java:177)
> > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:
> > 62)
> >

Re: ROW_TIMESTAMP

2018-02-02 Thread James Taylor

Hi Alberto,
Sounds like you need PHOENIX-4552. If you agree, let's continue the
discussion over there.
Thanks,
James

On Fri, Feb 2, 2018 at 9:05 AM, Alberto Bengoa 
wrote:

> Hello Folks,
>
> I'm working on a project where we need to identify when a row was changed
> (updated fields). I was wondering if ROW_TIMESTAMP would help me to reach
> this goal.
>
> I created the test table bellow, and inserted some data:
>
> create table test(
>   a integer not null,
>   b integer,
>   last_update date not null
>   CONSTRAINT PK PRIMARY KEY (a, last_update row_timestamp)
> );
>
> upsert into test (a, b) values (1, 1);
> upsert into test (a, b) values (2, 2);
> upsert into test (a, b) values (3, 4);
>
> 0: jdbc:phoenix:> select * from test;
> +++--+
> | A  | B  |   LAST_UPDATE|
> +++--+
> | 1  | 1  | 2018-02-02 16:33:52.345  |
> | 2  | 2  | 2018-02-02 16:33:56.714  |
> | 3  | 4  | 2018-02-02 16:34:00.281  |
> +++--+
> 3 rows selected (0.041 seconds)
>
> So, I've tried to update B value where A = 3;
>
> 0: jdbc:phoenix:> upsert into test (a, b) values (3, 3);
>
> Then, I have one "new" row, not an updated row as I need:
>
> 0: jdbc:phoenix:> select * from test;
> +++--+
> | A  | B  |   LAST_UPDATE|
> +++--+
> | 1  | 1  | 2018-02-02 16:33:52.345  |
> | 2  | 2  | 2018-02-02 16:33:56.714  |
> | 3  | 4  | 2018-02-02 16:34:00.281  |
> | 3  | 3  | 2018-02-02 16:36:31.890  |
> +++--+
> 4 rows selected (0.052 seconds)
>
> I understand that LAST_UPDATE column is part of the PRIMARY KEY and, from
> this perspective, it's in fact should be a NEW row. But, on the other hand,
> this not fits my case, because actually I'll have a new row after each
> "update" (and I have lots of updates).
>
> There's any alternative to this on the Phoenix side? I was not expecting
> to have to call a now() function from client side all the time to update a
> last_update field.
>
> Maybe another kind of CONSTRAINT that would be used?
>
> Phoenix version 4.7 here.
>
> Thanks in advanced!
>
> Cheers,
> Alberto
>
>

ROW_TIMESTAMP

2018-02-02 Thread Alberto Bengoa

Hello Folks,

I'm working on a project where we need to identify when a row was changed
(updated fields). I was wondering if ROW_TIMESTAMP would help me to reach
this goal.

I created the test table bellow, and inserted some data:

create table test(
  a integer not null,
  b integer,
  last_update date not null
  CONSTRAINT PK PRIMARY KEY (a, last_update row_timestamp)
);

upsert into test (a, b) values (1, 1);
upsert into test (a, b) values (2, 2);
upsert into test (a, b) values (3, 4);

0: jdbc:phoenix:> select * from test;
+++--+
| A  | B  |   LAST_UPDATE|
+++--+
| 1  | 1  | 2018-02-02 16:33:52.345  |
| 2  | 2  | 2018-02-02 16:33:56.714  |
| 3  | 4  | 2018-02-02 16:34:00.281  |
+++--+
3 rows selected (0.041 seconds)

So, I've tried to update B value where A = 3;

0: jdbc:phoenix:> upsert into test (a, b) values (3, 3);

Then, I have one "new" row, not an updated row as I need:

0: jdbc:phoenix:> select * from test;
+++--+
| A  | B  |   LAST_UPDATE|
+++--+
| 1  | 1  | 2018-02-02 16:33:52.345  |
| 2  | 2  | 2018-02-02 16:33:56.714  |
| 3  | 4  | 2018-02-02 16:34:00.281  |
| 3  | 3  | 2018-02-02 16:36:31.890  |
+++--+
4 rows selected (0.052 seconds)

I understand that LAST_UPDATE column is part of the PRIMARY KEY and, from
this perspective, it's in fact should be a NEW row. But, on the other hand,
this not fits my case, because actually I'll have a new row after each
"update" (and I have lots of updates).

There's any alternative to this on the Phoenix side? I was not expecting to
have to call a now() function from client side all the time to update a
last_update field.

Maybe another kind of CONSTRAINT that would be used?

Phoenix version 4.7 here.

Thanks in advanced!

Cheers,
Alberto

Re: Apache Phoenix integration

Anonymous survey: Apache HBase 1.x Usage

Re: ROW_TIMESTAMP

Index table in SYSTEM.CATALOG without DATA_TABLE_NAME and INDEX_TYPE

Re: ROW_TIMESTAMP

Re: ROW_TIMESTAMP

Re: Apache Phoenix integration

Re: Apache Phoenix integration

Re: ROW_TIMESTAMP

ROW_TIMESTAMP

10 matches

Site Navigation

Mail list logo

Footer information