date:20150320


[ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370890#comment-14370890
 ] 

James Taylor commented on PHOENIX-1756:
---

[~sergey.b] - I was talking about an improvement for the internal 
implementation of the function, not forcing the user to do this in SQL. I'm +1 
on having these functions. I also like your EXTRACT idea. We might be able to 
have one of our GSoC participants implement that. Would you mind filing a JIRA 
with some description as a subtask of PHOENIX-1662 and set the labels field to 
gsoc2015.

> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Commented] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information

Hi,

I have gone through some resources regarding visualization of trace info on
database servers (Postgres/MySQL, MSSQL).


   - The DTrace function in MySQL is a profiler that creates flame graphs.
   [1]
   - A tool for visualizations of a database system [2]
   - Generates images with help of GraphViz for
   - Some data modeling tools [4]
   - DBVisualizer Tool [5]
   - Data Visualization Application where data is input from a database or
   a file and exported as image or a customized template [6]
   - Visualizing Postgres [7]
   - A Research Paper on Modeling Trace Information[8]
   - A Tool for visualizing Trace Info


Given above is a brief summary of the details I found. Hope it would help
me to better understand the formats and values of the input traces and
different available methods of graphically representing them.

Based on them I hope to come up with the most suitable method of Visually
representing the said data.

Thank you.
BR,
Nishani

[1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
[2] http://docs.cartodb.com/cartodb-editor.html#visualizations
[3] https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/SchemaDisplay
[4] http://www.databaseanswers.org/modelling_tools.htm
[5] http://www.dbvis.com/
[6] https://sites.google.com/site/datavisualizationapplication/
[7] http://www.pgcon.org/2013/schedule/track/Performance/588.en.html
[8] http://link.springer.com/chapter/10.1007%2F978-3-642-40787-1_13
[9]
http://www.upscene.com/documentation/fbtm3/index.html?qsg_trace_data_visualization.htm

On Sun, Mar 15, 2015 at 2:32 PM, Nishani (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/PHOENIX-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14362302#comment-14362302
> ]
>
> Nishani  commented on PHOENIX-1118:
> ---
>
> Hi,
>
> I have started a new thread on developer mailing list of Apache Phoenix
> regarding this issue[1]. Please note the steps I'm currently following. I'm
> communicating with the Community and all of  your feedback is highly
> appreciated.
>
> Am I on the correct path as per [1]? Any suggestions for writing a better
> proposal?
>
> Thank you.
> Best Regards,
> Nishani
>
> [1] Subject : Provide a tool for visualizing Phoenix tracing information
> (PHOENIX-1118)
>
> http://mail-archives.apache.org/mod_mbox/phoenix-dev/201503.mbox/%3CCAGsXwjMKL6kNamCuXUt3dmshHgSKjYXfbVtqmL8FGR7hEQ5zaQ%40mail.gmail.com%3E
>
>
> > Provide a tool for visualizing Phoenix tracing information
> > --
> >
> > Key: PHOENIX-1118
> > URL: https://issues.apache.org/jira/browse/PHOENIX-1118
> > Project: Phoenix
> >  Issue Type: Sub-task
> >Reporter: James Taylor
> >Assignee: Nishani
> >  Labels: Java, SQL, Visualization, gsoc2015, mentor
> >
> > Currently there's no means of visualizing the trace information provided
> by Phoenix. We should provide some simple charting over our metrics tables.
> Take a look at the following JIRA for sample queries:
> https://issues.apache.org/jira/browse/PHOENIX-1115?focusedCommentId=14323151&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14323151
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>



-- 
Best Regards,
Ayola Jayamaha

[jira] [Commented] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information

2015-03-20 Thread Nishani (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370997#comment-14370997
 ] 

Nishani  commented on PHOENIX-1118:
---

Hi,

I have gone through some resources regarding visualization of trace info on 
database servers (Postgres/MySQL, MSSQL).

The DTrace function in MySQL is a profiler that creates flame graphs. [1] 
A tool for visualizations of a database system [2]
Generates images with help of GraphViz for 
Some data modeling tools [4]
DBVisualizer Tool [5]
Data Visualization Application where data is input from a database or a file 
and exported as image or a customized template [6]
Visualizing Postgres [7]
A Research Paper on Modeling Trace Information[8]
A Tool for visualizing Trace Info

Given above is a brief summary of the details I found. Hope it would help me to 
better understand the formats and values of the input traces and different 
available methods of graphically representing them.

Based on them I hope to come up with the most suitable method of Visually 
representing the said data. 

Regarding the installation I presume that the HBase version that is needed to 
run Phoenix for visualizing trace info can be as Standalone and that cluster 
view is not needed(Distributed Version).

Thank you.
BR,
Nishani 

[1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
[2] http://docs.cartodb.com/cartodb-editor.html#visualizations
[3] https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/SchemaDisplay
[4] http://www.databaseanswers.org/modelling_tools.htm
[5] http://www.dbvis.com/
[6] https://sites.google.com/site/datavisualizationapplication/
[7] http://www.pgcon.org/2013/schedule/track/Performance/588.en.html
[8] http://link.springer.com/chapter/10.1007%2F978-3-642-40787-1_13
[9] 
http://www.upscene.com/documentation/fbtm3/index.html?qsg_trace_data_visualization.htm


> Provide a tool for visualizing Phoenix tracing information
> --
>
> Key: PHOENIX-1118
> URL: https://issues.apache.org/jira/browse/PHOENIX-1118
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Nishani 
>  Labels: Java, SQL, Visualization, gsoc2015, mentor
>
> Currently there's no means of visualizing the trace information provided by 
> Phoenix. We should provide some simple charting over our metrics tables. Take 
> a look at the following JIRA for sample queries: 
> https://issues.apache.org/jira/browse/PHOENIX-1115?focusedCommentId=14323151&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14323151



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information

2015-03-20 Thread Nishani (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370997#comment-14370997
 ] 

Nishani  edited comment on PHOENIX-1118 at 3/20/15 8:54 AM:


Hi,

I have gone through some resources regarding visualization of trace info on 
database servers (Postgres/MySQL, MSSQL).

The DTrace function in MySQL is a profiler that creates flame graphs. [1] 
A tool for visualizations of a database system [2]
Generates images with help of GraphViz for 
Some data modeling tools [4]
DBVisualizer Tool [5]
Data Visualization Application where data is input from a database or a file 
and exported as image or a customized template [6]
Visualizing Postgres [7]
A Research Paper on Modeling Trace Information[8]
A Tool for visualizing Trace Info [9]

Given above is a brief summary of the details I found. Hope it would help me to 
better understand the formats and values of the input traces and different 
available methods of graphically representing them.

Based on them I hope to come up with the most suitable method of Visually 
representing the said data. 

Regarding the installation I presume that the HBase version that is needed to 
run Phoenix for visualizing trace info can be as Standalone and that cluster 
view is not needed(Distributed Version).

Thank you.
BR,
Nishani 

[1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
[2] http://docs.cartodb.com/cartodb-editor.html#visualizations
[3] https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/SchemaDisplay
[4] http://www.databaseanswers.org/modelling_tools.htm
[5] http://www.dbvis.com/
[6] https://sites.google.com/site/datavisualizationapplication/
[7] http://www.pgcon.org/2013/schedule/track/Performance/588.en.html
[8] http://link.springer.com/chapter/10.1007%2F978-3-642-40787-1_13
[9] 
http://www.upscene.com/documentation/fbtm3/index.html?qsg_trace_data_visualization.htm



was (Author: nishani):
Hi,

I have gone through some resources regarding visualization of trace info on 
database servers (Postgres/MySQL, MSSQL).

The DTrace function in MySQL is a profiler that creates flame graphs. [1] 
A tool for visualizations of a database system [2]
Generates images with help of GraphViz for 
Some data modeling tools [4]
DBVisualizer Tool [5]
Data Visualization Application where data is input from a database or a file 
and exported as image or a customized template [6]
Visualizing Postgres [7]
A Research Paper on Modeling Trace Information[8]
A Tool for visualizing Trace Info

Given above is a brief summary of the details I found. Hope it would help me to 
better understand the formats and values of the input traces and different 
available methods of graphically representing them.

Based on them I hope to come up with the most suitable method of Visually 
representing the said data. 

Regarding the installation I presume that the HBase version that is needed to 
run Phoenix for visualizing trace info can be as Standalone and that cluster 
view is not needed(Distributed Version).

Thank you.
BR,
Nishani 

[1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
[2] http://docs.cartodb.com/cartodb-editor.html#visualizations
[3] https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/SchemaDisplay
[4] http://www.databaseanswers.org/modelling_tools.htm
[5] http://www.dbvis.com/
[6] https://sites.google.com/site/datavisualizationapplication/
[7] http://www.pgcon.org/2013/schedule/track/Performance/588.en.html
[8] http://link.springer.com/chapter/10.1007%2F978-3-642-40787-1_13
[9] 
http://www.upscene.com/documentation/fbtm3/index.html?qsg_trace_data_visualization.htm


> Provide a tool for visualizing Phoenix tracing information
> --
>
> Key: PHOENIX-1118
> URL: https://issues.apache.org/jira/browse/PHOENIX-1118
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: James Taylor
>Assignee: Nishani 
>  Labels: Java, SQL, Visualization, gsoc2015, mentor
>
> Currently there's no means of visualizing the trace information provided by 
> Phoenix. We should provide some simple charting over our metrics tables. Take 
> a look at the following JIRA for sample queries: 
> https://issues.apache.org/jira/browse/PHOENIX-1115?focusedCommentId=14323151&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14323151



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-1761) rg.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table undefined

2015-03-20 Thread Thamarai Selvi (JIRA)

Thamarai Selvi created PHOENIX-1761:
---

Summary: rg.apache.phoenix.schema.TableNotFoundException: ERROR
1012 (42M03): Table undefined
Key: PHOENIX-1761
URL: https://issues.apache.org/jira/browse/PHOENIX-1761
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.2
Reporter: Thamarai Selvi
Priority: Critical

Hi James Taylor,

I am facing this issue repetately. Its not the case always getting this issue.
Sometimes only it is occuring. Not able to identify the root cause of this
issue. We are using hbase 0.98 and phoenix-4.2.0. Following are the two
scenarios where i have faced this issue,

Scenario1:
1. Ran a simple aggregation query without any join in phoenix client directly.
2. Client throws table not found exception.
3. Ran command !tables in client.
4. None of the tables were shown in the client apart from SYSTEM tables.
5. Quit the client and reconnected again.
6. Ran the same command !tables in client.
7. Now i can able to see all the tables along with SYSTEM tables.
8. Ran the same query. The query executed successfully and gave the result.

Scenario2:
1. Ran a simple aggregation query without any join from our application server
through phoenix jdbc server.
2. Application throws Phoenix table not found exception.
3. Re triggered the same process
4. The same query executed sucessfully by the same process and returned the
result.

Exception Trace:
org.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table
undefined.
at
org.apache.phoenix.compile.FromCompiler$BaseColumnResolver.createTableRef(FromCompiler.java:303)
at
org.apache.phoenix.compile.FromCompiler$SingleTableColumnResolver.(FromCompiler.java:215)
at
org.apache.phoenix.compile.FromCompiler.getResolverForQuery(FromCompiler.java:159)
at
org.apache.phoenix.compile.QueryCompiler.compileSingleQuery(QueryCompiler.java:374)
at
org.apache.phoenix.compile.QueryCompiler.compile(QueryCompiler.java:139)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:311)
at
org.apache.phoenix.jdbc.PhoenixStatement$ExecutableSelectStatement.compilePlan(PhoenixStatement.java:294)
at
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:215)
at
org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:211)
at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:210)
at
org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:1013)

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-1762) rg.apache.phoenix.schema.TableNotFoundException: ERROR 1012 (42M03): Table undefined

