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, 2016 at 10:29 PM, Marek Wiewiorka <
> > marek.wiewio...@gmail.com >
>
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 to use PrepareStatement
> to
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 wrote:
> Hey guys,
>
> Looks like the last site upda
gt;>>
>>> method ArrayList.replaceAll(UnaryOperator) is not applicable
>>>
>>> (actual and formal argument lists differ in length)
>>>
>>> 1 error
>>>
>>> Error: Could not find or load main class org.h2.build.Build
>
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
wrote:
> H
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 eac
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 he's implemented two
> o
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
> /tmp/phoenix/phoenix-pran
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
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 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
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]: h
James
>>
>> On Tue, May 31, 2016 at 1:48 PM, Nick Dimiduk 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
>>> using skip scan t
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 version
> is that existing user
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 relea
anch RM" style management for that?
>
>
> On Tue, Jul 5, 2016 at 9:53 AM, Nick Dimiduk wrote:
>
> > 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:
> >
> >
leases 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 fixes will not
> have
> > > been held up no matter how long
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 the quick turnaround on th
Nope, just the one. It's the default base dir for all the rest.
On Sunday, August 7, 2016, James Taylor 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, Nick Dimiduk >
> wr
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 he found and fixed licens
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 over, but my first rea
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
d
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".
O
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, en
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 th
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, 20
LICATION_SCOPE=>’1’}*
>
> *enable ‘BIGTABLE_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 sam
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 :)
>
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
ru
It's TPC-DS, not -H, but this is what I was using way back when to run perf
tests over Phoenix and the query server while I was developing on it. The
first project generates, loads the data via mapreduce and the second tool
wraps up use of jmeter to run queries in parallel.
https://github.com/ndim
I'm +1 on both points. I don't know that 1.3 will be available in time
though...
On Saturday, August 20, 2016, wrote:
> The HBase 1.0.x branch has been EOL'd, I propose we drop support for it
> with Phoenix 4.9.I'd also propose that should HBase have a stable 1.3.x
> release soon, we should supp
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 ab
-- better 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
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 done an great job findin
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 Söztutar
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
w
Okay thanks James!
On Mon, Dec 12, 2016 at 4:33 PM, James Taylor
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 wrote:
>
> > Heya,
> >
> > In revi
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
On
ulate ParameterMetaData
accordingly.
On Tue, Mar 31, 2015 at 1:06 PM, Nick Dimiduk wrote:
> Hi Gabriel,
>
> Yes, we do this in the Phoenix test harness for parameterizing split
> points. See o.a.p.q.BaseTest#createTestTable(String, String, byte[][],
> Long, boolean). I ran into this whil
Adding back dev@calcite
On Wed, Apr 1, 2015 at 11:48 AM, Nick Dimiduk wrote:
> Poking around with HSQLDB, it seems parameter metadata is made available
> after statement preparation for select statements. (Presumably inferred
> from column type, as in "SELECT * FROM TEST_TABLE WHE
c. If Phoenix can't figure
> it out, we use null for the type in the metadata APIs.
>
> On Wed, Apr 1, 2015 at 11:49 AM, Nick Dimiduk wrote:
> > Adding back dev@calcite
> >
> > On Wed, Apr 1, 2015 at 11:48 AM, Nick Dimiduk
> wrote:
> >
> >>
Heya,
In bin/phoenix_utils.py, the global variable hbase_conf_path is defined.
This variable is referenced from sqlline.py and is added to the class path,
presumably used to resolve hbase-site.xml. The env variable it's checking
is HBASE_CONF_PATH. This is *different* from the standard BigTop inst
FYI, HTrace is now Apache HTrace [0] and has come a long way in terms of
visualizations. The 3.2 release (next month, I hope) will include many
improvements.
[0]: http://htrace.incubator.apache.org
On Wed, Apr 15, 2015 at 12:43 AM, Ayola Jayamaha
wrote:
> Hi,
>
> I looked at HTrace [1]. Then I
Quick question:
Why do we package up our dependencies in the TGZ? There's no Phoenix
executable, just a fat jar for the RS and a fat client jar for
applications. Why bother with lib and all this business?
If we are trying to package up all our dependencies in the tgz, our current
means are inadeq
> > Jesse I think you initially worked on Phoenix assembly tar and jar
> > packaging. Any thoughts?
> >
> > On Fri, Apr 17, 2015 at 12:39 PM, Nick Dimiduk
> wrote:
> >
> >> Quick question:
> >>
> >> Why do we package up our dependencies
n Sat, Apr 18, 2015 at 12:36 PM, Jesse Yates
wrote:
> Sounds like we can rip it out then - did you already file a jira?
>
> On Fri, Apr 17, 2015, 3:06 PM Nick Dimiduk wrote:
>
> > My understanding is that we already run via standalone uberjar for
> > sqlline.py and psql.
te:
> Not building a tgz will mess up Bigtop packaging, please don't rip it out
> if it's not critical.
>
>
> On Sat, Apr 18, 2015 at 2:20 PM, Nick Dimiduk wrote:
>
> > Nothing filed; just asking for my own enlightenment. Let me see about
> > putting our tgz
Hi folks,
Looks like a merge commit was recently pushed to master. I think we have
the project policy to not merge changes, but rather rebase any local
changes onto an update from upstream.
The easiest way to avoid merge commits is to not use `git pull` but instead
use `get fetch` followed by `re
Devs --
We now have a pre-commit BuildBot [0]! Our pedantic build-checking robot
servant passed its first judgement [1] this afternoon. It is a clone [2] of
the buildbot from HBase, so it's somber tone should be familiar to many of
you. Same rules apply -- attach your patch, hit "Submit Patch" and
wesome Nick!
> >>
> >> On Thu, Apr 23, 2015 at 4:30 PM, Eli Levine
> wrote:
> >>
> >> > Great work, Nick! Thanks for doing this.
> >> >
> >> > Eli
> >> >
> >> > On Thu, Apr 23, 2015 at 4:01 PM, Nick Dimiduk
>
h?
Thanks,
Nick
On Fri, Apr 24, 2015 at 3:59 PM, Andrew Purtell wrote:
> +1
>
> On Wed, Apr 22, 2015 at 3:29 PM, Nick Dimiduk wrote:
>
> > Hi folks,
> >
> > Looks like a merge commit was recently pushed to master. I think we have
> > the project policy to
Hi folks,
I've pushed a couple commits that clean up the ASL headers in our code.
That means the pre-commit bot's "release audit warnings" section is now
correct and talking about *your patch*. PMC are required to validate these
headers on releases, but I see no reason for us to not verify this mo
ne :). I did do a fetch
> and rebase before applying my patch. What got me was commits happened
> before I could commit. Then I did a pull without realizing that would
> merge. Sorry about that.
>
> ~Cody
>
> On Fri, Apr 24, 2015 at 5:02 PM, Nick Dimiduk > wrote:
>
>
> Thanks,
> Rajeshbabu.
>
> On Fri, Apr 24, 2015 at 9:18 AM, Nick Dimiduk wrote:
>
> > On Thu, Apr 23, 2015 at 7:19 PM, James Taylor
> > wrote:
> >
> > > Excellent, Nick. For us non HBasers, what's the recommended workflow?
> > >
> >
FYI, HBase 1.1.0 is imminent. I will push another snapshot jar today that's
very close, and hope to have rc0 up Wednesday (tomorrow).
On Mon, Apr 27, 2015 at 12:20 PM, James Taylor
wrote:
> Do you agree we need to create a 4.x-HBase-1.0 branch now? If not,
> what branch will be used to check-in
On Wed, Apr 29, 2015 at 11:08 AM, Stack wrote:
> Any chance of our hurrying up this process and shipping a Phoenix that
> works on hbase 1.x?
>
Would be great to have a Phoenix working on HBase 1.x for HBaseCon :)
On Tue, Apr 28, 2015 at 9:42 PM, rajeshb...@apache.org <
> chrajeshbab...@gmail.c
Hi Sergey,
Nice find. I left a comment over on PHOENIX-1904. From my point of view,
this is a bug raised by your custom packaging and not bad enough to sink
the RC -- i.e., the RC should still work "out of the box". Should
definitely file a ticket to make the launch scripts more robust in the
futu
r out of box folder structure for phoenix 4.4 client
> with sqlline ?
>
> we also switched to HDP 2.2 distribution if that make any difference
> (hopefully not)
>
> thank you
> S
> On May 5, 2015 5:00 PM, "Nick Dimiduk" wrote:
>
> > Hi Sergey,
> >
my question was what would be proper (out of box) structure for the
> Phoenix client?
>
> in tar from what I remember it all jars together and than bin folder. I do
> not think it has lib folder unless assumption is that all jars dumped to
> hbase/lib
> On May 5, 2015 6:47 PM, &quo
he binary tarball is just for convenience actually. So I am not
> sure we need to sink the RC as long as bigtop packaging can take this
> tarball and create the binary tarball in the expected layout.
>
> Enis
>
> On Tue, May 5, 2015 at 4:23 PM, Nick Dimiduk wrote:
>
> > Yeah, I
maven assembly packaging. Whether this sinks the RC is an
> open
> > question. The binary tarball is just for convenience actually. So I am
> not
> > sure we need to sink the RC as long as bigtop packaging can take this
> > tarball and create the binary tarball in the expec
ether this sinks the RC is an
>>> open
>>> > question. The binary tarball is just for convenience actually. So I am
>>> not
>>> > sure we need to sink the RC as long as bigtop packaging can take this
>>> > tarball and create the binary tarball in th
Which RC build are you using (0.98 or 1.0)? Does your HBase deploy match
the Phoenix version? Can you compare the class path for the process (use
`ps aux | grep -i sqlline` or similar) to the actual jars on disk --
everything is there?
Thanks,
Nick
On Wed, May 6, 2015 at 2:42 AM, Biyuhao wrote:
> > On Fri, Apr 24, 2015 at 5:36 PM Nick Dimiduk wrote:
> >
> >> Hi folks,
> >>
> >> I've pushed a couple commits that clean up the ASL headers in our code.
> >> That means the pre-commit bot's "release audit warnings" section is n
Heya,
Giving the RC a spin, and also investigating the impact of HBASE-13604, I'm
having a spot of trouble with bulk load. I'm executing CsvBulkLoadToolIT
manually. Seems like date string parsing is not working, but I may well be
doing something wrong.
Thanks.
$ cat /tmp/input1.csv
1,Name 1,1970
Hi Rajesh.
Is there no maven repository staged for this RC?
Thanks,
Nick
On Mon, May 11, 2015 at 5:41 PM, rajeshb...@apache.org <
chrajeshbab...@gmail.com> wrote:
> Hi Everyone,
>
> This is a call for a vote on Apache Phoenix 4.4.0-HBase-1.0 RC1. This is
> the
> next minor release of Phoenix 4,
I think which version of gpg used is not important, so long as the
signatures are valid and can be consumed universally. Likewise with the
checksum calculations. I agree that standardizing on this for the project
would be helpful for all parties, but until we enforce generating release
artifacts in
I've already given my opinion on gpg versions, checksums formats, and the
delta between tag and packaging on the other thread.
For this release, +1:
- verified signing key for both tgzs
- run with 0.98.12 in local mode
- create table, load example data with psql, list tables and content
- start q
FYI, I filed a ticket to get some support on this.
https://issues.apache.org/jira/browse/INFRA-9663
On Sat, May 16, 2015 at 1:11 AM, James Taylor
> > wrote:
> >
> > > +1
> > >
> > > - verified basic installation and querying worked
> > > - verified creating mutable secondary indexes worked
> > > - verified various DDL calls worked
> > &
Thanks Rajesh. Have you checked JIRA for issues labeled 4.4.1? Probably
those need to be back ported to the new branches, if the branches were
created from the release tags.
On Thursday, May 21, 2015, rajeshb...@apache.org
wrote:
> I have created branches 4.4-HBase-0.98 branch off of the 4.x-HBa
This looks good except for (1) branch should be cut from the
4.4.0-HBase-1.0 tag. That way 4.4.0 will be feature-identical across all
releases. Then we'll need to go back over what's landed on 4.x-HBase-1.0
since 4.4.0 was released and bring forward any patches, so that all 3
branches are aligned f
enix-core/src/it/java/org/apache/phoenix/mapreduce/CsvBulkLoadToolIT.java#L99-L100
On Sat, May 16, 2015 at 9:14 AM, Gabriel Reid
wrote:
> Hi Nick,
>
> The date format is (if I'm not mistaken) ISO-8601, so I think you'll have
> to format your date values as 1970-01-01.
>
&g
oenix/mapreduce/CsvBulkLoadToolIT.java#L105
>
>
> On Tue, May 26, 2015 at 9:33 PM Nick Dimiduk wrote:
>
>> This is working for me as expected, thanks Gabriel. I find it odd that we
>> don't have an issue in our IT test though
>>
>> printWriter.println(&
Great questions. I think Ambari/HDP stacks support versioned packages,
which should allow multiple software versions to be installed concurrently.
I don't know if this is supported by other stack definitions.
Probably this is better answered on the Ambari lists, +user@ambari.
-n
On Monday, May 2
pecific deployed version. Could be possible with
namespaces and a connection concept similar to tenant ID.
On May 26, 2015 4:31 PM, "Nick Dimiduk" wrote:
>
> > Great questions. I think Ambari/HDP stacks support versioned packages,
> > which should allow multiple softwa
Performing the steps in your blog will populate a and query data, but I
didn't see any place where you enabled tracing for a request. Enabling
collection of trace spans via [2] is required. With that done, you also
need to execute queries with tracing initiated. To experiment, try
setting phoenix.t
We now have 7 (!!!) active branches. Is there a plan to deprecate any of
them in the near future -- will there be a 4.5-HBase-1.0 release, for
example? Perhaps it's worth re-evaluating the cost-benefit analysis of a
shim layer.
-n
+1 approve.
- verified signing key for both tgzs
- run with 1.1.0.1 and checkout of branch-1.1/a1043fb in local mode
- create table, load example data with psql, list tables and content
- start query server and perform similar experiments there; everything
works as expected and log levels look goo
Dropping the incubator list.
What Jesse said :)
This is off to a nice start Nishani! (Sorry, or is it Ayola?) What are you
thinking of for your next objective? Wiring up the backend to query the
life Phoenix table? More UI work? Keep at it and as always, let us know if
you're having troubles.
-n
Hi Siva,
I haven't tried this yet. Just a guess, but maybe rebuilding the stats
table after load will resolve this. Can you give it a try?
-n
On Thursday, June 4, 2015, Siva wrote:
> Hi Everyone,
>
> Facing strange issue in phoenix after bulk loading data in HBase. When we
> query count(*) on
I'd feel better if a check was done to verify they carry the same patches.
I'd also like this to be followed up with a discussion about fix versions
in JIRA and how they relate to git branches. For instance, we've had 5.0.0
for ages, but it seems even master will be 4.5.0-SNAPSHOT-HBase-1.1. Shoul
to drop the
> branch. Just let me know when you're ok with it.
>
> Thanks,
> James
>
> On Thu, Jun 18, 2015 at 11:45 AM, Nick Dimiduk wrote:
> > I'd feel better if a check was done to verify they carry the same
> patches.
> >
> > I'd also like this t
ith the 4.x-HBase-1.1 branch being dropped. It's getting
> > > further and further behind master and we can always re-create it from
> > > master if we need it down-the-road.
> > >
> > > On Thu, Jun 18, 2015 at 1:28 PM, Nick Dimiduk > > > wrote:
> >
Nice work, congratulations Josh, and welcome!
On Tue, Jun 23, 2015 at 9:40 AM, James Taylor
wrote:
> On behalf of the Apache Phoenix PMC, I'm pleased to announce that Josh
> Mahonin has accepted our invitation to become a committer on the
> Apache Phoenix project. He's been the force behind our
I'm happy to announce the first release candidate of HBase 1.1.1
(HBase-1.1.1RC0) is available for download at
https://dist.apache.org/repos/dist/dev/hbase/hbase-1.1.1RC0/
Maven artifacts are also available in the staging repository
https://repository.apache.org/content/repositories/orgapachehbase
I think the JIRA version also needs to be marked as released and the issues
marked "closed".
On Wed, Jun 24, 2015 at 12:28 PM, Thomas D'Silva
wrote:
> Rajeshbabu,
>
> I don't see the tags for the 4.4.0 release, I only see the rc tags :
>
> v4.4.0-HBase-0.98-rc0
> v4.4.0-HBase-0.98-rc1
> v4.4.0-H
Hello developers, users, speakers,
In honor of ApacheCON's inaugural "Apache: Big Data" event, I'm hoping to
see a "HBase: NoSQL + SQL" track come together. The idea is to showcase the
growing ecosystem of applications and tools built on top of and around
Apache HBase. To have a track, we need con
Just a reminder, there's roughly 6 hours left in the voting cycle.
Realistically a few more than that, as I won't observe results until
AM/Pacific time on Monday.
Thanks for your time and attention,
-n
On Tue, Jun 23, 2015 at 4:25 PM, Nick Dimiduk wrote:
> I'm happy to
Are you wanting to interface with HBase-client data from Phoenix, or is it
vice-versa? Phoenix's UNSIGNED_TINYINT type is the equivalent of using
HBase's Bytes.putByte(byte[], int, byte). HBase's Bytes encodings do not
preserve the sort order of negative values in encoded form, hence the
OrderedByt
+user
Hi Jeff,
Phoenix and non-Phoenix tables can co-exist in the same cluster, no problem.
Sharing the same table with both Phoenix and non-Phoenix clients can be a
bit tricky. Likely you'll become intimately familiar Phoenix's encoding
formats and compound-types. This interoperability is a roa
Hi Nishani,
Any progress on your module for including the SQL query in the UI?
Thanks,
Nick
On Wed, Jun 24, 2015 at 11:46 AM, Ayola Jayamaha
wrote:
> Hi All,
> I'll create a javascript module in angular to solve this issue and share.
>
> Thanks,
> Nishani.
>
> On Thu, Jun 25, 2015 at 12:09 AM,
The HBase team is happy to announce the availability of HBase 1.1.1!
Download it from an Apache mirror near you,
http://www.apache.org/dyn/closer.cgi/hbase/, or wire up through the maven
repo.
HBase 1.1.1 is the first patch release in the HBase 1.1 line, continuing on
the theme of bringing a stabl
Get your submissions in, the deadline is imminent!
On Thu, Jun 25, 2015 at 11:48 AM, Nick Dimiduk wrote:
> Hello developers, users, speakers,
>
> In honor of ApacheCON's inaugural "Apache: Big Data" event, I'm hoping to
> see a "HBase: NoSQL + SQL" tr
.
> >
> > Enis
> >
> > On Mon, Jun 22, 2015 at 9:18 AM, James Taylor
> > wrote:
> >
> > > Ok, I'll drop the branch tomorrow then. Thanks,
> > >
> > > James
> > >
> > > On Mon, Jun 22, 2015 at 9:16 AM, Nic
Hmm. Looks like i'm not the only one who's pushed stuff there. Okay, it's
gone.
On Wed, Jul 1, 2015 at 11:26 AM, James Taylor
wrote:
> Yes, it resurrected itself. :-) That'd be good if you could delete that
> branch to avoid any confusion.
>
> On Wed, Jul 1
, 2015 at 11:34 AM, Nick Dimiduk wrote:
> Hmm. Looks like i'm not the only one who's pushed stuff there. Okay, it's
> gone.
>
> On Wed, Jul 1, 2015 at 11:26 AM, James Taylor
> wrote:
>
>> Yes, it resurrected itself. :-) That'd be good if you could
If there is some
> > mistake please let me know.
> > Step 1 has been done. Updating the pom files are yet to be done.
> >
> > Thanks.
> >
> > [1] https://github.com/apache/phoenix/pull/96
> >
> > On Fri, Jul 3, 2015 at 12:46 AM, Ayola Jayamaha
> &
Sorry if this has already been resolved, I'm just getting back from an
extended absence.
I'm +1 for this as well. Can we remove 5.0.0 label from JIRA as well?
Presumably there's nothing with just the 5.0.0 label, so a simple removal
should suffice. I haven't checked though...
On Thu, Jul 9, 2015
Nice work Nishani!
On Mon, Aug 31, 2015 at 3:16 AM, Ayola Jayamaha
wrote:
> I also plan to do a screen cast on features of the Web App.
> 1. How to start the web app
> 2. The new features added to Phoenix
>
> The PRs can be found here[1,2].
>
> [1] https://github.com/apache/phoenix/pull/111
> [2
Glad to hear Phoenix is working so well for you!
This question comes up a lot, and it's something we need to support. I
think we need to do an audit on the PhoenixConnection object to ensure it
is safe for concurrent access from multiple threads. Do you have bandwidth
to look into this? It sounds
1 - 100 of 724 matches
Mail list logo
