Re: Handling of HBase version specifics.

I think this is generally a good idea for managing multiple target runtimes. One question I have though: is it really necessary that we support so many release branches and so many compile targets? What about the versions of Hadoop underneath each of those versions of HBase? Are we committed to

Re: Error using VARBINARY in Index

of where the index data edits are created in code? I spent some time looking around but it’s not obvious to me. I’m looking at the 4.14.1-hbase-1.4 tag. Thanks, Nick On Mon, May 13, 2019 at 3:49 PM Nick Dimiduk wrote: > Hi Pedro, > > Indeed, some restrictions do apply :) >

Re: About mapping a phoenix table

IGTABLE_PHOENIX’* > > 5) Send data. In my test case I used psql to send 2 million records from > CSV to the phoenix source table > > *phoenix-psql.py -t BIGTABLE_PHOENIX localhost:2181 wine_mag.csv * > > > 6) You can now see the same data in the source and target cluster >

Re: About mapping a phoenix table

Hi Reid, I'll throw my +1 onto Anil's Approach #1. I followed this path recently to migrate all of our production data. Migrating Phoenix metadata by creating tables manually on the destination is a little clunky, but HBase Snapshots are quite easy to work with. Good luck, Nick On Tue, Apr 2,

Re: [DISCUSS] Suggestions for Phoenix from HBaseCon Asia notes

On Mon, Aug 27, 2018 at 2:03 PM, Thomas D'Silva wrote: > > > > > > 2. Can Phoenix be the de-facto schema for SQL on HBase? > > > > We've long asserted "if you have to ask how Phoenix serializes data, you > > shouldn't be do it" (a nod that you have to write lots of code). What if > we > > turn

Re: [DISCUSS] Design for a "query log"

I'm a big fan of this idea. There was a brief discussion on the topic over on PHOENIX-2715. My first concern is that the collected information is huge -- easily far larger than the user data for a busy cluster. For instance, a couple 10's of GB stored user data, guideposts set to default 100mb,

Re: [DISCUSS] 5.0.0-beta release before month's end?

Isn't Tephra integration mandatory for transaction support? What happens to a user who has TRANSACTIONAL=true tables when they upgrade? This can't really fail gracefully. I guess transaction support is still marked 'beta', but still, this would be a regression of functionality in "base Phoenix".

[jira] [Commented] (PHOENIX-4449) Incorrect behavior of sqlline after PHOENIX-3567

[ https://issues.apache.org/jira/browse/PHOENIX-4449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16286903#comment-16286903 ] Nick Dimiduk commented on PHOENIX-4449: --- bq. If we add some indirection around our Python scripts

Re: Query execution failed

First confirm a simple query is working, select * limit 1. If you're getting data back, it means your installation is (probably, mostly) correct. After that, take a long look at the explain plan of your desired query. If you've got any data at all and a full table scan, you can easily exceed the

Re: [DISCUSS] discontinue HBase 1.1 based Phoenix releases

For what it's worth, HBase community is pretty close to EOL on HBase 1.1. Probably 1.1.13 or 1.1.14 will be the last release (though I'm still not sure that DISCUSS thread has reached a conclusion). On Wed, Oct 11, 2017 at 2:54 PM Josh Elser wrote: > I'm still mulling this

Re: Phoenix code quality

Lars, This is a great list of guidelines. We should publish it on the contributing [0] section of the public site. -n [0]: http://phoenix.apache.org/contributing.html On Fri, Sep 22, 2017 at 4:12 PM lars hofhansl wrote: > Any comments?Is this simply not a concern? > -- Lars

Re: Reading the row key with HBase Client API

Phoenix has it's own type encodings for each data type. For best compatibility, I suggest you either use UNSIGNED_XXX [0], which are guaranteed to serialize with Bytes.toBytes(), or to use the serialization methods of PDataType types that ship in phoenix-core. [0]:

[jira] [Commented] (PHOENIX-3697) Tests failing on master and 4.x-HBase-1.1 HBASE-17587

