We are exploring using a JPA implementation to persist objects into HBase
using Phoenix SQL. Curious to know if anyone is exploring the same.
Appreciate the sync-up.
Baahu, did you change just the pom or the above said source code too?
On Fri, Jun 12, 2015 at 1:11 AM, Bahubali Jain wrote:
> Thanks Sun...now its working.
> For others, below are the changes I did in the pom.xml
> 1.0.0-cdh5.4.2
> 2.6.0-cdh5.4.2
> 2.6.0-cdh5.4.2
>
> Thanks,
> Baahu
>
> On
I'm getting this when I use sqlline.
I compiled phoenix4.4 with cdh5.4 along with code changes and pom changes.
Any clue? Appreciate your time.
Error: ERROR 103 (08004): Unable to establish connection.
(state=08004,code=103)
java.sql.SQLException: ERROR 103 (08004): Unable to establish connec
Re-sending with the subject.
On Sun, Jun 21, 2015 at 3:51 PM, Kumar Palaniappan <
kpalaniap...@marinsoftware.com> wrote:
> I'm getting this when I use sqlline.
>
> I compiled phoenix4.4 with cdh5.4 along with code changes and pom changes.
>
> Any clue? Appreciate your
I'm in the same exact position as Zack described. Appreciate your feedback.
So far we tried the call queue n the handlers, nope. Planned to try off-heap
cache.
Kumar Palaniappan
> On Dec 4, 2015, at 6:45 AM, Riesland, Zack wrote:
>
> Thanks Satish,
>
> To clarify
ush.
>
>
> On Dec 4, 2015, at 1:27 PM, Kumar Palaniappan <
> kpalaniap...@marinsoftware.com> wrote:
>
> working on getting it. the problem is where to store the file...working
> with our IT :(
>
> It's on your way.
>
> On Fri, Dec 4, 2015 at 1:23 PM, And
We have a table with a data type BIGINT[], Since phoenix doesnt support to
index this data type, our queries are doing a full table scan when we have
to do filtering on this field.
What are the alternate approaches? Tried looking into Views, but nope.
Appreciate your time.
Kumar
lowing query would use the index:
> SELECT K FROM T WHERE A[3] = 5;
>
> Does this help for your usage?
>
> Thanks,
> James
>
> On Tue, Jan 5, 2016 at 2:51 PM, Kumar Palaniappan <
> kpalaniap...@marinsoftware.com> wrote:
>
>>
>>
>> We have a t
y.
>
> You could still efficiently iterate over the account of a given customer
> too:
> SELECT * FROM T WHERE CID=?
> but your application would need to know that the first row would be the
> customer row and the next rows would contain only the account IDs for that
> custome
Thanks James. We will look into it. we need to find a way to overcome the
full scan.
On Wed, Jan 6, 2016 at 9:26 AM, James Taylor wrote:
> In that case, you'd need PHOENIX-1544 to be implemented.
>
> On Wed, Jan 6, 2016 at 8:52 AM, Kumar Palaniappan <
> kpalaniap...@mari
We have a table
*create table t1 ( a bigint not null, a1 bigint not null, b bigint not
null, c varchar, d varchar pk_constraint "t1_pk" (a, a1,b))*
create a global indices as -
*create index id_t1 on t1 (b) include (a,a1,c,d)* - this one is to speed up
filtering on b since it is the last elemen
Thanks James.
Do we need an index on a pk column, since it's a last element in the rowkey, to
speed up the query? ( because of this, write won't be impacted on that table)
we do leverage the call queue.
Kumar Palaniappan
> On Jan 18, 2016, at 10:07 AM, James Taylor wrote:
&
Andrew, any updates? Seem HBase-11544 impacted the Phoenix and CDH 5.5.1
isnt working.
On Sun, Jan 17, 2016 at 11:25 AM, Andrew Purtell
wrote:
> This looks like something easy to fix up. Maybe I can get to it next week.
>
> > On Jan 15, 2016, at 9:07 PM, Krishna wrote:
> >
> > On the branch: 4
5).
>
>
> On Thu, Jan 28, 2016 at 11:23 AM, Andrew Purtell
> wrote:
>
>> Looking today
>>
>>
>> On Tue, Jan 26, 2016 at 11:00 PM, Kumar Palaniappan <
>> kpalaniap...@marinsoftware.com> wrote:
>>
>>> Andrew, any updates? Seem HBase-115
While data migration, we simply drop the indices on the tables and
recreate. Would like to avoid.
Is there disable all index syntax in phoenix grammar? How do we disable an
index? If we disable index in phoenix and rebuild what does that translates
to phoenix intercepting WAL? We know rebuilding i
What is an easy solution or is there a solution to clone the table/schema
in phoenix?
Thanks in advance.
It's not about data. Would like to clone just the table structure(s) under the
schema partially or entire tables.
Kumar Palaniappan
> On Sep 8, 2016, at 5:48 PM, dalin.qin wrote:
>
> try this:
>
> 0: jdbc:phoenix:namenode:2181:/hbase-unsecure> CREATE TABLE TABLE1
Yes, we found a way to do off of system.catalog
In the meantime, trying to to explore are there any off the
shelves options.
Thanks dalin.
Kumar Palaniappan
> On Sep 8, 2016, at 6:43 PM, dalin.qin wrote:
>
> Hi Kumar,
>
> I believe right now there is no way to directly g
Yes James.
Kumar Palaniappan
> On Sep 9, 2016, at 12:53 AM, Heather, James (ELS-LON)
> wrote:
>
> This does rather suggest that it would be fairly easy to implement a SHOW
> CREATE TABLE statement. Is that right?
>
> It would be useful if so.
>
> James
>
Will do James.
On Fri, Sep 9, 2016 at 10:27 AM, James Taylor
wrote:
> Good idea - this would make a great contribution. Please file a JIRA.
>
> On Fri, Sep 9, 2016 at 6:29 AM, Kumar Palaniappan <
> kpalaniap...@marinsoftware.com> wrote:
>
>> Yes James.
>>
>
Any one had faced this issue?
https://issues.apache.org/jira/browse/PHOENIX-3297
And this one gives no rows
SELECT * FROM TEST.RVC_TEST WHERE (COLONE, COLTWO) IN (1,2) AND COLTHREE =3
AND COLFOUR=4;
> Can you try with the 4.8 release?
>
>
>
> On Mon, Sep 19, 2016 at 2:54 PM, Kumar Palaniappan <
> kpalaniap...@marinsoftware.com> wrote:
>
>>
>> Any one had faced this issue?
>>
>> https://issues.apache.org/jira/browse/PHOENIX-3297
>>
>&g
The problem is when we have just 1 param in the rvc it works.
but this one , for 2+
SELECT * FROM TEST.RVC_TEST WHERE (COLONE, COLTWO) IN ((1,2),(1,2)) AND
COLTHREE=3;
blows up.
On Mon, Sep 19, 2016 at 3:58 PM, Kumar Palaniappan <
kpalaniap...@marinsoftware.com> wrote:
> No, I didnt
For a weird reason, if we do scan on a table, with a non key, there are
duplicate rows in the table.
If we do look up with the complete RK of a table, it doesnt show the
duplicates.
What could be wrong? Appreciate your time.
Similar as this one -https://issues.apache.org/jira/browse/PHOENIX-375
Deleting the table entries from system stats helped to get rid of duplicates.
Problem to be monitored during the high growth.
Kumar Palaniappan
> On Aug 28, 2017, at 11:48 AM, James Taylor wrote:
>
> Is the table salted? If the SALT_BUCKETS property was ever changed during the
After we did upgrade to 4.10 on a CDH 5.10, we do see too many ZK
connections (increased the max connections form 60->300->1000), but the
problem still exist.
Are there any known issues? Phoenix connection leak?
Appreciate your time.
After upgrading to CDH 5.9.1/Phoenix 4.10/Spark 1.6 from CDH 5.5.2/Phoenix
4.6/Spark 1.5, streaming jobs that read data from Phoenix no longer release
their zookeeper connections, meaning that the number of connections from
the driver grow with each batch until the ZooKeeper limit on connections
pe
Are there any plans to release Phoenix 4.13 compatible with HBase 1.2?
On Sat, Nov 11, 2017 at 5:57 PM, James Taylor
wrote:
> The Apache Phoenix team is pleased to announce the immediate availability
> of the 4.13.0 release. Apache Phoenix enables SQL-based OLTP and
> operational analytics for A
Thanks James. Sure will look into it from my end n update.
Currently we are focused on the ZK connection leak
https://issues.apache.org/jira/browse/PHOENIX-4247
https://issues.apache.org/jira/browse/PHOENIX-4319
Kumar Palaniappan
> On Nov 19, 2017, at 1:21 PM, James Taylor wrote:
>
Thanks Pedro.
We did CDH5.9.2 compatible with Phoenix 4.10 n 4.12 but got into series of
issues, one of them is a ZK leak.
Kumar Palaniappan
> On Nov 19, 2017, at 3:43 PM, Pedro Boado wrote:
>
> As I have volunteered to keep a CDH compatible release for Phoenix and as for
>
all IT are passing. I don't have any reason to believe that CDH would
> behave differently to Apache HBase. If there was a zk connection leak in
> CDH I would also expect it in the Apache version.
>
>
>
> On 20 Nov 2017 00:32, "Kumar Palaniappan"
> wrote:
>
>
Thanks,
> James
>
> [1] https://lists.apache.org/thread.html/5b8b44acb1d3608770309767c3cdde
> cbc6484c29452fe6750d8e1516@%3Cdev.phoenix.apache.org%3E
> [2] https://lists.apache.org/thread.html/70cffa798d5f21ef87b02e07aeca8c
> 7982b0b30251411b7be17fadf9@%3Cdev.phoenix.apach
sts
>>>> so they can take place in DISCUSS threads.
>>>>
>>>> Thanks,
>>>> James
>>>>
>>>> [1] https://lists.apache.org/thread.html/5b8b44acb1d3608770309767c3cdde
>>>> cbc6484c29452fe6750d8e1516@%3Cdev.phoenix.apache.org%3E
&
)
>
> Cheers.
>
> On 27 Nov 2017 08:28, "Kumar Palaniappan"
> wrote:
>
>> Thanks @james.
>>
>> Since this patch(Phoenix-4372) is tightly coupled with CDH5.11.2, would
>> like to get the 4.13HBase1.2 branch released so can make it compatible wi
34 matches
Mail list logo