2015-03-20 Thread Thamarai Selvi (JIRA)

Thamarai Selvi created PHOENIX-1762:
---

Summary: rg.apache.phoenix.schema.TableNotFoundException: ERROR
1012 (42M03): Table undefined
Key: PHOENIX-1762
URL: https://issues.apache.org/jira/browse/PHOENIX-1762
Project: Phoenix
Issue Type: Bug
Affects Versions: 4.2
Reporter: Thamarai Selvi
Priority: Critical

Hi James Taylor,

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1734) Local index improvements

2015-03-20 Thread Rajeshbabu Chintaguntla (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371530#comment-14371530
 ] 

Rajeshbabu Chintaguntla commented on PHOENIX-1734:
--

[~stack]
bq. Every index key will have startkey prefix? 
Currently yes. I am thinking we can find the minimal byte array between start 
and end key of the region and prefix it. Then in worst case we may need to 
prefix the region start key.
bq. All scans of this index will need to first strip start key?
Yes we are striping out the start key.

> Local index improvements
> 
>
> Key: PHOENIX-1734
> URL: https://issues.apache.org/jira/browse/PHOENIX-1734
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>
> Local index design considerations: 
>  1. Colocation: We need to co-locate regions of local index regions and data 
> regions. The co-location can be a hard guarantee or a soft (best approach) 
> guarantee. The co-location is a performance requirement, and also maybe 
> needed for consistency(2). Hard co-location means that either both the data 
> region and index region are opened atomically, or neither of them open for 
> serving. 
>  2. Index consistency : Ideally we want the index region and data region to 
> have atomic updates. This means that they should either (a)use transactions, 
> or they should (b)share the same WALEdit and also MVCC for visibility. (b) is 
> only applicable if there is hard colocation guarantee. 
>  3. Local index clients : How the local index will be accessed from clients. 
> In case of the local index being managed in a table, the HBase client can be 
> used for doing scans, etc. If the local index is hidden inside the data 
> regions, there has to be a different mechanism to access the data through the 
> data region. 
> With the above considerations, we imagine three possible implementation for 
> the local index solution, each detailed below. 
> APPROACH 1:  Current approach
> (1) Current approach uses balancer as a soft guarantee. Because of this, in 
> some rare cases, colocation might not happen. 
> (2) The index and data regions do not share the same WALEdits. Meaning 
> consistency cannot be achieved. Also there are two WAL writes per write from 
> client. 
> (3) Regular Hbase client can be used to access index data since index is just 
> another table. 
> APPROACH 2: Shadow regions + shared WAL & MVCC 
> (1) Introduce a shadow regions concept in HBase. Shadow regions are not 
> assigned by AM. Phoenix implements atomic open (and split/merge) of region 
> opening for data regions and index regions so that hard co-location is 
> guaranteed. 
> (2) For consistency requirements, the index regions and data regions will 
> share the same WALEdit (and thus recovery) and they will also share the same 
> MVCC mechanics so that index update and data update is visible atomically. 
> (3) Regular Hbase client can be used to access index data since index is just 
> another table.  
> APPROACH 3: Storing index data in separate column families in the table.
>  (1) Regions will have store files for cfs, which is sorted using the primary 
> sort order. Regions may also maintain stores, sorted in secondary sort 
> orders. This approach is similar in vein how a RDBMS keeps data (a B-TREE in 
> primary sort order and multiple B-TREEs in secondary sort orders with 
> pointers to primary key). That means store the index data in separate column 
> families in the data region. This way a region is extended to be more similar 
> to a RDBMS (but LSM instead of BTree). This is sometimes called shadow cf’s 
> as well. This approach guarantees hard co-location.
>  (2) Since everything is in a single region, they automatically share the 
> same WALEdit and MVCC numbers. Atomicity is easily achieved. 
>  (3) Current Phoenix implementation need to change in such a way that column 
> families selection in read/write path is based data table/index table(logical 
> table in phoenix). 
> I think that APPROACH 3 is the best one for long term, since it does not 
> require to change anything in HBase, mainly we don't need to muck around with 
> the split/merge stuff in HBase. It will be win-win.
> However, APPROACH 2 still needs a “shadow regions” concept to be implemented 
> in HBase itself, and also a way to share WALEdits and MVCCs from multiple 
> regions.
> APPROACH 1 is a good start for local indexes, but I think we are not getting 
> the full benefits for the feature. We can support this for the short term, 
> and decide on the next steps for a longer term implementation. 
> we won't be able to get to implementing it immediately, and want to start a 
> brainstorm.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1653) Allow option to pass peer zookeeper address to load data into a target cluster in Map Reduce api

2015-03-20 Thread Gabriel Reid (JIRA)


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gabriel Reid updated PHOENIX-1653:
--
Attachment: PHOENIX-1653v5.patch

Good point [~maghamraviki...@gmail.com]. Here's the updated patch with that 
issue fixed. I'll commit shortly if there aren't any objections.

> Allow option to pass peer zookeeper address to load data into a target 
> cluster in Map Reduce api
> 
>
> Key: PHOENIX-1653
> URL: https://issues.apache.org/jira/browse/PHOENIX-1653
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0
>Reporter: maghamravikiran
>  Labels: newbie, patch
> Attachments: PHOENIX-1653.patch, PHOENIX-1653v2.patch, 
> PHOENIX-1653v3.patch, PHOENIX-1653v4.patch, PHOENIX-1653v5.patch
>
>
> Provide an option to pass the peer zookeeper address within a MapReduce job 
> where PhoenixInputFormat reads from one HBase cluster, and 
> PhoenixOutputFormat writes to a different cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1653) Allow option to pass peer zookeeper address to load data into a target cluster in Map Reduce api

2015-03-20 Thread maghamravikiran (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371545#comment-14371545
 ] 

maghamravikiran commented on PHOENIX-1653:
--

Thanks [~gabriel.reid] . +1 for commit.

> Allow option to pass peer zookeeper address to load data into a target 
> cluster in Map Reduce api
> 
>
> Key: PHOENIX-1653
> URL: https://issues.apache.org/jira/browse/PHOENIX-1653
> Project: Phoenix
>  Issue Type: Improvement
>Affects Versions: 5.0.0
>Reporter: maghamravikiran
>  Labels: newbie, patch
> Attachments: PHOENIX-1653.patch, PHOENIX-1653v2.patch, 
> PHOENIX-1653v3.patch, PHOENIX-1653v4.patch, PHOENIX-1653v5.patch
>
>
> Provide an option to pass the peer zookeeper address within a MapReduce job 
> where PhoenixInputFormat reads from one HBase cluster, and 
> PhoenixOutputFormat writes to a different cluster.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1734) Local index improvements

2015-03-20 Thread stack (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371563#comment-14371563
 ] 

stack commented on PHOENIX-1734:


[~rajeshbabu] Sounds good (especially bit of finding minimal byte array between 
start and end key -- you've seen how this is done in the hfile index code?).  
Approach #3 seems viable to me; nice. Thinking more on how the region keyspace 
will 'bulge out' on the key we center secondary indices on, I don't think it 
will be a problem. We'll split on a key that falls inside the bulge but that is 
fine I'd say (or at least lets run with it for now I'd say).

> Local index improvements
> 
>
> Key: PHOENIX-1734
> URL: https://issues.apache.org/jira/browse/PHOENIX-1734
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Rajeshbabu Chintaguntla
>
> Local index design considerations: 
>  1. Colocation: We need to co-locate regions of local index regions and data 
> regions. The co-location can be a hard guarantee or a soft (best approach) 
> guarantee. The co-location is a performance requirement, and also maybe 
> needed for consistency(2). Hard co-location means that either both the data 
> region and index region are opened atomically, or neither of them open for 
> serving. 
>  2. Index consistency : Ideally we want the index region and data region to 
> have atomic updates. This means that they should either (a)use transactions, 
> or they should (b)share the same WALEdit and also MVCC for visibility. (b) is 
> only applicable if there is hard colocation guarantee. 
>  3. Local index clients : How the local index will be accessed from clients. 
> In case of the local index being managed in a table, the HBase client can be 
> used for doing scans, etc. If the local index is hidden inside the data 
> regions, there has to be a different mechanism to access the data through the 
> data region. 
> With the above considerations, we imagine three possible implementation for 
> the local index solution, each detailed below. 
> APPROACH 1:  Current approach
> (1) Current approach uses balancer as a soft guarantee. Because of this, in 
> some rare cases, colocation might not happen. 
> (2) The index and data regions do not share the same WALEdits. Meaning 
> consistency cannot be achieved. Also there are two WAL writes per write from 
> client. 
> (3) Regular Hbase client can be used to access index data since index is just 
> another table. 
> APPROACH 2: Shadow regions + shared WAL & MVCC 
> (1) Introduce a shadow regions concept in HBase. Shadow regions are not 
> assigned by AM. Phoenix implements atomic open (and split/merge) of region 
> opening for data regions and index regions so that hard co-location is 
> guaranteed. 
> (2) For consistency requirements, the index regions and data regions will 
> share the same WALEdit (and thus recovery) and they will also share the same 
> MVCC mechanics so that index update and data update is visible atomically. 
> (3) Regular Hbase client can be used to access index data since index is just 
> another table.  
> APPROACH 3: Storing index data in separate column families in the table.
>  (1) Regions will have store files for cfs, which is sorted using the primary 
> sort order. Regions may also maintain stores, sorted in secondary sort 
> orders. This approach is similar in vein how a RDBMS keeps data (a B-TREE in 
> primary sort order and multiple B-TREEs in secondary sort orders with 
> pointers to primary key). That means store the index data in separate column 
> families in the data region. This way a region is extended to be more similar 
> to a RDBMS (but LSM instead of BTree). This is sometimes called shadow cf’s 
> as well. This approach guarantees hard co-location.
>  (2) Since everything is in a single region, they automatically share the 
> same WALEdit and MVCC numbers. Atomicity is easily achieved. 
>  (3) Current Phoenix implementation need to change in such a way that column 
> families selection in read/write path is based data table/index table(logical 
> table in phoenix). 
> I think that APPROACH 3 is the best one for long term, since it does not 
> require to change anything in HBase, mainly we don't need to muck around with 
> the split/merge stuff in HBase. It will be win-win.
> However, APPROACH 2 still needs a “shadow regions” concept to be implemented 
> in HBase itself, and also a way to share WALEdits and MVCCs from multiple 
> regions.
> APPROACH 1 is a good start for local indexes, but I think we are not getting 
> the full benefits for the feature. We can support this for the short term, 
> and decide on the next steps for a longer term implementation. 
> we won't be able to get to implementing it immediately, and want to start a 
> brainstorm.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1752) Phoenix should not "early-start" TableResultIterators