[ https://issues.apache.org/jira/browse/PHOENIX-3697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15887407#comment-15887407 ] Nick Dimiduk commented on PHOENIX-3697: --- 1.1.9 votes passed. I've closed the repo, so it should

[jira] [Commented] (PHOENIX-3567) Use argparse in sqlline.py

[ https://issues.apache.org/jira/browse/PHOENIX-3567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15824365#comment-15824365 ] Nick Dimiduk commented on PHOENIX-3567: --- +1 > Use argparse in sqlline

Re: Phoenix Array

Hi Davide, I'm glad Phoenix is working well for you. Can you be more specific with your question? What kind of limitations are you concerned about? Have you seen the ARRAY Type documentation? It outlines some limitations at the bottom on the page. http://phoenix.apache.org/array_type.html -n

[jira] [Commented] (PHOENIX-3517) Use argparse in sqlline-thin.py

[ https://issues.apache.org/jira/browse/PHOENIX-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15746719#comment-15746719 ] Nick Dimiduk commented on PHOENIX-3517: --- bq. Would somethign like virtualenv be a tool to use here

Re: HBase RpcServerInterface changes from HBASE-16033

Okay thanks James! On Mon, Dec 12, 2016 at 4:33 PM, James Taylor <jamestay...@apache.org> wrote: > Hey Nick, > Adding new methods won't cause a problem, but thanks for asking. > > James > > On Sat, Dec 10, 2016 at 5:43 PM, Nick Dimiduk <ndimi...@ap

[jira] [Commented] (PHOENIX-3517) Use argparse in sqlline-thin.py

[ https://issues.apache.org/jira/browse/PHOENIX-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15744347#comment-15744347 ] Nick Dimiduk commented on PHOENIX-3517: --- Yeah looks like an improvement to me, +1. While you're

HBase RpcServerInterface changes from HBASE-16033

Heya, In reviewing changes for the next HBase 1.1 release, I noticed that HBASE-16033 introduces a new method to o.a.h.h.ipc.RpcServerInterface. This class is marked as LimitedPrivate(Phoenix). I'm not seeing any references to that class name in the Phoenix code on any of the 1.1 branches, but I

Re: Coprocessor metrics

IIRC, the plan is to get off of Hadoop Metrics2, so I am in favor of either (2) or (3). Specifically for (3), I believe there is an implementation for translating Dropwizard Metrics to Hadoop Metrics2, in or around Avatica and/or Phoenix Query Server. On Fri, Nov 11, 2016 at 3:15 PM, Enis

Re: [ANNOUNCE] New Apache Phoenix committer - Kevin Liew

Congrats Kevin! Thanks for all the contributions!! On Thursday, November 10, 2016, James Taylor wrote: > On behalf of the Apache Phoenix PMC, I'm pleased to announce that Kevin > Liew has accepted our invitation to become a committer on the Apache > Phoenix project. He's

[jira] [Created] (PHOENIX-3325) optimize lhs = ANY(...) as lhs in (...)

Nick Dimiduk created PHOENIX-3325: - Summary: optimize lhs = ANY(...) as lhs in (...) Key: PHOENIX-3325 URL: https://issues.apache.org/jira/browse/PHOENIX-3325 Project: Phoenix Issue Type

[jira] [Commented] (PHOENIX-3305) Parser doesn't accept UNION ALL with LIMIT

[ https://issues.apache.org/jira/browse/PHOENIX-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15511061#comment-15511061 ] Nick Dimiduk commented on PHOENIX-3305: --- Yes, the nested subselect achieves my desired results

[jira] [Commented] (PHOENIX-3305) Parser doesn't accept UNION ALL with LIMIT

[ https://issues.apache.org/jira/browse/PHOENIX-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510565#comment-15510565 ] Nick Dimiduk commented on PHOENIX-3305: --- Yep, precisely what I have in the description. Thanks

[jira] [Commented] (PHOENIX-3305) Parser doesn't accept UNION ALL with LIMIT

[ https://issues.apache.org/jira/browse/PHOENIX-3305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15510497#comment-15510497 ] Nick Dimiduk commented on PHOENIX-3305: --- Yes, this is what I've observed; not the behavior

[jira] [Created] (PHOENIX-3305) Parser doesn't accept UNION ALL with LIMIT

Nick Dimiduk created PHOENIX-3305: - Summary: Parser doesn't accept UNION ALL with LIMIT Key: PHOENIX-3305 URL: https://issues.apache.org/jira/browse/PHOENIX-3305 Project: Phoenix Issue Type

Re: I want to provide a module that provides the unshaded version of the jdbc client.

still -- file a JIRA? On Thu, Sep 15, 2016 at 11:45 AM, Marco Villalobos < mvillalo...@kineteque.com> wrote: > Not all of its dependencies are repackaged though, which leads to > class loading conflicts. When is that ever a good thing? > > On Thu, Sep 15, 2016 at 9:28 AM, N

Re: I want to provide a module that provides the unshaded version of the jdbc client.

Maybe I'm missing something, but... The whole point of providing a shaded client jar is to prevent exposing Phoenix implementation details to the applications that consume it -- effectively allowing people to manage their own dependencies. Using a shaded client jar means you don't have to worry

[jira] [Updated] (PHOENIX-3197) DATE/TIMESTAMP comparison involving rowkey column broken

[ https://issues.apache.org/jira/browse/PHOENIX-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated PHOENIX-3197: -- Attachment: test2.sql test1.sql Test files to run with psql.py > D

[jira] [Created] (PHOENIX-3197) DATE/TIMESTAMP comparison involving rowkey column broken

Nick Dimiduk created PHOENIX-3197: - Summary: DATE/TIMESTAMP comparison involving rowkey column broken Key: PHOENIX-3197 URL: https://issues.apache.org/jira/browse/PHOENIX-3197 Project: Phoenix

Re: [ANNOUNCE] Josh Elser joins Phoenix PMC

Congratulations Josh! Thanks for keeping us sorted :) On Wednesday, August 10, 2016, James Taylor wrote: > On behalf of the Apache Phoenix PMC, I'm pleased to announce that Josh > Elser has accepted our invitation to become a member of the Apache Phoenix > PMC. Recently

Re: [VOTE] Release of Apache Phoenix 4.8.0 RC2

Nope, just the one. It's the default base dir for all the rest. On Sunday, August 7, 2016, James Taylor <jamestay...@apache.org> wrote: > Thanks for the tip, Nick. I'll try that next time. Do you still override > the properties I mentioned? > > On Sunday, August 7, 2016, N

Re: [VOTE] Release of Apache Phoenix 4.8.0 RC2

For local mode on a Mac, I usually override hbase.tmp.dir to the absolute path of the unpacked tarball. Works for all versions of HBase I've used in recent memory. http://www.n10k.com/blog/hbase-root-dir/ On Sunday, August 7, 2016, James Taylor wrote: > +1. Thanks for

[jira] [Commented] (PHOENIX-3021) Using local index during compaction is producing NPE

[ https://issues.apache.org/jira/browse/PHOENIX-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15375775#comment-15375775 ] Nick Dimiduk commented on PHOENIX-3021: --- Is this issue isolated to the 4.8 branch or does

Re: [DISCUSS] RM for next release

heads and maintenance/release > > > branches both. Cut releases from the maintenance branches monthly. > > Simple. > > > When the time comes, just do it. Meanwhile as the bigger things fully > > bake > > > do a new minor or even major rev to release them. Bug fix

Re: [DISCUSS] RM for next release

ider > the HBase "branch RM" style management for that? > > > On Tue, Jul 5, 2016 at 9:53 AM, Nick Dimiduk <ndimi...@apache.org> wrote: > > > Is this thread to discuss Lars for RM, for moving to a monthly release > > cadence, or propose specific JIRAs

Re: [DISCUSS] RM for next release

Is this thread to discuss Lars for RM, for moving to a monthly release cadence, or propose specific JIRAs for the next release? One the above: +1 for Lars, he knows how to make releases happen :) Is this monthly cadence for patch releases? So far this community hasn't seen fit to make patch

[jira] [Created] (PHOENIX-3026) sqlline-thin.py doesn't honor jdbc properties in url

Nick Dimiduk created PHOENIX-3026: - Summary: sqlline-thin.py doesn't honor jdbc properties in url Key: PHOENIX-3026 URL: https://issues.apache.org/jira/browse/PHOENIX-3026 Project: Phoenix

Re: Regarding PHOENIX-1734

On Sun, Jun 12, 2016 at 4:33 PM, James Taylor wrote: > Users not relying on local indexes can upgrade the server ahead of the > client, but users depending on local indexes will need to upgrade the > client and server together. The problem with bumping up the major

[jira] [Commented] (PHOENIX-2732) Update HBase versions in pom

[ https://issues.apache.org/jira/browse/PHOENIX-2732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335405#comment-15335405 ] Nick Dimiduk commented on PHOENIX-2732: --- Hey fellas -- was this change made in order to access

[jira] [Commented] (PHOENIX-2914) Make sqlline refer to bin/hbase-site.xml by default

[ https://issues.apache.org/jira/browse/PHOENIX-2914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335401#comment-15335401 ] Nick Dimiduk commented on PHOENIX-2914: --- Seems like this patch means we not longer require

[jira] [Commented] (PHOENIX-2891) Support system-wide UDFs

[ https://issues.apache.org/jira/browse/PHOENIX-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15334078#comment-15334078 ] Nick Dimiduk commented on PHOENIX-2891: --- bq. Similar to HBase "system coprocessors"

[jira] [Created] (PHOENIX-2997) Spark Integration tests not managed through failsafe plugin

Nick Dimiduk created PHOENIX-2997: - Summary: Spark Integration tests not managed through failsafe plugin Key: PHOENIX-2997 URL: https://issues.apache.org/jira/browse/PHOENIX-2997 Project: Phoenix

[jira] [Commented] (PHOENIX-2940) Remove STATS RPCs from rowlock

[ https://issues.apache.org/jira/browse/PHOENIX-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312558#comment-15312558 ] Nick Dimiduk commented on PHOENIX-2940: --- bq. we don't use stats on the server-side, only

Re: Are we ready for 4.8.0 RC?

gt;> James >> >> On Tue, May 31, 2016 at 1:48 PM, Nick Dimiduk<ndimi...@gmail.com> wrote: >> >> We're hoping to get the shaded client jars [0] and rename of queryserver >>> jar [1] changes in for 4.8. There's also an optimization improvement for >

Re: Are we ready for 4.8.0 RC?

We're hoping to get the shaded client jars [0] and rename of queryserver jar [1] changes in for 4.8. There's also an optimization improvement for using skip scan that's close [2]. [0]: https://issues.apache.org/jira/browse/PHOENIX-2535 [1]: https://issues.apache.org/jira/browse/PHOENIX-2267 [2]:

[jira] [Commented] (PHOENIX-2267) Disambiguate server jar from phoenix-server module jar

[ https://issues.apache.org/jira/browse/PHOENIX-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15308084#comment-15308084 ] Nick Dimiduk commented on PHOENIX-2267: --- I assume you meant PHOENIX-2535. Yes hoping so; I want

[jira] [Commented] (PHOENIX-2267) Disambiguate server jar from phoenix-server module jar

[ https://issues.apache.org/jira/browse/PHOENIX-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307938#comment-15307938 ] Nick Dimiduk commented on PHOENIX-2267: --- I see. Patch v6 on 2535 does the work of this one as well

[jira] [Commented] (PHOENIX-2267) Disambiguate server jar from phoenix-server module jar

[ https://issues.apache.org/jira/browse/PHOENIX-2267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15307935#comment-15307935 ] Nick Dimiduk commented on PHOENIX-2267: --- bq. Thanks for PHOENIX-2535. Can we close this as a dup

[jira] [Commented] (PHOENIX-2940) Remove STATS RPCs from rowlock

[ https://issues.apache.org/jira/browse/PHOENIX-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302923#comment-15302923 ] Nick Dimiduk commented on PHOENIX-2940: --- Thanks for picking this one up [~elserj]. I like where

[jira] [Updated] (PHOENIX-2940) Remove STATS RPCs from rowlock

[ https://issues.apache.org/jira/browse/PHOENIX-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated PHOENIX-2940: -- Description: We have an unfortunate situation wherein we potentially execute many RPCs while

[jira] [Updated] (PHOENIX-2940) Remove STATS RPCs from rowlock

[ https://issues.apache.org/jira/browse/PHOENIX-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated PHOENIX-2940: -- Summary: Remove STATS RPCs from rowlock (was: Remove CATALOG,STATS RPCs from rowlock

[jira] [Created] (PHOENIX-2941) Alternative means of propagating schema changes

Nick Dimiduk created PHOENIX-2941: - Summary: Alternative means of propagating schema changes Key: PHOENIX-2941 URL: https://issues.apache.org/jira/browse/PHOENIX-2941 Project: Phoenix Issue

[jira] [Created] (PHOENIX-2940) Remove CATALOG,STATS RPCs from rowlock

Nick Dimiduk created PHOENIX-2940: - Summary: Remove CATALOG,STATS RPCs from rowlock Key: PHOENIX-2940 URL: https://issues.apache.org/jira/browse/PHOENIX-2940 Project: Phoenix Issue Type

[jira] [Commented] (PHOENIX-2939) MetaCache is easily thrashed with default settings

[ https://issues.apache.org/jira/browse/PHOENIX-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15301255#comment-15301255 ] Nick Dimiduk commented on PHOENIX-2939: --- If we want to continue the practice of caching the entire

[jira] [Created] (PHOENIX-2939) MetaCache is easily thrashed with default settings

Nick Dimiduk created PHOENIX-2939: - Summary: MetaCache is easily thrashed with default settings Key: PHOENIX-2939 URL: https://issues.apache.org/jira/browse/PHOENIX-2939 Project: Phoenix

[jira] [Commented] (PHOENIX-258) Use skip scan when SELECT DISTINCT on leading row key column(s)

[ https://issues.apache.org/jira/browse/PHOENIX-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15301119#comment-15301119 ] Nick Dimiduk commented on PHOENIX-258: -- In my particular case, itemizing the leading column also

[jira] [Updated] (PHOENIX-258) Use skip scan when SELECT DISTINCT on leading row key column(s)

[ https://issues.apache.org/jira/browse/PHOENIX-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated PHOENIX-258: - Attachment: in-clause.png Yes indeed. Here's a rudimentary test result -- my leading column has

Re: Hudson build failure for PHOENIX-2809

Apache Jenkins login is quite restricted -- many project committers do not have accounts. Pre-commit builds are triggered by attaching patch files to a Jira and putting it into 'patch available' status. You can re-attach your patch to trigger a new build. On Thursday, May 19, 2016, William

[DISCUSS] Appetite for a 4.7.1

Hi folks, I'd like to bring PHOENIX-2887 to your attention. It means that Phoenix cannot be used from Yarn applications in a number of scenarios (see history around the related HBASE-8), and is bad enough that I think it's reasonable justification for a patch release. We haven't done a lot of

[jira] [Commented] (PHOENIX-2887) Uberjar application fail with "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.LiteralByteStr

[ https://issues.apache.org/jira/browse/PHOENIX-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15282918#comment-15282918 ] Nick Dimiduk commented on PHOENIX-2887: --- I've confirmed this patch resolves the issue. Thanks

[jira] [Commented] (PHOENIX-2887) Uberjar application fail with "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.LiteralByteStr

[ https://issues.apache.org/jira/browse/PHOENIX-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15281649#comment-15281649 ] Nick Dimiduk commented on PHOENIX-2887: --- Thanks a lot for the quick patch, I'll take it for a spin

Re: Phoenix Tracing Web App Problem

Is there anything in /tmp/phoenix/phoenix-pranavan-traceserver.log ? On Wed, May 11, 2016 at 5:00 AM, Pranavan Theivendiram < pranavan...@cse.mrt.ac.lk> wrote: > Hi Devs, > > I have started the tracing web app. It is starting like > > starting Trace Server, logging to >

[jira] [Created] (PHOENIX-2891) Support system-wide UDFs

Nick Dimiduk created PHOENIX-2891: - Summary: Support system-wide UDFs Key: PHOENIX-2891 URL: https://issues.apache.org/jira/browse/PHOENIX-2891 Project: Phoenix Issue Type: Improvement

[jira] [Updated] (PHOENIX-2887) Uberjar application fail with "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.LiteralByteStrin

[ https://issues.apache.org/jira/browse/PHOENIX-2887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated PHOENIX-2887: -- Description: Uberjar applications operating over Phoenix 4.7.0 are expressing the same

[jira] [Created] (PHOENIX-2887) Uberjar application fail with "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.LiteralByteStrin

Nick Dimiduk created PHOENIX-2887: - Summary: Uberjar application fail with "IllegalAccessError: class com.google.protobuf.ZeroCopyLiteralByteString cannot access its superclass com.google.protobuf.LiteralByteString" Ke

[jira] [Commented] (PHOENIX-2508) Phoenix Connections Stopped Working

[ https://issues.apache.org/jira/browse/PHOENIX-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274590#comment-15274590 ] Nick Dimiduk commented on PHOENIX-2508: --- I believe I'm experiencing the same bug, as per

[jira] [Commented] (PHOENIX-2508) Phoenix Connections Stopped Working

[ https://issues.apache.org/jira/browse/PHOENIX-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15274589#comment-15274589 ] Nick Dimiduk commented on PHOENIX-2508: --- Hi [~gcagrici], what workload are you running when

[jira] [Updated] (PHOENIX-2845) Timestamp ignores nanos in literal expressions

[ https://issues.apache.org/jira/browse/PHOENIX-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk updated PHOENIX-2845: -- Attachment: PHOENIX-2845-3.patch Reattaching patch for buildbot. > Timestamp ignores na

[jira] [Assigned] (PHOENIX-2845) Timestamp ignores nanos in literal expressions

[ https://issues.apache.org/jira/browse/PHOENIX-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Dimiduk reassigned PHOENIX-2845: - Assignee: Nick Dimiduk (was: Sergey Soldatov) > Timestamp ignores nanos in lite

Re: [ANNOUNCE] Ankit Singhal joins Phoenix PMC

Nice work Ankit, congrats! On Tuesday, May 3, 2016, James Taylor wrote: > On behalf of the Apache Phoenix PMC, I'm pleased to announce that Ankit > Singhal has accepted our invitation to become a member of the Apache > Phoenix project management committee (PMC). Recently

[jira] [Commented] (PHOENIX-2784) phoenix-spark: Allow coercion of DATE fields to TIMESTAMP when loading DataFrames

[ https://issues.apache.org/jira/browse/PHOENIX-2784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15265928#comment-15265928 ] Nick Dimiduk commented on PHOENIX-2784: --- I'm not following the intended use-case here. Date, Time

[jira] [Commented] (PHOENIX-2845) Timestamp ignores nanos in literal expressions

[ https://issues.apache.org/jira/browse/PHOENIX-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15265924#comment-15265924 ] Nick Dimiduk commented on PHOENIX-2845: --- Your changes look right to me [~sergey.soldatov

Re: Jenkins build failures?

The default thread pool sizes for HDFS, HBase, ZK, and the Phoenix client are all contributing to this huge thread count. A good starting point would be to take a jstack of the IT process and count, group by threads with similar name. Reconfigure to reduce all those groups to something like 10

Re: [Dev] Apache Phoenix installation

Same as on our getting started page on the website, you'll need a compatible version of HBase. The main difference is that with a local build, your build output is in 'target' directories. Check the phoenix-assembly module for the jars. On Friday, April 29, 2016, Pranavan Theivendiram

[jira] [Created] (PHOENIX-2859) RPC Heartbeats for aggregation coprocessors

Nick Dimiduk created PHOENIX-2859: - Summary: RPC Heartbeats for aggregation coprocessors Key: PHOENIX-2859 URL: https://issues.apache.org/jira/browse/PHOENIX-2859 Project: Phoenix Issue Type

[jira] [Commented] (PHOENIX-2640) Make it possible to kill running queries (and ideally list them too)

[ https://issues.apache.org/jira/browse/PHOENIX-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15256591#comment-15256591 ] Nick Dimiduk commented on PHOENIX-2640: --- bq. It would be good to implement statement.cancel() +1

[jira] [Commented] (PHOENIX-2843) Phoenix-site does not build with JDK-8

[ https://issues.apache.org/jira/browse/PHOENIX-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15250182#comment-15250182 ] Nick Dimiduk commented on PHOENIX-2843: --- +1. What's org.h2? Should this be pushed upstream

Re: Site broken

or: Could not find or load main class org.h2.build.Build >>> >>> Enis >>> >>> On Tue, Apr 19, 2016 at 1:36 PM, Enis Söztutar <e...@apache.org> wrote: >>> >>>> I think it is me. Let me check. >>>> >>>> I had update

Re: Site broken

Sending to the correct dev list. http://phoenix.apache.org/language/index.html http://phoenix.apache.org/language/functions.html http://phoenix.apache.org/language/datatypes.html On Tue, Apr 19, 2016 at 1:00 PM, Nick Dimiduk <ndimi...@apache.org> wrote: > Hey guys, > > Looks lik

Re: Timestamp with nanos.

Can you not use syntax like TIMESTAMP '2016-01-01 00:00:00.123456789' for the sql value? On Wed, Apr 13, 2016 at 4:15 PM, Sergey Soldatov wrote: > Guys, > Is there a way to set nanos for Timestamp from sql statement? The only > way to set nanos I see at the moment is

[jira] [Commented] (PHOENIX-1395) ResultSpooler spill files are left behind in /tmp folder

[ https://issues.apache.org/jira/browse/PHOENIX-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240189#comment-15240189 ] Nick Dimiduk commented on PHOENIX-1395: --- Yes, these files are in /tmp on the client machine

[jira] [Commented] (PHOENIX-1395) ResultSpooler spill files are left behind in /tmp folder

[ https://issues.apache.org/jira/browse/PHOENIX-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240160#comment-15240160 ] Nick Dimiduk commented on PHOENIX-1395: --- Maybe a better solution is to advise in our docs

[jira] [Commented] (PHOENIX-1395) ResultSpooler spill files are left behind in /tmp folder

[ https://issues.apache.org/jira/browse/PHOENIX-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240149#comment-15240149 ] Nick Dimiduk commented on PHOENIX-1395: --- Hey guys I'm still seeing this on 4.6. > ResultSpoo

Re: [ANNOUNCE] New Apache Phoenix committer - Josh Elser

Nice work! The Josh maffia is growing. On Friday, April 8, 2016, rajeshb...@apache.org wrote: > Congratulations Josh!! > > On Sat, Apr 9, 2016 at 12:17 AM, Ankit Singhal > > wrote: > > > Congrats Josh!! > > > > On Fri, Apr 8,

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[ https://issues.apache.org/jira/browse/PHOENIX-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15233020#comment-15233020 ] Nick Dimiduk commented on PHOENIX-2535: --- bq. 4.8 RM should especially check whether the publish

[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)

[ https://issues.apache.org/jira/browse/PHOENIX-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15232444#comment-15232444 ] Nick Dimiduk commented on PHOENIX-2535: --- bq. +1 to rename query server jar yeah, this should have

[jira] [Commented] (PHOENIX-2757) Phoenix Can't Coerce String to Boolean

[ https://issues.apache.org/jira/browse/PHOENIX-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15189696#comment-15189696 ] Nick Dimiduk commented on PHOENIX-2757: --- The {{String}} row has an X in every column

[jira] [Commented] (PHOENIX-2757) Phoenix Can't Coerce String to Boolean

[ https://issues.apache.org/jira/browse/PHOENIX-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15188436#comment-15188436 ] Nick Dimiduk commented on PHOENIX-2757: --- Looks like Postgres handles it on the client

[jira] [Commented] (PHOENIX-2757) Phoenix Can't Coerce String to Boolean

[ https://issues.apache.org/jira/browse/PHOENIX-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15188432#comment-15188432 ] Nick Dimiduk commented on PHOENIX-2757: --- [~sergey.soldatov] placing the fix

[jira] [Created] (PHOENIX-2754) Add INTERVAL type

Nick Dimiduk created PHOENIX-2754: - Summary: Add INTERVAL type Key: PHOENIX-2754 URL: https://issues.apache.org/jira/browse/PHOENIX-2754 Project: Phoenix Issue Type: Improvement

Re: [DISCUSS] Drop branch for HBase-1.0?

In this case we're effectively forcing users to upgrade their HBase if they want to continue to receive Phoenix updates. That's probably fine? On Fri, Feb 26, 2016 at 3:15 PM, Enis Söztutar wrote: > Hi, > > In case you are not following hbase-dev closely, after HBase-1.0.3, we

Re: [VOTE] Release of Apache Phoenix 4.7.0-HBase-1.1 RC3

Sure, I can look into that. On Thu, Feb 25, 2016 at 4:09 PM, James Taylor <jamestay...@apache.org> wrote: > No, it's not staged in Maven, but that would be a welcome addition to our > release process (if you're volunteering :-) ). > > Thanks, > James > > On Thu, Fe

Re: [VOTE] Release of Apache Phoenix 4.7.0-HBase-1.1 RC3

Is there a staging maven repository for this release? There's no mention in this vote thread and I don't see anything on https://repository.apache.org/#stagingRepositories. Having a staging repo makes it a lot easier to test client applications. Thanks, -n On Thu, Feb 25, 2016 at 12:18 AM, James

[jira] [Commented] (PHOENIX-2702) Show estimate rows and bytes touched in explain plan.

[ https://issues.apache.org/jira/browse/PHOENIX-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167666#comment-15167666 ] Nick Dimiduk commented on PHOENIX-2702: --- bq. Can we get at the on-disk size of a KeyValue? Best

[jira] [Commented] (PHOENIX-2702) Show estimate rows and bytes touched in explain plan.

[ https://issues.apache.org/jira/browse/PHOENIX-2702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15167646#comment-15167646 ] Nick Dimiduk commented on PHOENIX-2702: --- This may be misleading information. Comparing the output

[jira] [Created] (PHOENIX-2715) Query Log

Nick Dimiduk created PHOENIX-2715: - Summary: Query Log Key: PHOENIX-2715 URL: https://issues.apache.org/jira/browse/PHOENIX-2715 Project: Phoenix Issue Type: New Feature Reporter

[jira] [Commented] (PHOENIX-2646) Extend VARCHAR matching with ~ regex syntax

[ https://issues.apache.org/jira/browse/PHOENIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159495#comment-15159495 ] Nick Dimiduk commented on PHOENIX-2646: --- Looks like I can use {{ARRAY_TO_STRING}} and tweak

[jira] [Commented] (PHOENIX-2646) Extend VARCHAR matching with ~ regex syntax

[ https://issues.apache.org/jira/browse/PHOENIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159449#comment-15159449 ] Nick Dimiduk commented on PHOENIX-2646: --- Seems we don't have UNNEST either. > Extend VARC

[jira] [Commented] (PHOENIX-2646) Extend VARCHAR matching with ~ regex syntax

[ https://issues.apache.org/jira/browse/PHOENIX-2646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15159281#comment-15159281 ] Nick Dimiduk commented on PHOENIX-2646: --- http://phoenix.apache.org/language/functions.html#any

  1   2   3   4   5   6   7   >