vote for Phoenix Hadoop Summit talk!

I've submitted a Phoenix talk for Hadoop Summit. I'd appreciate a vote for it here: http://hadoopsummit.uservoice.com/forums/344967-future-of-apache-hadoop Regards, James

Re: to_date not working as expected

I have a patch out for PHOENIX-1769 . The issue is that the jruby-complete-1.6.8.jar that is present in then hbase lib directory contains jodatime 1.6 classes which get picked up instead of the 2.7 classes that are included in the phoenix server

Re: select all dynamic columns by primary key if columns names are unknown

Regarding the use of views to make dynamic fields appear as static fields, I have been unable to get them to work with dynamic fields. I am using Phoenix 3.2.2. 0: jdbc:phoenix:localhost> create view TMP_DYNA as select * from COLLECTIONS("category_hierarchy" varchar); REDError: ERROR 602 (42P00)

Re: select all dynamic columns by primary key if columns names are unknown

It's not my usecase unfortunately... I have to log links between identities. Link presented as: id1, source1, id2, source2 means id1 came from source1 and id2 came from source2 and these ids are linked (a kind cross-site auth) the problem is that I set (id1, source1) as composite primary key and wr

Re: Select by first part of composite primary key, is it effective?

If you know your key space then you can use *SPLIT ON* in your table create DDL. See http://phoenix.apache.org/language On Tue, Feb 2, 2016 at 11:54 AM, Serega Sheypak wrote: > Hm... and what is the right to presplit table then? > > 2016-02-02 18:30 GMT+01:00 Mujtaba Chohan : > >> If your filter

ArrayIndexOutOfBoundsException in phoenix-core 3.3.1

I am seeing the following stack trace intermittently when committing after an upsert. java.lang.ArrayIndexOutOfBoundsException: 14 at org.apache.phoenix.execute.MutationState.validate(MutationState.java:314) at org.apache.phoenix.execute.MutationState.commit(MutationState.java:360) at org.apache.p

Re: select all dynamic columns by primary key if columns names are unknown

I encourage you to use views[1] instead. You can dynamically add/remove columns from a view and this way Phoenix keeps track of it for you and you get all the other standard features. Thanks, James [1] https://phoenix.apache.org/views.html On Tue, Feb 2, 2016 at 1:42 PM, Serega Sheypak wrote: >

Re: select all dynamic columns by primary key if columns names are unknown

It super overhead, you have to query twice... 2016-02-02 22:34 GMT+01:00 Steve Terrell : > I would like to know as well. Today when I upsert and create dynamic > columns, I have to also create a second table to keep track of the dynamic > field names and data types that were upserted so that the

Re: select all dynamic columns by primary key if columns names are unknown

I would like to know as well. Today when I upsert and create dynamic columns, I have to also create a second table to keep track of the dynamic field names and data types that were upserted so that the person writing queries for the first table can know what's fields are available. Also would lik

select all dynamic columns by primary key if columns names are unknown

Hi, is it possible to select all dynamic columns if you don't know their names in advance? Example: I have a table with single defined column named PK, which is a primary key Someone runs query: UNSERT INTO MY_TBL(PK, C1, C2, C3) VALUES('x', '1', '2', '3') where C1, C2, C3 are dynamic columns

Re: Select by first part of composite primary key, is it effective?

Hm... and what is the right to presplit table then? 2016-02-02 18:30 GMT+01:00 Mujtaba Chohan : > If your filter matches few rows due to filter on leading part of PK then > your data might only reside in a single block which leads to less > overall disk reads for non-salted case vs need for multi

Re: to_date not working as expected

Hi Thomas, Any update on this? If and when a patch becomes available, can you please update this thread. This is a blocker: 1. We have existing HBase tables that users do not necessarily want to port over to Phoenix tables 2. Building Phoenix views to the existing HBase tables is a better soluti

Re: Select by first part of composite primary key, is it effective?

If your filter matches few rows due to filter on leading part of PK then your data might only reside in a single block which leads to less overall disk reads for non-salted case vs need for multiple blocks reads for salted one. On Tuesday, February 2, 2016, Serega Sheypak wrote: > > then you wou

Re: Select by first part of composite primary key, is it effective?

Does phoenix have something similar: hbase org.apache.hadoop.hbase.util.RegionSplitter MY_TABLE HexStringSplit -c 10 -f c Command creates pre-splitte table with 10 splits where each split takes a part of range from 000 to f? 2016-02-02 10:34 GMT+01:00 Serega Sheypak : > > then you w

Re: Select by first part of composite primary key, is it effective?

> then you would be better off not using salt buckets all together rather than having 100 parallel scan and block reads in your case. I Didn't understand you correctly. What is difference between salted/not salted table in case of "primary key leading-part select"? 2016-02-02 1:18 GMT+01:00 Mujtab