2015-03-20 Thread Mujtaba Chohan (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371645#comment-14371645
 ] 

Mujtaba Chohan commented on PHOENIX-1752:
-

[~jamestaylor] Default client thread pool size was used. 

> Phoenix should not "early-start" TableResultIterators
> -
>
> Key: PHOENIX-1752
> URL: https://issues.apache.org/jira/browse/PHOENIX-1752
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>  Labels: 4.3.1
> Attachments: 1752.txt
>
>
> Currently Phoenix early-starts TableResultIterators.
> I do not think that is correct; what happens is that the scanner will start 
> working simply by being created, and the work is not handled by the 
> threadpool. In other words merely creating the iterator will start to do 
> work, regardless of how large the Phoenix pool is size. It might seem to be 
> faster, but only because we're throwing more threads at it than we say we 
> would. Making the threadpool larger should get us back to the same the 
> performance.
> The main task here is to perf test this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1705) implement ARRAY_APPEND built in function

2015-03-20 Thread ramkrishna.s.vasudevan (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371717#comment-14371717
 ] 

ramkrishna.s.vasudevan commented on PHOENIX-1705:
-

Thanks to James for pointing out the case where the 'short' array gets changed 
to 'int'.  Nice catch.
{code}
offsetArrayPosition+elementLength+offsetArrayLength+Bytes.SIZEOF_INT+Bytes.SIZEOF_BYTE
{code}
Instead of repeating the common part in these calculation ensure that you move 
them to a local variable and substitute that local variable where ever 
possible.  I think that would make the code easier to read too. 
One question, if a null is passed ato ARRAY_APPEND ['abc','def'][null], ideally 
we need not do anything. Are we handling that here.

> implement ARRAY_APPEND built in function
> 
>
> Key: PHOENIX-1705
> URL: https://issues.apache.org/jira/browse/PHOENIX-1705
> Project: Phoenix
>  Issue Type: Sub-task
>Reporter: Dumindu Buddhika
>Assignee: Dumindu Buddhika
> Attachments: 
> PHOENIX-1705_implement_ARRAY_APPEND_built_in_function.patch, 
> PHOENIX-1705_implement_ARRAY_APPEND_built_in_function.patch, 
> PHOENIX-1705_implement_ARRAY_APPEND_built_in_function1.patch, 
> PHOENIX-1705_implement_ARRAY_APPEND_built_in_function2.patch, 
> PHOENIX-1705_implement_ARRAY_APPEND_built_in_function3.patch, 
> PHOENIX-1705_implement_ARRAY_APPEND_built_in_function4.patch, 
> PHOENIX-1705_implement_ARRAY_APPEND_built_in_function5.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request: PHOENIX-1744 Allow Integer, UnsignedInt and ...

2015-03-20 Thread dhacker1341

Github user dhacker1341 closed the pull request at:

https://github.com/apache/phoenix/pull/48


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (PHOENIX-1744) CAST from UNSIGNED_LONG (_INT) to * TIMESTAMP is not supported.

2015-03-20 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371963#comment-14371963
 ] 

ASF GitHub Bot commented on PHOENIX-1744:
-

Github user dhacker1341 closed the pull request at:

https://github.com/apache/phoenix/pull/48


> CAST from UNSIGNED_LONG (_INT) to * TIMESTAMP is not supported.
> ---
>
> Key: PHOENIX-1744
> URL: https://issues.apache.org/jira/browse/PHOENIX-1744
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Serhiy Bilousov
>Assignee: Dave Hacker
>Priority: Minor
>  Labels: 4.3.1
>
> Epoch time can be represented as INTEGER (up to the seconds) or LONG (up to 
> the millisecond). Currently CAST from UNSIGNED_LONG to TIMESTAMP not 
> supported by Phoenix. 
> It make sense to have support for conversion from epoch (4 bytes or 8 bytes) 
> to any datetime like format curently supported by Phoenix (TIME, DATE, 
> TIMESTAMP, UNSIGNED_TIME, UNSIGNED_DATE, UNSIGNED_TIMESTAMP).
> HBase shell:
> {noformat}
> create 't','f1'
> put 
> 't',"\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x01L\x0Fz,\x1E",'f1:c1','test'
> {noformat}
> sqlline:
> {noformat}
> CREATE VIEW vT
> (   a UNSIGNED_INT NOT NULL
>,b UNSIGNED_INT NOT NULL
>,ts UNSIGNED_LONG NOT NULL
> CONSTRAINT pk PRIMARY KEY (a, b, ts))
> AS SELECT * FROM "t"
> DEFAULT_COLUMN_FAMILY ='f1';
>  select a, b, ts, CAST(1426188807198 AS TIMESTAMP) from vt;
> ++++--+
> | A  | B  |   TS   | TO_TIMESTAMP(1426188807198)  |
> ++++--+
> | 1  | 1  | 1426188807198  | 2015-03-12 19:33:27.198  |
> ++++--+
> {noformat}
> but
> {noformat}
> select a, b, ts, CAST(ts AS TIMESTAMP) from vt;
> Error: ERROR 203 (22005): Type mismatch. UNSIGNED_LONG and TIMESTAMP for TS 
> (state=22005,code=203)
> {noformat}
> As per Gabriel Reid
> {quote}
> As a workaround, you can cast the UNSIGNED_LONG to a BIGINT first, and then 
> cast it to a TIMESTAMP, i.e.
> select a, b, ts, CAST(CAST(ts AS BIGINT) AS TIMESTAMP) from vt;
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] phoenix pull request: PHOENIX-1744 unsigned long cast to timestamp

2015-03-20 Thread dhacker1341

GitHub user dhacker1341 opened a pull request:

https://github.com/apache/phoenix/pull/52

PHOENIX-1744 unsigned long cast to timestamp



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dhacker1341/phoenix master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/phoenix/pull/52.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #52


commit bfe114af832dee4ea4ba4ee1cdc663e7461a1b6c
Author: David 
Date:   2015-03-18T20:37:20Z

PHOENIX-1744 Allow Integer, UnsignedInt and UnsignedLong to be Cast to 
TIMESTAMP

commit 7daa14bf5e858b9abfd026bd9760f08583a3de41
Author: David 
Date:   2015-03-20T19:42:01Z

PHOENIX-1744 Only unsigned long, not integer should be castable to 
timestamp.

commit 6a68955c95caa2ae1510f1b97321e249a572d7e1
Author: dhacker1341 
Date:   2015-03-20T19:45:51Z

PHOENIX-1744 Only unsigned long, not integer should be castable to 
timestamp.

commit 0e846ba2f85bc4e118f59f74f6f8761e4bb30612
Author: dhacker1341 
Date:   2015-03-20T19:48:35Z

PHOENIX-1744 Only unsigned long, not integer should be castable to 
timestamp.

commit cd6594475986aa0ff3c9eaaebd18ab6815ad46f3
Author: dhacker1341 
Date:   2015-03-20T19:49:45Z

PHOENIX-1744 Only unsigned long, not integer should be castable to 
timestamp.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (PHOENIX-1744) CAST from UNSIGNED_LONG (_INT) to * TIMESTAMP is not supported.

2015-03-20 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14371965#comment-14371965
 ] 

ASF GitHub Bot commented on PHOENIX-1744:
-

GitHub user dhacker1341 opened a pull request:

https://github.com/apache/phoenix/pull/52

PHOENIX-1744 unsigned long cast to timestamp



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/dhacker1341/phoenix master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/phoenix/pull/52.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #52


commit bfe114af832dee4ea4ba4ee1cdc663e7461a1b6c
Author: David 
Date:   2015-03-18T20:37:20Z

PHOENIX-1744 Allow Integer, UnsignedInt and UnsignedLong to be Cast to 
TIMESTAMP

commit 7daa14bf5e858b9abfd026bd9760f08583a3de41
Author: David 
Date:   2015-03-20T19:42:01Z

PHOENIX-1744 Only unsigned long, not integer should be castable to 
timestamp.

commit 6a68955c95caa2ae1510f1b97321e249a572d7e1
Author: dhacker1341 
Date:   2015-03-20T19:45:51Z

PHOENIX-1744 Only unsigned long, not integer should be castable to 
timestamp.

commit 0e846ba2f85bc4e118f59f74f6f8761e4bb30612
Author: dhacker1341 
Date:   2015-03-20T19:48:35Z

PHOENIX-1744 Only unsigned long, not integer should be castable to 
timestamp.

commit cd6594475986aa0ff3c9eaaebd18ab6815ad46f3
Author: dhacker1341 
Date:   2015-03-20T19:49:45Z

PHOENIX-1744 Only unsigned long, not integer should be castable to 
timestamp.




> CAST from UNSIGNED_LONG (_INT) to * TIMESTAMP is not supported.
> ---
>
> Key: PHOENIX-1744
> URL: https://issues.apache.org/jira/browse/PHOENIX-1744
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Serhiy Bilousov
>Assignee: Dave Hacker
>Priority: Minor
>  Labels: 4.3.1
>
> Epoch time can be represented as INTEGER (up to the seconds) or LONG (up to 
> the millisecond). Currently CAST from UNSIGNED_LONG to TIMESTAMP not 
> supported by Phoenix. 
> It make sense to have support for conversion from epoch (4 bytes or 8 bytes) 
> to any datetime like format curently supported by Phoenix (TIME, DATE, 
> TIMESTAMP, UNSIGNED_TIME, UNSIGNED_DATE, UNSIGNED_TIMESTAMP).
> HBase shell:
> {noformat}
> create 't','f1'
> put 
> 't',"\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x01L\x0Fz,\x1E",'f1:c1','test'
> {noformat}
> sqlline:
> {noformat}
> CREATE VIEW vT
> (   a UNSIGNED_INT NOT NULL
>,b UNSIGNED_INT NOT NULL
>,ts UNSIGNED_LONG NOT NULL
> CONSTRAINT pk PRIMARY KEY (a, b, ts))
> AS SELECT * FROM "t"
> DEFAULT_COLUMN_FAMILY ='f1';
>  select a, b, ts, CAST(1426188807198 AS TIMESTAMP) from vt;
> ++++--+
> | A  | B  |   TS   | TO_TIMESTAMP(1426188807198)  |
> ++++--+
> | 1  | 1  | 1426188807198  | 2015-03-12 19:33:27.198  |
> ++++--+
> {noformat}
> but
> {noformat}
> select a, b, ts, CAST(ts AS TIMESTAMP) from vt;
> Error: ERROR 203 (22005): Type mismatch. UNSIGNED_LONG and TIMESTAMP for TS 
> (state=22005,code=203)
> {noformat}
> As per Gabriel Reid
> {quote}
> As a workaround, you can cast the UNSIGNED_LONG to a BIGINT first, and then 
> cast it to a TIMESTAMP, i.e.
> select a, b, ts, CAST(CAST(ts AS BIGINT) AS TIMESTAMP) from vt;
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1676) Set priority of Index Updates correctly

2015-03-20 Thread Thomas D'Silva (JIRA)


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas D'Silva updated PHOENIX-1676:

Affects Version/s: 4.3.1

> Set priority of Index Updates correctly 
> 
>
> Key: PHOENIX-1676
> URL: https://issues.apache.org/jira/browse/PHOENIX-1676
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0, 4.3.1
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
> Attachments: PHOENIX-1676-4.x-HBase-0.98.patch, 
> PHOENIX-1676-4.x-HBase-1.x.patch
>
>
> I spoke to Jesse offline about this. 
> The priority of index updates isn't being set correctly because of the use of 
> CoprocessorHConnection (which all coprocessors use if they create an HTable 
> via the CPEnvironment).
> Specifically the flow happens like this: the CoprocessorHTableFactory 
> attempts to set the connection qos factory, but it is ignored because the 
> CoprocessorHConnection is used (instead of a standard HConnection) and the 
> #getClient method just goes straight into the rpc scheduler of the 
> HRegionServer, if its on the same server. This allows the region to be 
> directly accessed, but without actually going over the loopback or 
> serializing any information.
> However, this means it ignores the configured rpccontroller factory and the 
> override setting of the rpc priority. We probably shouldn't be runtime 
> changing the configuration - instead we should probably be using some other 
> serialized information.
> The primary fix would seems to be that the regionserver needs to be 
> configured with the IndexQosRpcControllerFactory and then use a static map 
> (or cache of the index metadata) to set the qos for the index servers. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1676) Set priority of Index Updates correctly

2015-03-20 Thread Thomas D'Silva (JIRA)


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas D'Silva updated PHOENIX-1676:

Affects Version/s: 5.0.0
   4.0.0

> Set priority of Index Updates correctly 
> 
>
> Key: PHOENIX-1676
> URL: https://issues.apache.org/jira/browse/PHOENIX-1676
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0, 4.3.1
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
> Attachments: PHOENIX-1676-4.x-HBase-0.98.patch, 
> PHOENIX-1676-4.x-HBase-1.x.patch
>
>
> I spoke to Jesse offline about this. 
> The priority of index updates isn't being set correctly because of the use of 
> CoprocessorHConnection (which all coprocessors use if they create an HTable 
> via the CPEnvironment).
> Specifically the flow happens like this: the CoprocessorHTableFactory 
> attempts to set the connection qos factory, but it is ignored because the 
> CoprocessorHConnection is used (instead of a standard HConnection) and the 
> #getClient method just goes straight into the rpc scheduler of the 
> HRegionServer, if its on the same server. This allows the region to be 
> directly accessed, but without actually going over the loopback or 
> serializing any information.
> However, this means it ignores the configured rpccontroller factory and the 
> override setting of the rpc priority. We probably shouldn't be runtime 
> changing the configuration - instead we should probably be using some other 
> serialized information.
> The primary fix would seems to be that the regionserver needs to be 
> configured with the IndexQosRpcControllerFactory and then use a static map 
> (or cache of the index metadata) to set the qos for the index servers. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-1763) Support building with HBase-1.1.0

2015-03-20 Thread Enis Soztutar (JIRA)

Enis Soztutar created PHOENIX-1763:
--

 Summary: Support building with HBase-1.1.0 
 Key: PHOENIX-1763
 URL: https://issues.apache.org/jira/browse/PHOENIX-1763
 Project: Phoenix
  Issue Type: Improvement
Reporter: Enis Soztutar
 Fix For: 5.0.0


HBase-1.1 is in the works. However, due to HBASE-11544 and possibly HBASE-12972 
and more, we need some changes for supporting HBase-1.1 even after 
PHOENIX-1642. 

We can decide on a plan to support (or not) HBase-1.1 on which branches by the 
time it comes out. Let's use subtasks to keep progress for build support for 
1.1.0-SNAPSHOT. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1676) Set priority of Index Updates correctly

2015-03-20 Thread Thomas D'Silva (JIRA)


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas D'Silva updated PHOENIX-1676:

Attachment: PHOENIX-1676-4.x-HBase-1.x-v2.patch
PHOENIX-1676-4.x-HBase-0.98-v2.patch

[~jamestaylor] 

I have made the changes and uploaded a batch based on the feedback on the pull 
request. Can you please review?

Thanks,
Thomas

> Set priority of Index Updates correctly 
> 
>
> Key: PHOENIX-1676
> URL: https://issues.apache.org/jira/browse/PHOENIX-1676
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0, 4.3.1
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
> Attachments: PHOENIX-1676-4.x-HBase-0.98-v2.patch, 
> PHOENIX-1676-4.x-HBase-0.98.patch, PHOENIX-1676-4.x-HBase-1.x-v2.patch, 
> PHOENIX-1676-4.x-HBase-1.x.patch
>
>
> I spoke to Jesse offline about this. 
> The priority of index updates isn't being set correctly because of the use of 
> CoprocessorHConnection (which all coprocessors use if they create an HTable 
> via the CPEnvironment).
> Specifically the flow happens like this: the CoprocessorHTableFactory 
> attempts to set the connection qos factory, but it is ignored because the 
> CoprocessorHConnection is used (instead of a standard HConnection) and the 
> #getClient method just goes straight into the rpc scheduler of the 
> HRegionServer, if its on the same server. This allows the region to be 
> directly accessed, but without actually going over the loopback or 
> serializing any information.
> However, this means it ignores the configured rpccontroller factory and the 
> override setting of the rpc priority. We probably shouldn't be runtime 
> changing the configuration - instead we should probably be using some other 
> serialized information.
> The primary fix would seems to be that the regionserver needs to be 
> configured with the IndexQosRpcControllerFactory and then use a static map 
> (or cache of the index metadata) to set the qos for the index servers. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-1764) Pherf ClassCastException

Cody Marcel created PHOENIX-1764:


 Summary: Pherf ClassCastException
 Key: PHOENIX-1764
 URL: https://issues.apache.org/jira/browse/PHOENIX-1764
 Project: Phoenix
  Issue Type: Bug
Affects Versions: 5.0.0
Reporter: Cody Marcel


You get this exception when trying to execute a test scenario.

Starting Data Loader...
2015-03-20 19:22:12,773 INFO  [main] pherf.Pherf - Run completed. Shutting down 
Monitor if it was running.
java.lang.ClassCastException: java.util.Collections$SynchronizedCollection 
cannot be cast to java.util.List
at 
org.apache.phoenix.pherf.configuration.XMLConfigParser.getScenarios(XMLConfigParser.java:68)
at 
org.apache.phoenix.pherf.loaddata.DataLoader.execute(DataLoader.java:94)
at 
org.apache.phoenix.pherf.workload.WorkloadExecutor.executeDataLoad(WorkloadExecutor.java:83)
at org.apache.phoenix.pherf.Pherf.run(Pherf.java:174)
at org.apache.phoenix.pherf.Pherf.main(Pherf.java:124)




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1764) Pherf ClassCastException


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cody Marcel updated PHOENIX-1764:
-
Attachment: PHOENIX-1727.patch

> Pherf ClassCastException
> 
>
> Key: PHOENIX-1764
> URL: https://issues.apache.org/jira/browse/PHOENIX-1764
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 5.0.0
>Reporter: Cody Marcel
> Attachments: PHOENIX-1727.patch
>
>
> You get this exception when trying to execute a test scenario.
> Starting Data Loader...
> 2015-03-20 19:22:12,773 INFO  [main] pherf.Pherf - Run completed. Shutting 
> down Monitor if it was running.
> java.lang.ClassCastException: java.util.Collections$SynchronizedCollection 
> cannot be cast to java.util.List
>   at 
> org.apache.phoenix.pherf.configuration.XMLConfigParser.getScenarios(XMLConfigParser.java:68)
>   at 
> org.apache.phoenix.pherf.loaddata.DataLoader.execute(DataLoader.java:94)
>   at 
> org.apache.phoenix.pherf.workload.WorkloadExecutor.executeDataLoad(WorkloadExecutor.java:83)
>   at org.apache.phoenix.pherf.Pherf.run(Pherf.java:174)
>   at org.apache.phoenix.pherf.Pherf.main(Pherf.java:124)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1727) Pherf - Port shell scripts to python


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cody Marcel updated PHOENIX-1727:
-
Attachment: PHOENIX-1727.patch

> Pherf - Port shell scripts to python
> 
>
> Key: PHOENIX-1727
> URL: https://issues.apache.org/jira/browse/PHOENIX-1727
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Cody Marcel
>Assignee: Cody Marcel
>Priority: Minor
>
> Move the pherf.sh scripts into python scripts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1727) Pherf - Port shell scripts to python


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cody Marcel updated PHOENIX-1727:
-
Attachment: (was: PHOENIX-1727.patch)

> Pherf - Port shell scripts to python
> 
>
> Key: PHOENIX-1727
> URL: https://issues.apache.org/jira/browse/PHOENIX-1727
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Cody Marcel
>Assignee: Cody Marcel
>Priority: Minor
>
> Move the pherf.sh scripts into python scripts.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1756) Add Month() and Second() buildin functions


[ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372299#comment-14372299
 ] 

Alicia Ying Shu commented on PHOENIX-1756:
--

We picked the functions based on what time functions customers would use 
mostly. In another patch, will implement WEEK(date),  Minute() Hour(). Can add 
Day() and Millisecond() as well. 

> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (PHOENIX-1765) Add time relate building

Alicia Ying Shu created PHOENIX-1765:


 Summary: Add time relate building
 Key: PHOENIX-1765
 URL: https://issues.apache.org/jira/browse/PHOENIX-1765
 Project: Phoenix
  Issue Type: Bug
Reporter: Alicia Ying Shu


Week(), Day(), Hour(), Minute(), MillisOfSecond()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1765) Add time related buildins


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alicia Ying Shu updated PHOENIX-1765:
-
Assignee: Alicia Ying Shu
 Summary: Add time related buildins  (was: Add time relate building)

> Add time related buildins
> -
>
> Key: PHOENIX-1765
> URL: https://issues.apache.org/jira/browse/PHOENIX-1765
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
>
> Week(), Day(), Hour(), Minute(), MillisOfSecond()



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (PHOENIX-1756) Add Month() and Second() buildin functions


[ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372299#comment-14372299
 ] 

Alicia Ying Shu edited comment on PHOENIX-1756 at 3/20/15 11:21 PM:


We picked the functions based on what time functions customers would use 
mostly. In Phoenix-1765, will implement WEEK(date),  Minute(), Hour(), Day() 
and MillisOfSecond() as well. 


was (Author: aliciashu):
We picked the functions based on what time functions customers would use 
mostly. In another patch, will implement WEEK(date),  Minute() Hour(). Can add 
Day() and Millisecond() as well. 

> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [IMPORTANT] Some changes to branches and releases for 4.4+

2015-03-20 Thread James Taylor

Is this fixed yet? If not, would it be possible for you to set the pom
to HBase-1.0.1 instead so that master will build? Just don't want to
leave it in a broken state.
Thanks,
James

On Thu, Mar 19, 2015 at 7:31 PM, Enis Söztutar  wrote:
> About the 4.x-HBase-1.x branch, it seems that I have spoken too soon.
> Current branch head does not compile with latest HBase-1.1.0-SNAPSHOT:
>
> It seems the RegionScanner changes are the problem. Let me look into how we
> can resolve those for future compatibility.
>
> Enis
>
> On Thu, Mar 19, 2015 at 2:15 PM, Enis Söztutar  wrote:
>
>> Hi,
>>
>> As per private PMC threads and the dev discussions [1], I have created two
>> new branches for 4.x development for supporting both HBase-0.98 and
>> HBase-1.0 versions. The goal is to have 4.4.0 and 4.5.0, etc releases which
>> support both of the HBase versions and possibly HBase-1.1.0+ as well.
>>
>> See [1] for why the branches are needed (this seems like the least bad
>> approach). Here are the changes I did for this:
>>
>> BRANCH CHANGES:
>> - Committed PHOENIX-1642 to master
>> - Created branch-4.x-HBase-0.98. Pushed to git repo
>> - Created branch-4.x-HBase-1.x. Pushed to git repo
>> - Changed versions to be 4.4.0-HBase-0.98-SNAPSHOT and
>> 4.4.0-HBase-1.x-SNAPSHOT respectively in above branches
>> - Cherry-picked PHOENIX-1642 to branch-4.x-HBase-1.x
>> - Deleted branch named "4.0". (there is no rename of branches in git)
>>
>> I have named the branch 4.x-HBase-1.x instead of suffix HBase-1.0 in hopes
>> that further HBase-1.1, 1.2 can be supported in this branch and we can get
>> away without branching again for 1.1. See especially HBASE-12972. We can
>> change this later on if it is not the case.
>>
>>
>> JENKINS CHANGES:
>> - Disabled Phoenix-4.0 job (Lets keep it around for a couple of days just
>> in case)
>> - Created new jobs for these two branches:
>>
>> https://builds.apache.org/view/All/job/Phoenix-4.x-HBase-0.98/
>> https://builds.apache.org/job/Phoenix-4.x-HBase-1.x/
>>
>> The build should be similar to the previous 4.0 branch builds.
>>
>>
>> JIRA CHANGES:
>>  - Renamed release version 4.4 in jira to 4.4.0
>>
>>
>> Further changes coming shortly unless objection:
>>  - Delete jenkins job
>> https://builds.apache.org/view/All/job/Phoenix%202.0/  (does not seem to
>> be used for more than 1 year)
>>  - Delete jenkins job https://builds.apache.org/view/All/job/Phoenix-2.0/
>>  - Delete jenkins job https://builds.apache.org/view/All/job/Phoenix-4.0/
>>
>>
>> How does this affect development and releases?
>>  - Current master is version 5.0.0-SNAPSHOT. It builds with
>> HBase-1.0.1-SNAPSHOT (from apache snapshots repo).
>>  - branch-4.x-HBase-0.98 is very similar to old 4.0 branch. It builds with
>> HBase-0.98.9-hadoop2
>>  - branch-4.x-HBase-1.x is forked from branch-4.x-HBase-0.98 and builds
>> with HBase-1.0.1-SNAPSHOT.
>>  - There should be two release artifacts (or releases simultaneously) for
>> 4.4 release. One will have version 4.4.0-HBase-0.98 and the other
>> 4.4.0-HBase-1.x. We can make it so that the RM creates both releases at the
>> same time, and the VOTE applies to both releases.
>>  - All changes MUST be committed to both branches for future 4.x releases
>> unless it is HBase version specific. There is no way to auto-enforce it, so
>> all committers should take this into account. The patches might differ
>> sligtly. Before the release RM may do some manual checks to ensure that
>> every patch is commmitted to both branches.
>>  - Old 4.0 is deleted from git repository. Please re-check or rename your
>> local branches. Please do not push anything there (as it will re-create the
>> branch).
>>  - There is only one jira version 4.4.0, which should apply equally to
>> both release versions. If needed we can differentiate these in jira as
>> well. Let me know.
>>  - Before the 4.4.0 release, RM should fork both 4.x branches and name
>> them 4.4-HBase-XXX. At that time, we will have 1 master branch, 2 of 4.x
>> branches and 2 of 4.4 branches.
>>
>> Let me know if you have further concerns. Let's see how well this process
>> works.
>>
>> Thanks,
>> Enis
>>
>> Ref:
>> [1] http://search-hadoop.com/m/lz2la1GgkPx
>>
>>

[jira] [Updated] (PHOENIX-1765) Add time related buildins


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alicia Ying Shu updated PHOENIX-1765:
-
Description: 
Week(), DAYOFMONTH(), Hour(), Minute()

>From Oracle doc:
WEEK(date)   An integer from 1 to 53 representing the week of 
 the year in date
DAYOFMONTH(date)  An integer from 1 to 31 representing the day of 
 the month in date
HOUR(time)   An integer from 0 to 23 representing the hour 
 component of time
MINUTE(time) An integer from 0 to 59 representing the minute 
 component of time

  was:Week(), Day(), Hour(), Minute(), MillisOfSecond()


> Add time related buildins
> -
>
> Key: PHOENIX-1765
> URL: https://issues.apache.org/jira/browse/PHOENIX-1765
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
>
> Week(), DAYOFMONTH(), Hour(), Minute()
> From Oracle doc:
> WEEK(date)   An integer from 1 to 53 representing the week of 
>  the year in date
> DAYOFMONTH(date)  An integer from 1 to 31 representing the day of 
>  the month in date
> HOUR(time)   An integer from 0 to 23 representing the hour 
>  component of time
> MINUTE(time) An integer from 0 to 59 representing the minute 
>  component of time



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1756) Add Month() and Second() buildin functions


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alicia Ying Shu updated PHOENIX-1756:
-
Description: 
>From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
>buildin. 

MONTH(date)  An integer from 1 to 12 representing the month 
 component of date
SECOND(time) An integer from 0 to 59 representing the second 
 component of time

  was:From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
buildin. 


> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 
> MONTH(date)  An integer from 1 to 12 representing the month 
>  component of date
> SECOND(time) An integer from 0 to 59 representing the second 
>  component of time



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (PHOENIX-1756) Add Month() and Second() buildin functions


[ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372299#comment-14372299
 ] 

Alicia Ying Shu edited comment on PHOENIX-1756 at 3/21/15 12:39 AM:


We picked the functions based on what time functions customers would use 
mostly. In Phoenix-1765, will implement WEEK(date),  Minute(), Hour(), 
DAYOFMONTH(). 


was (Author: aliciashu):
We picked the functions based on what time functions customers would use 
mostly. In Phoenix-1765, will implement WEEK(date),  Minute(), Hour(), Day() 
and MillisOfSecond() as well. 

> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 
> MONTH(date)  An integer from 1 to 12 representing the month 
>  component of date
> SECOND(time) An integer from 0 to 59 representing the second 
>  component of time



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1756) Add Month() and Second() buildin functions


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alicia Ying Shu updated PHOENIX-1756:
-
Attachment: Phoenix-1756-v1.patch

> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756-v1.patch, Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 
> MONTH(date)  An integer from 1 to 12 representing the month 
>  component of date
> SECOND(time) An integer from 0 to 59 representing the second 
>  component of time



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1756) Add Month() and Second() buildin functions


[ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372398#comment-14372398
 ] 

Alicia Ying Shu commented on PHOENIX-1756:
--

[~jamestaylor] Uploaded another patch calculating seconds of a minute for 
SECOND() instead of instantiating a DateTime.

> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756-v1.patch, Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 
> MONTH(date)  An integer from 1 to 12 representing the month 
>  component of date
> SECOND(time) An integer from 0 to 59 representing the second 
>  component of time



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (PHOENIX-1756) Add Month() and Second() buildin functions


[ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372401#comment-14372401
 ] 

James Taylor commented on PHOENIX-1756:
---

YOu'll need to encode as int instead of long and cast the % you're doing to an 
int, like this:
{code}
+@Override
+public boolean evaluate(Tuple tuple, ImmutableBytesWritable ptr) {
+Expression expression = getChildExpression();
+if (!expression.evaluate(tuple, ptr)) {
+return false;
+}
+if ( ptr.getLength() == 0) {
+return true; //means null
+}
+long dateTime = expression.getDataType().getCodec().decodeLong(ptr, 
expression.getSortOrder());
+int sec = (int)((dateTime/1000) % 60);
+PDataType returnType = getDataType();
+byte[] byteValue = new byte[returnType.getByteSize()];
+returnType.getCodec().encodeInt(sec, byteValue, 0);
+ptr.set(byteValue);
+return true;
+}
{code}

> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756-v1.patch, Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 
> MONTH(date)  An integer from 1 to 12 representing the month 
>  component of date
> SECOND(time) An integer from 0 to 59 representing the second 
>  component of time



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1428) Keep scanner open on server and pace by client instead of spooling


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Taylor updated PHOENIX-1428:
--
Assignee: Samarth Jain  (was: Dave Hacker)

> Keep scanner open on server and pace by client instead of spooling
> --
>
> Key: PHOENIX-1428
> URL: https://issues.apache.org/jira/browse/PHOENIX-1428
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Samarth Jain
>
> Instead of spooling a batch of results for all chunked scans to the client, 
> keep the scan open and pace it through pre-fetching. This will perform much 
> better for a full table scan with a LIMIT = 1, as this case currently will 
> run a scan for every guidepost, each returning a single row.
> [~lhofhansl]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [IMPORTANT] Some changes to branches and releases for 4.4+

2015-03-20 Thread Enis Söztutar

The pom is pointing to 1.0.1-SNAPSHOT. Jenkins build was fine yesterday. I
tested locally with 1.1.0-SNAPSHOT.

See https://issues.apache.org/jira/browse/PHOENIX-1763.

Enis

On Fri, Mar 20, 2015 at 4:53 PM, James Taylor 
wrote:

> Is this fixed yet? If not, would it be possible for you to set the pom
> to HBase-1.0.1 instead so that master will build? Just don't want to
> leave it in a broken state.
> Thanks,
> James
>
> On Thu, Mar 19, 2015 at 7:31 PM, Enis Söztutar  wrote:
> > About the 4.x-HBase-1.x branch, it seems that I have spoken too soon.
> > Current branch head does not compile with latest HBase-1.1.0-SNAPSHOT:
> >
> > It seems the RegionScanner changes are the problem. Let me look into how
> we
> > can resolve those for future compatibility.
> >
> > Enis
> >
> > On Thu, Mar 19, 2015 at 2:15 PM, Enis Söztutar  wrote:
> >
> >> Hi,
> >>
> >> As per private PMC threads and the dev discussions [1], I have created
> two
> >> new branches for 4.x development for supporting both HBase-0.98 and
> >> HBase-1.0 versions. The goal is to have 4.4.0 and 4.5.0, etc releases
> which
> >> support both of the HBase versions and possibly HBase-1.1.0+ as well.
> >>
> >> See [1] for why the branches are needed (this seems like the least bad
> >> approach). Here are the changes I did for this:
> >>
> >> BRANCH CHANGES:
> >> - Committed PHOENIX-1642 to master
> >> - Created branch-4.x-HBase-0.98. Pushed to git repo
> >> - Created branch-4.x-HBase-1.x. Pushed to git repo
> >> - Changed versions to be 4.4.0-HBase-0.98-SNAPSHOT and
> >> 4.4.0-HBase-1.x-SNAPSHOT respectively in above branches
> >> - Cherry-picked PHOENIX-1642 to branch-4.x-HBase-1.x
> >> - Deleted branch named "4.0". (there is no rename of branches in git)
> >>
> >> I have named the branch 4.x-HBase-1.x instead of suffix HBase-1.0 in
> hopes
> >> that further HBase-1.1, 1.2 can be supported in this branch and we can
> get
> >> away without branching again for 1.1. See especially HBASE-12972. We can
> >> change this later on if it is not the case.
> >>
> >>
> >> JENKINS CHANGES:
> >> - Disabled Phoenix-4.0 job (Lets keep it around for a couple of days
> just
> >> in case)
> >> - Created new jobs for these two branches:
> >>
> >> https://builds.apache.org/view/All/job/Phoenix-4.x-HBase-0.98/
> >> https://builds.apache.org/job/Phoenix-4.x-HBase-1.x/
> >>
> >> The build should be similar to the previous 4.0 branch builds.
> >>
> >>
> >> JIRA CHANGES:
> >>  - Renamed release version 4.4 in jira to 4.4.0
> >>
> >>
> >> Further changes coming shortly unless objection:
> >>  - Delete jenkins job
> >> https://builds.apache.org/view/All/job/Phoenix%202.0/  (does not seem
> to
> >> be used for more than 1 year)
> >>  - Delete jenkins job
> https://builds.apache.org/view/All/job/Phoenix-2.0/
> >>  - Delete jenkins job
> https://builds.apache.org/view/All/job/Phoenix-4.0/
> >>
> >>
> >> How does this affect development and releases?
> >>  - Current master is version 5.0.0-SNAPSHOT. It builds with
> >> HBase-1.0.1-SNAPSHOT (from apache snapshots repo).
> >>  - branch-4.x-HBase-0.98 is very similar to old 4.0 branch. It builds
> with
> >> HBase-0.98.9-hadoop2
> >>  - branch-4.x-HBase-1.x is forked from branch-4.x-HBase-0.98 and builds
> >> with HBase-1.0.1-SNAPSHOT.
> >>  - There should be two release artifacts (or releases simultaneously)
> for
> >> 4.4 release. One will have version 4.4.0-HBase-0.98 and the other
> >> 4.4.0-HBase-1.x. We can make it so that the RM creates both releases at
> the
> >> same time, and the VOTE applies to both releases.
> >>  - All changes MUST be committed to both branches for future 4.x
> releases
> >> unless it is HBase version specific. There is no way to auto-enforce
> it, so
> >> all committers should take this into account. The patches might differ
> >> sligtly. Before the release RM may do some manual checks to ensure that
> >> every patch is commmitted to both branches.
> >>  - Old 4.0 is deleted from git repository. Please re-check or rename
> your
> >> local branches. Please do not push anything there (as it will re-create
> the
> >> branch).
> >>  - There is only one jira version 4.4.0, which should apply equally to
> >> both release versions. If needed we can differentiate these in jira as
> >> well. Let me know.
> >>  - Before the 4.4.0 release, RM should fork both 4.x branches and name
> >> them 4.4-HBase-XXX. At that time, we will have 1 master branch, 2 of 4.x
> >> branches and 2 of 4.4 branches.
> >>
> >> Let me know if you have further concerns. Let's see how well this
> process
> >> works.
> >>
> >> Thanks,
> >> Enis
> >>
> >> Ref:
> >> [1] http://search-hadoop.com/m/lz2la1GgkPx
> >>
> >>
>

Re: [IMPORTANT] Some changes to branches and releases for 4.4+

2015-03-20 Thread James Taylor

Ah, got it. Thanks, Enis!

On Fri, Mar 20, 2015 at 5:57 PM, Enis Söztutar  wrote:
> The pom is pointing to 1.0.1-SNAPSHOT. Jenkins build was fine yesterday. I
> tested locally with 1.1.0-SNAPSHOT.
>
> See https://issues.apache.org/jira/browse/PHOENIX-1763.
>
> Enis
>
> On Fri, Mar 20, 2015 at 4:53 PM, James Taylor 
> wrote:
>
>> Is this fixed yet? If not, would it be possible for you to set the pom
>> to HBase-1.0.1 instead so that master will build? Just don't want to
>> leave it in a broken state.
>> Thanks,
>> James
>>
>> On Thu, Mar 19, 2015 at 7:31 PM, Enis Söztutar  wrote:
>> > About the 4.x-HBase-1.x branch, it seems that I have spoken too soon.
>> > Current branch head does not compile with latest HBase-1.1.0-SNAPSHOT:
>> >
>> > It seems the RegionScanner changes are the problem. Let me look into how
>> we
>> > can resolve those for future compatibility.
>> >
>> > Enis
>> >
>> > On Thu, Mar 19, 2015 at 2:15 PM, Enis Söztutar  wrote:
>> >
>> >> Hi,
>> >>
>> >> As per private PMC threads and the dev discussions [1], I have created
>> two
>> >> new branches for 4.x development for supporting both HBase-0.98 and
>> >> HBase-1.0 versions. The goal is to have 4.4.0 and 4.5.0, etc releases
>> which
>> >> support both of the HBase versions and possibly HBase-1.1.0+ as well.
>> >>
>> >> See [1] for why the branches are needed (this seems like the least bad
>> >> approach). Here are the changes I did for this:
>> >>
>> >> BRANCH CHANGES:
>> >> - Committed PHOENIX-1642 to master
>> >> - Created branch-4.x-HBase-0.98. Pushed to git repo
>> >> - Created branch-4.x-HBase-1.x. Pushed to git repo
>> >> - Changed versions to be 4.4.0-HBase-0.98-SNAPSHOT and
>> >> 4.4.0-HBase-1.x-SNAPSHOT respectively in above branches
>> >> - Cherry-picked PHOENIX-1642 to branch-4.x-HBase-1.x
>> >> - Deleted branch named "4.0". (there is no rename of branches in git)
>> >>
>> >> I have named the branch 4.x-HBase-1.x instead of suffix HBase-1.0 in
>> hopes
>> >> that further HBase-1.1, 1.2 can be supported in this branch and we can
>> get
>> >> away without branching again for 1.1. See especially HBASE-12972. We can
>> >> change this later on if it is not the case.
>> >>
>> >>
>> >> JENKINS CHANGES:
>> >> - Disabled Phoenix-4.0 job (Lets keep it around for a couple of days
>> just
>> >> in case)
>> >> - Created new jobs for these two branches:
>> >>
>> >> https://builds.apache.org/view/All/job/Phoenix-4.x-HBase-0.98/
>> >> https://builds.apache.org/job/Phoenix-4.x-HBase-1.x/
>> >>
>> >> The build should be similar to the previous 4.0 branch builds.
>> >>
>> >>
>> >> JIRA CHANGES:
>> >>  - Renamed release version 4.4 in jira to 4.4.0
>> >>
>> >>
>> >> Further changes coming shortly unless objection:
>> >>  - Delete jenkins job
>> >> https://builds.apache.org/view/All/job/Phoenix%202.0/  (does not seem
>> to
>> >> be used for more than 1 year)
>> >>  - Delete jenkins job
>> https://builds.apache.org/view/All/job/Phoenix-2.0/
>> >>  - Delete jenkins job
>> https://builds.apache.org/view/All/job/Phoenix-4.0/
>> >>
>> >>
>> >> How does this affect development and releases?
>> >>  - Current master is version 5.0.0-SNAPSHOT. It builds with
>> >> HBase-1.0.1-SNAPSHOT (from apache snapshots repo).
>> >>  - branch-4.x-HBase-0.98 is very similar to old 4.0 branch. It builds
>> with
>> >> HBase-0.98.9-hadoop2
>> >>  - branch-4.x-HBase-1.x is forked from branch-4.x-HBase-0.98 and builds
>> >> with HBase-1.0.1-SNAPSHOT.
>> >>  - There should be two release artifacts (or releases simultaneously)
>> for
>> >> 4.4 release. One will have version 4.4.0-HBase-0.98 and the other
>> >> 4.4.0-HBase-1.x. We can make it so that the RM creates both releases at
>> the
>> >> same time, and the VOTE applies to both releases.
>> >>  - All changes MUST be committed to both branches for future 4.x
>> releases
>> >> unless it is HBase version specific. There is no way to auto-enforce
>> it, so
>> >> all committers should take this into account. The patches might differ
>> >> sligtly. Before the release RM may do some manual checks to ensure that
>> >> every patch is commmitted to both branches.
>> >>  - Old 4.0 is deleted from git repository. Please re-check or rename
>> your
>> >> local branches. Please do not push anything there (as it will re-create
>> the
>> >> branch).
>> >>  - There is only one jira version 4.4.0, which should apply equally to
>> >> both release versions. If needed we can differentiate these in jira as
>> >> well. Let me know.
>> >>  - Before the 4.4.0 release, RM should fork both 4.x branches and name
>> >> them 4.4-HBase-XXX. At that time, we will have 1 master branch, 2 of 4.x
>> >> branches and 2 of 4.4 branches.
>> >>
>> >> Let me know if you have further concerns. Let's see how well this
>> process
>> >> works.
>> >>
>> >> Thanks,
>> >> Enis
>> >>
>> >> Ref:
>> >> [1] http://search-hadoop.com/m/lz2la1GgkPx
>> >>
>> >>
>>

[jira] [Commented] (PHOENIX-1676) Set priority of Index Updates correctly


[ 
https://issues.apache.org/jira/browse/PHOENIX-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372420#comment-14372420
 ] 

James Taylor commented on PHOENIX-1676:
---

+1. Please commit to 4.3, new 4.x branch, and master. Thanks, [~tdsilva]!

> Set priority of Index Updates correctly 
> 
>
> Key: PHOENIX-1676
> URL: https://issues.apache.org/jira/browse/PHOENIX-1676
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.0.0, 5.0.0, 4.3.1
>Reporter: Thomas D'Silva
>Assignee: Thomas D'Silva
> Attachments: PHOENIX-1676-4.x-HBase-0.98-v2.patch, 
> PHOENIX-1676-4.x-HBase-0.98.patch, PHOENIX-1676-4.x-HBase-1.x-v2.patch, 
> PHOENIX-1676-4.x-HBase-1.x.patch
>
>
> I spoke to Jesse offline about this. 
> The priority of index updates isn't being set correctly because of the use of 
> CoprocessorHConnection (which all coprocessors use if they create an HTable 
> via the CPEnvironment).
> Specifically the flow happens like this: the CoprocessorHTableFactory 
> attempts to set the connection qos factory, but it is ignored because the 
> CoprocessorHConnection is used (instead of a standard HConnection) and the 
> #getClient method just goes straight into the rpc scheduler of the 
> HRegionServer, if its on the same server. This allows the region to be 
> directly accessed, but without actually going over the loopback or 
> serializing any information.
> However, this means it ignores the configured rpccontroller factory and the 
> override setting of the rpc priority. We probably shouldn't be runtime 
> changing the configuration - instead we should probably be using some other 
> serialized information.
> The primary fix would seems to be that the regionserver needs to be 
> configured with the IndexQosRpcControllerFactory and then use a static map 
> (or cache of the index metadata) to set the qos for the index servers. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Comment Edited] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information

Hi All,

As mentioned earlier I completed my research on how existing database
systems visualize tracing information. (Mysql, Postgres etc.)

Please give me some feedback on it? Or if you have any questions regard to
that or any unclear part I'd be glad to help you out.

I also successfully built and ran phoenix and went through
SYSTEM.TRACING_STATS
table and tried to understand it's schema. I would like to write a blog
post and share my knowledge with the community.

Can you also mention some of the attributes and resources where I can
further get a good idea on the tracing information before I try to come up
with ways to visualize them?

I'm writing my proposal for GSoC 2015 and shall share it as soon as I
finish. Hoping you would be generous in giving out feedback.

Thanks.

BR,
Nishani

On Fri, Mar 20, 2015 at 2:24 PM, Nishani (JIRA)  wrote:

>
> [
> https://issues.apache.org/jira/browse/PHOENIX-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370997#comment-14370997
> ]
>
> Nishani  edited comment on PHOENIX-1118 at 3/20/15 8:54 AM:
> 
>
> Hi,
>
> I have gone through some resources regarding visualization of trace info
> on database servers (Postgres/MySQL, MSSQL).
>
> The DTrace function in MySQL is a profiler that creates flame graphs. [1]
> A tool for visualizations of a database system [2]
> Generates images with help of GraphViz for
> Some data modeling tools [4]
> DBVisualizer Tool [5]
> Data Visualization Application where data is input from a database or a
> file and exported as image or a customized template [6]
> Visualizing Postgres [7]
> A Research Paper on Modeling Trace Information[8]
> A Tool for visualizing Trace Info [9]
>
> Given above is a brief summary of the details I found. Hope it would help
> me to better understand the formats and values of the input traces and
> different available methods of graphically representing them.
>
> Based on them I hope to come up with the most suitable method of Visually
> representing the said data.
>
> Regarding the installation I presume that the HBase version that is needed
> to run Phoenix for visualizing trace info can be as Standalone and that
> cluster view is not needed(Distributed Version).
>
> Thank you.
> BR,
> Nishani
>
> [1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
> [2] http://docs.cartodb.com/cartodb-editor.html#visualizations
> [3]
> https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/SchemaDisplay
> [4] http://www.databaseanswers.org/modelling_tools.htm
> [5] http://www.dbvis.com/
> [6] https://sites.google.com/site/datavisualizationapplication/
> [7] http://www.pgcon.org/2013/schedule/track/Performance/588.en.html
> [8] http://link.springer.com/chapter/10.1007%2F978-3-642-40787-1_13
> [9]
> http://www.upscene.com/documentation/fbtm3/index.html?qsg_trace_data_visualization.htm
>
>
>
> was (Author: nishani):
> Hi,
>
> I have gone through some resources regarding visualization of trace info
> on database servers (Postgres/MySQL, MSSQL).
>
> The DTrace function in MySQL is a profiler that creates flame graphs. [1]
> A tool for visualizations of a database system [2]
> Generates images with help of GraphViz for
> Some data modeling tools [4]
> DBVisualizer Tool [5]
> Data Visualization Application where data is input from a database or a
> file and exported as image or a customized template [6]
> Visualizing Postgres [7]
> A Research Paper on Modeling Trace Information[8]
> A Tool for visualizing Trace Info
>
> Given above is a brief summary of the details I found. Hope it would help
> me to better understand the formats and values of the input traces and
> different available methods of graphically representing them.
>
> Based on them I hope to come up with the most suitable method of Visually
> representing the said data.
>
> Regarding the installation I presume that the HBase version that is needed
> to run Phoenix for visualizing trace info can be as Standalone and that
> cluster view is not needed(Distributed Version).
>
> Thank you.
> BR,
> Nishani
>
> [1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
> [2] http://docs.cartodb.com/cartodb-editor.html#visualizations
> [3]
> https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/SchemaDisplay
> [4] http://www.databaseanswers.org/modelling_tools.htm
> [5] http://www.dbvis.com/
> [6] https://sites.google.com/site/datavisualizationapplication/
> [7] http://www.pgcon.org/2013/schedule/track/Performance/588.en.html
> [8] http://link.springer.com/chapter/10.1007%2F978-3-642-40787-1_13
> [9]
> http://www.upscene.com/documentation/fbtm3/index.html?qsg_trace_data_visualization.htm
>
>
> > Provide a tool for visualizing Phoenix tracing information
> > --
> >
> > Key: PHOENIX-1118
> > URL: https://issues.apache.org/jira/browse/PHOENIX-1118
> >

[jira] [Commented] (PHOENIX-1287) Use the joni byte[] regex engine in place of j.u.regex

2015-03-20 Thread Shuxiong Ye (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372461#comment-14372461
 ] 

Shuxiong Ye commented on PHOENIX-1287:
--

Hi [~jamestaylor],

I have a question about PVarchar.toObject. When we are trying to put a String 
"" into ImmutableBytesWritable, and turn it back to String like the following 
code, we get null back. Why not "" back here?

{code:java}
Expression srcExp = LiteralExpression.newConstant("", TYPE);
ImmutableBytesWritable ptr = new ImmutableBytesWritable();
boolean eval = srcExp.evaluate(null, ptr);
String result = (String)srcExp.getDataType().toObject(ptr);
System.out.println(result); // result = null, here
assertTrue("".equals(result));
{code}

In PVarchar.java,
{code:java}
  @Override
  public Object toObject(byte[] bytes, int offset, int length, PDataType 
actualType,
  SortOrder sortOrder, Integer maxLength, Integer scale) {
if (!actualType.isCoercibleTo(this)) {
  throwConstraintViolationException(actualType, this);
}
if (length == 0) {  // < here to set it null when length is zero
  return null;
}
if (sortOrder == SortOrder.DESC) {
  bytes = SortOrder.invert(bytes, offset, length);
  offset = 0;
}
return Bytes.toString(bytes, offset, length); // <-- here we call 
Bytes.toString from HBase, in which it will return "" when length is zero, and 
null when bytes ptr is null.
  }
{code}


> Use the joni byte[] regex engine in place of j.u.regex
> --
>
> Key: PHOENIX-1287
> URL: https://issues.apache.org/jira/browse/PHOENIX-1287
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Shuxiong Ye
>  Labels: gsoc2015
>
> See HBASE-11907. We'd get a 2x perf benefit plus it's driven off of byte[] 
> instead of strings.Thanks for the pointer, [~apurtell].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Comment Edited] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information

2015-03-20 Thread Jesse Yates

Hi Nishani,

Thanks for your interesting in phoenix!

For tracing, the first thing I would recommend doing is reading the tracing
documentation: http://phoenix.apache.org/tracing.html

A careful reading there would then lead you to look at
org.apache.phoenix.trace.PhoenixTableMetricsWriterIT for running a unit
test that actually looks at the traces being written.

>From there you can look into the org.apache.phoenix.trace.TraceReader which
is actually reading any traces out from the table.

Admittedly, some of the schema is a little bit opaque, but you can take a
crack at it if you read through
org.apache.phoenix.trace.PhoenixMetricsSink, specifically #createTable()
and #putMetrics(). The key to understand is that there are generic
annotations and tags that can be appended to a trace - specifically, onto a
span of the trace - at any point in its life. To manage that the only known
column for the tags and annotations, respectively, is a count column. Then
with the count column we can build the names of the dynamic columns
 for each annotation and
tag.

For instance, say there is a tag count column tags.count with value 1 and
annotations.count with value 2. Then we know there are also the dynamic
columns: tags.t0, annotations.a0, annotations.a1.

Also see the HTace documentation  for
info on the version of HTrace we are using - we could upgrade, but no one
has had a chance to validate that.

BTW, looking at the documentation, its a little out of date for tracing -
since we removed support for Hadoop2 we removed some of the indirection so
classes like PhoenixTableMetricsWriter got renamed. If you are interested,
we would also love if you wanted to help keep our docs up to date with what
you find!

Hope this helps,
Jesse
(the guy who wrote tracing for phoenix)

On Fri, Mar 20, 2015 at 7:13 PM, Ayola Jayamaha 
wrote:

> Hi All,
>
> As mentioned earlier I completed my research on how existing database
> systems visualize tracing information. (Mysql, Postgres etc.)
>
> Please give me some feedback on it? Or if you have any questions regard to
> that or any unclear part I'd be glad to help you out.
>
> I also successfully built and ran phoenix and went through
> SYSTEM.TRACING_STATS
> table and tried to understand it's schema. I would like to write a blog
> post and share my knowledge with the community.
>
> Can you also mention some of the attributes and resources where I can
> further get a good idea on the tracing information before I try to come up
> with ways to visualize them?
>
> I'm writing my proposal for GSoC 2015 and shall share it as soon as I
> finish. Hoping you would be generous in giving out feedback.
>
> Thanks.
>
> BR,
> Nishani
>
> On Fri, Mar 20, 2015 at 2:24 PM, Nishani (JIRA)  wrote:
>
> >
> > [
> >
> https://issues.apache.org/jira/browse/PHOENIX-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14370997#comment-14370997
> > ]
> >
> > Nishani  edited comment on PHOENIX-1118 at 3/20/15 8:54 AM:
> > 
> >
> > Hi,
> >
> > I have gone through some resources regarding visualization of trace info
> > on database servers (Postgres/MySQL, MSSQL).
> >
> > The DTrace function in MySQL is a profiler that creates flame graphs. [1]
> > A tool for visualizations of a database system [2]
> > Generates images with help of GraphViz for
> > Some data modeling tools [4]
> > DBVisualizer Tool [5]
> > Data Visualization Application where data is input from a database or a
> > file and exported as image or a customized template [6]
> > Visualizing Postgres [7]
> > A Research Paper on Modeling Trace Information[8]
> > A Tool for visualizing Trace Info [9]
> >
> > Given above is a brief summary of the details I found. Hope it would help
> > me to better understand the formats and values of the input traces and
> > different available methods of graphically representing them.
> >
> > Based on them I hope to come up with the most suitable method of Visually
> > representing the said data.
> >
> > Regarding the installation I presume that the HBase version that is
> needed
> > to run Phoenix for visualizing trace info can be as Standalone and that
> > cluster view is not needed(Distributed Version).
> >
> > Thank you.
> > BR,
> > Nishani
> >
> > [1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
> > [2] http://docs.cartodb.com/cartodb-editor.html#visualizations
> > [3]
> > https://bitbucket.org/zzzeek/sqlalchemy/wiki/UsageRecipes/SchemaDisplay
> > [4] http://www.databaseanswers.org/modelling_tools.htm
> > [5] http://www.dbvis.com/
> > [6] https://sites.google.com/site/datavisualizationapplication/
> > [7] http://www.pgcon.org/2013/schedule/track/Performance/588.en.html
> > [8] http://link.springer.com/chapter/10.1007%2F978-3-642-40787-1_13
> > [9]
> >
> http://www.upscene.com/documentation/fbtm3/index.html?qsg_trace_data

[jira] [Comment Edited] (PHOENIX-1287) Use the joni byte[] regex engine in place of j.u.regex

2015-03-20 Thread Shuxiong Ye (JIRA)


[ 
https://issues.apache.org/jira/browse/PHOENIX-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372461#comment-14372461
 ] 

Shuxiong Ye edited comment on PHOENIX-1287 at 3/21/15 2:46 AM:
---

Hi [~jamestaylor],

I have a question about PVarchar.toObject. When we are trying to put a String 
"" into ImmutableBytesWritable, and turn it back to String like the following 
code, we get null back. Why not "" back here?

{code:java}
Expression srcExp = LiteralExpression.newConstant("", 
PVarchar.INSTANCE);
ImmutableBytesWritable ptr = new ImmutableBytesWritable();
boolean eval = srcExp.evaluate(null, ptr);
String result = (String)srcExp.getDataType().toObject(ptr);
System.out.println(result); // result = null, here
assertTrue("".equals(result));
{code}

In PVarchar.java,
{code:java}
  @Override
  public Object toObject(byte[] bytes, int offset, int length, PDataType 
actualType,
  SortOrder sortOrder, Integer maxLength, Integer scale) {
if (!actualType.isCoercibleTo(this)) {
  throwConstraintViolationException(actualType, this);
}
if (length == 0) {  // < here to set it null when length is zero
  return null;
}
if (sortOrder == SortOrder.DESC) {
  bytes = SortOrder.invert(bytes, offset, length);
  offset = 0;
}
return Bytes.toString(bytes, offset, length); // <-- here we call 
Bytes.toString from HBase, in which it will return "" when length is zero, and 
null when bytes ptr is null.
  }
{code}



was (Author: shuxi0ng):
Hi [~jamestaylor],

I have a question about PVarchar.toObject. When we are trying to put a String 
"" into ImmutableBytesWritable, and turn it back to String like the following 
code, we get null back. Why not "" back here?

{code:java}
Expression srcExp = LiteralExpression.newConstant("", TYPE);
ImmutableBytesWritable ptr = new ImmutableBytesWritable();
boolean eval = srcExp.evaluate(null, ptr);
String result = (String)srcExp.getDataType().toObject(ptr);
System.out.println(result); // result = null, here
assertTrue("".equals(result));
{code}

In PVarchar.java,
{code:java}
  @Override
  public Object toObject(byte[] bytes, int offset, int length, PDataType 
actualType,
  SortOrder sortOrder, Integer maxLength, Integer scale) {
if (!actualType.isCoercibleTo(this)) {
  throwConstraintViolationException(actualType, this);
}
if (length == 0) {  // < here to set it null when length is zero
  return null;
}
if (sortOrder == SortOrder.DESC) {
  bytes = SortOrder.invert(bytes, offset, length);
  offset = 0;
}
return Bytes.toString(bytes, offset, length); // <-- here we call 
Bytes.toString from HBase, in which it will return "" when length is zero, and 
null when bytes ptr is null.
  }
{code}


> Use the joni byte[] regex engine in place of j.u.regex
> --
>
> Key: PHOENIX-1287
> URL: https://issues.apache.org/jira/browse/PHOENIX-1287
> Project: Phoenix
>  Issue Type: Bug
>Reporter: James Taylor
>Assignee: Shuxiong Ye
>  Labels: gsoc2015
>
> See HBASE-11907. We'd get a 2x perf benefit plus it's driven off of byte[] 
> instead of strings.Thanks for the pointer, [~apurtell].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1756) Add Month() and Second() buildin functions


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alicia Ying Shu updated PHOENIX-1756:
-
Attachment: Phoenix-1756-v2.patch

> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756-v1.patch, Phoenix-1756-v2.patch, 
> Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 
> MONTH(date)  An integer from 1 to 12 representing the month 
>  component of date
> SECOND(time) An integer from 0 to 59 representing the second 
>  component of time



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Comment Edited] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information

On Sat, Mar 21, 2015 at 8:07 AM, Jesse Yates  wrote:

> nnotations.


Hi Jesse,

Thanks for the quick and informative reply. I would be sure to go through
all the resources regarding tracing that you have shared.

I'm so happy and honored for the chance of interaction with you who wrote
tracing for phoenix. I would be needing more assistance from you given that
I'm implementing a task where you have expectancy.(visualizing tracing
information). I hope to I can take tracing which you created for Phoenix to
the next level - visualize

 I'd be so glad to update your documentation as I'm a keen writer and have
considerable experience  and passion in technical writing as I too maintain
my personal blog for sharing knowledge.[1]

Thanks.

BR,
Nishani.

[1] http://ayolajayamaha.blogspot.com



-- 
Best Regards,
Ayola Jayamaha

[jira] [Commented] (PHOENIX-1756) Add Month() and Second() buildin functions


[ 
https://issues.apache.org/jira/browse/PHOENIX-1756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372474#comment-14372474
 ] 

Alicia Ying Shu commented on PHOENIX-1756:
--

[~jamestaylor] Thanks! Attached a patch.

> Add Month() and Second() buildin functions
> --
>
> Key: PHOENIX-1756
> URL: https://issues.apache.org/jira/browse/PHOENIX-1756
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Alicia Ying Shu
>Assignee: Alicia Ying Shu
> Attachments: Phoenix-1756-v1.patch, Phoenix-1756-v2.patch, 
> Phoenix-1756.patch
>
>
> From Oracle doc: Month(date) and Second(date). Very similar to Year(date) 
> buildin. 
> MONTH(date)  An integer from 1 to 12 representing the month 
>  component of date
> SECOND(time) An integer from 0 to 59 representing the second 
>  component of time



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (PHOENIX-1763) Support building with HBase-1.1.0

2015-03-20 Thread Enis Soztutar (JIRA)


 [ 
https://issues.apache.org/jira/browse/PHOENIX-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Enis Soztutar updated PHOENIX-1763:
---
Attachment: phoenix-1763_v1.patch

Here is an initial patch. It compiles, but some of the ITs fail still. 

> Support building with HBase-1.1.0 
> --
>
> Key: PHOENIX-1763
> URL: https://issues.apache.org/jira/browse/PHOENIX-1763
> Project: Phoenix
>  Issue Type: Improvement
>Reporter: Enis Soztutar
> Fix For: 5.0.0
>
> Attachments: phoenix-1763_v1.patch
>
>
> HBase-1.1 is in the works. However, due to HBASE-11544 and possibly 
> HBASE-12972 and more, we need some changes for supporting HBase-1.1 even 
> after PHOENIX-1642. 
> We can decide on a plan to support (or not) HBase-1.1 on which branches by 
> the time it comes out. Let's use subtasks to keep progress for build support 
> for 1.1.0-SNAPSHOT. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [jira] [Comment Edited] (PHOENIX-1118) Provide a tool for visualizing Phoenix tracing information