+1
On Monday, May 13, 2019, 1:31:35 PM EDT, Vincent Poon
wrote:
+1
On Sun, May 12, 2019 at 8:18 PM Andrew Purtell
wrote:
> +1
>
> I would think it would be a drain on committer time to keep having to
> accommodate interface differences on the EOL line.
>
> > On May 10, 2019, at 1:28
Hi all,
historically we have a branch of each version of HBase we want to support.As a
result we have many branches, committing is a hassle and it is easy to miss a
change across branches.
Instead we could have a maven module per version of HBase we want to support
and move the version dependent
> The tests would take longer to run (1.3, 1.4, 1.5 and 2.x). We should
> make
> > sure our precommit build will run the tests for all the modules.
> >
> >
> >
> > On Fri, May 17, 2019 at 11:23 AM la...@apache.org
> > wrote:
> >
> > > Hi all,
>
I just inspected the artifacts. Based on that: +1
On Saturday, May 18, 2019, 12:38:47 AM PDT, Thomas D'Silva
wrote:
Hello Everyone,
This is a call for a vote on Apache Phoenix 4.14.2 RC1. This is a patch
release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and 1.4.
The rele
+1 again based on inspection of the release artifacts.
On Thursday, May 23, 2019, 2:09:52 PM PDT, Thomas D'Silva
wrote:
Hello Everyone,
This is a call for a vote on Apache Phoenix 4.14.2 RC2. This is a patch
release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and 1.4.
The
I finally managed to get a single successful test run. Yeah! :)
The fact that this is worth a note to the @dev points to a larger problem,
though... Our tests have been failing for months (or years? I don't remember
that last successful run.)
I'll continue to stabilize the tests (for 4.15.x and
t. Is this change local only for now?
https://builds.apache.org/job/PreCommit-PHOENIX-Build/
On Mon, Jun 10, 2019 at 8:54 AM la...@apache.org wrote:
> I finally managed to get a single successful test run. Yeah! :)
>
> The fact that this is worth a note to the @dev points to a larger probl
Hi all,
we have three active 4.x branches: 4.x-HBase-1.3, 4.x-HBase-1.4, 4.x-HBase-1.5.
It looks like we're lacking _basic_ discipline here. There are patches in some
branches but not in others, some patches are different between these branches
for no good reason, different tests fail, etc.
I hav
l have only the last step
to perform, which would be to resolve any lingering test issues.
> On Jun 13, 2019, at 7:29 PM, "la...@apache.org" wrote:
>
> Hi all,
> we have three active 4.x branches: 4.x-HBase-1.3, 4.x-HBase-1.4,
> 4.x-HBase-1.5.
> It looks like we&#x
uld be pleased to offer my services for clean up duty. The ginsu
> I mean git knives for slicing and dicing history are sharp and at the
> ready. At the conclusion of the work you the Phoenix community will have
> only the last step to perform, which would be to resolve any lingering t
Hi all,
I'll be pushing out out a set of changes to speed up various tests.Let's see
how these go. If you see something strange, please let me know and I'll
revert/fix.
Most test runs already finish in around 2h (instead of 3h), but there're still
some bad offenders.
I'll do each test as a sepa
Hi all,
we're getting close. The test suite is passing fairly reliably now.(minus some
strange failure to archive the artifact in -1.4 and PartialCommitIT failing in
-1.3 only).
I put a lot of effort into speeding up the tests and making them pass. Let's
please (pretty please :) ) keep it that w
#x27;s advanced further than I know about, and we're closer
to green than I think. Happy to hear everyone's thoughts.
Geoffrey
On Thu, Jun 27, 2019 at 10:26 AM la...@apache.org wrote:
> Hi all,
> we're getting close. The test suite is passing fairly reliably now.(minus
> so
Hi all,
in the past weeks we had mostly successful test runs on 4.x-HBase-1.4
Yet when you look at that build it's all read. The reason is that tests all run
and finish and then Jenkins just hangs trying to archive the test artifacts for
an hour or more. That only happens on the -1.4 branch (doe
ering principles, namely an
always releasable code base and small, frequent releases.
-- Lars
On Thursday, June 27, 2019, 3:07:27 PM PDT, la...@apache.org
wrote:
Thanks Geoffrey.
The damage is already done. We messed up and let it slide (multiple times, this
is by no means the first time
t's fine for them to go in 4.14.3.
Geoffrey
On Fri, Jun 28, 2019 at 12:20 PM la...@apache.org wrote:
> Any further comments?
> I offered to be the RM for 4.15.0, and I stand by that. I can't do it
> alone, though. Do we have consensus on the rough course of action below?
&g
+1
On Monday, July 8, 2019, 12:57:27 PM HST, Thomas D'Silva
wrote:
I don't think we need to call 4.15/5.1 an alpha or beta release. Lets just
follow our usual process and release 4.15 and 5.1,
(after ensuring all the ITs pass and any manual testing that needs to be
done). If we need t
Does anybody know what could cause this? Failed at least the last 10 master
builds (which I have deleted). I'll leave one failed build up.
Seems to be happening in H35 only. Removed it from the build rotation (for
master for now)
On Thursday, July 18, 2019, 8:42:03 AM HST, la...@apache.org
wrote:
Does anybody know what could cause this? Failed at least the last 10 master
builds (which I have deleted). I'll leav
+1 (binding)
- Built from source
- Went through a simple 4.14 to 4.15 upgrade- Loaded a few dozens of millions
of rows.- Tried global and local indexes.- Tried HBase 1.5.0- Nothing weird in
the logs.
Looks good.
On a related note: I'd really love us to go back to a monthly release train.
That w
ropTable(MetaDataEndpointImpl.java:2153)
>
>
> On Fri, Oct 18, 2019 at 2:36 PM Chinmay Kulkarni <
> chinmayskulka...@gmail.com> wrote:
>
>> *REMINDER - [VOTE] Release of Apache Phoenix 4.15.0 RC0*
>>
>> Just sending out a friendly reminder to everyone to pleas
atibility issue.
>
> On Fri, Oct 18, 2019 at 4:25 PM la...@apache.org wrote:
>
> > Did you use one of the provided tarballs (in that case, which one)? Or
> > build from source (in that case, which branch?).
> > Also was that before or after the first 4.15 client
+1
On Wednesday, October 30, 2019, 8:27:36 AM PDT, Josh Elser
wrote:
Hi,
As was previously discussed[1][2], there is a motion to "adopt" the
Tephra and Omid podlings as sub-projects to Apache Phoenix. A
sub-project is a distinct software project from some top-level project
(TLP) bu
The slightly longer answer is that HBase is very well equipped to handle this
case.Row for inner/nested relationships can be stored inline with the parent
relation, by extending the key by one more part indicating the identity of
inner rows.The trick is to teach Phoenix to understand this - suc
I responded yesterday, but somehow didn't appear to go through. Trying again...
+1 (Binding)
- built from source (4.x-HBase-1.5) with latest branch-1 HBase (also built from
source)
- loaded a few million rows
- tried with local indexes
- issued upserts and deletes while splitting in HBase.
- ch
NDER - [VOTE] Release of Apache Phoenix 4.15.0 RC1*
>
> Just sending out a friendly reminder to everyone to please vote on Apache
> Phoenix 4.15.0 RC1 (thanks Lars).
>
> On Tue, Nov 19, 2019 at 2:49 PM la...@apache.org wrote:
>
>> I responded yesterday, but somehow
LECT * FROM VIEW` at 4.14 client.
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Xinyi Yan
> >>>>
> >>>> On Fri, Nov 22, 2019 at 11:52 AM Neha Gupta
> >>> wrote:
> >>>>
> >>>>> +1 (Non-B
+1 (binding)
I did the following:
- built from source
- verified tar ball
- ran with tip of HBase branch-1
- created tables, global and local ndexes, views, and indexes on views with
both 4.15.0 and older client
- upserted data alternately with a 4.15.0 and older client
- queried while upserting
That leads me to a general question:
(1) Will OMID and TEPHRA continue to be usable standalone without Phoenix? In
that case we should keep the OMID and TEPHRA projects in Jira.
Or (2) do we envision to tightly integrate those into the Phoenix and have them
only work in the Phoenix contexts?
reate a
> > table
> > > > > with a
> > > > > > > few indexes and ran some queries.
> > > > > > > Everything looks good.
> > > > > > >
> > > > > > > On Thu, Dec 5, 2019 at 11:35 AM C
unity we seem to fail following well known
software engineering principles (always releasable code base, agile principles,
frequent releases, comprehensive test suite, etc, etc).
Cheers.
-- Lars
On Friday, December 6, 2019, 1:57:50 PM PST, la...@apache.org
wrote:
Sigh. Agreed.
I chan
+1 (Binding)
Did the same tests as in RC2. :)
Cheers and crossing fingers.
-- Lars
On Monday, December 9, 2019, 02:48:41 PM PST, Chinmay Kulkarni
wrote:
Hello Everyone,
This is a call for a vote on Apache Phoenix 4.15.0 RC3. This is the next
minor release of Phoenix 4, compatible with
at, Dec 7, 2019 at 10:39 AM la...@apache.org wrote:
> I filed a blocker bug for 4.16.0 to improve backward compatibility and
> tests for the same.And I wow to veto any 4.16 release without that in
> place. We've almost reached the point at which Phoenix becomes
> unreleasable, thi
PMC, please test and vote on this :)
On Monday, December 9, 2019, 4:43:02 PM PST, la...@apache.org
wrote:
+1 (Binding)
Did the same tests as in RC2. :)
Cheers and crossing fingers.
-- Lars
On Monday, December 9, 2019, 02:48:41 PM PST, Chinmay Kulkarni
wrote:
Hello
+1 (binding)
Again... This time I did the following:
- Ran through upgrade and various test scripts using phoenix_sandbox.py (with
PHOENIX-5617 applied). This started with 4.14, created some tables, views, and
indexes, then with a 4.15 client, added/removed views, columns, and indexes,
then wit
You mean you see multiple rows with the same primary key? I have not see this
- or heard about this before.
Could you post your schema?
-- Lars
On Tuesday, December 17, 2019, 7:42:13 PM GMT+1, Francesco Malerba
wrote:
Hi all,
we are having some troubles with Phoenix 4.14 on top of H
This is really hard to follow.
I think we should do the same with HBase dependencies in Phoenix that HBase
does with Hadoop dependencies.
That is: We could have a maven module with the specific HBase version
dependent code.
Btw. Tephra does the same... A module for HBase version specific code.
Elser
wrote:
To clarify, you think that compat modules are better than that
separate-branches model in 4.x?
On 12/18/19 11:29 AM, la...@apache.org wrote:
> This is really hard to follow.
>
> I think we should do the same with HBase dependencies in Phoenix that HBase
> does
rit HBase classes or implement
HBase interfaces, and those can vary between minor versions. (See my above
example of a new coprocessor hook on BaseRegionObserver.)
Geoffrey
On Thu, Dec 19, 2019 at 10:54 AM la...@apache.org wrote:
> Yep. The differences are pretty minimal - provided they can be isol
herit HBase classes or implement
> HBase interfaces, and those can vary between minor versions. (See my above
> example of a new coprocessor hook on BaseRegionObserver.)
>
> Geoffrey
>
> On Thu, Dec 19, 2019 at 10:54 AM la...@apache.org
> wrote:
>
> > Yep. The d
Yeah! Finally.
Let's use this time to stabilize; especially the metadata management and
upgrade testing (and perhaps the HBase compatibility), so that we can have a
smooth 4.16.0 release.
On Saturday, December 21, 2019, 1:19:34 AM GMT+1, Chinmay Kulkarni
wrote:
Hello Everyone,
The A
en 1 and
2 is good enough for normal client operations. If the version check didn’t
throw an exception I wonder if there would be any issue.
For your consideration.
> On Dec 21, 2019, at 2:40 AM, "la...@apache.org" wrote:
>
> Yeah! Finally.
> Let's use this time
Hi all,
python2 is officially EOL'd. No more changes, improvements, or fixes will be
done by the developers.
Some Linux distributions stopped shipping Python2.
It turns out our scripts do not work with Python3, see: [PHOENIX-5656] Make
Phoenix scripts work with Python 3 - ASF JIRA.
[PHOENIX-56
ndier than bash but sometimes the
> right tool for the job is the right tool for the job. Unlike python, bash
> has a very stable grammar.
>
> On Thu, Jan 9, 2020 at 12:34 PM la...@apache.org wrote:
>
>> Hi all,
>>
>> python2 is officially EOL'd. No more changes,
... Not much else to say here...
The tests have been failing again for a while... I will NOT fix them again this
time! Sorry folks.
-- Lars
eople will presumably start to care. :)If I hear
no objects I'll start doing that a while.
Cheers.
-- Lars
On Monday, January 13, 2020, 06:23:01 PM PST, Josh Elser
wrote:
How do we keep getting into this mess: unreliable QA, people ignoring
QA, or something else?
On 1/12/20 9:24 PM
st too frustrating and
> error-prone.
>
> It would also be great if we could have a single Phoenix jar that works
> across HBase versions, but would not die on that hill :)
>
> On 12/20/19 5:04 AM, la...@apache.org wrote:
> > I said _provided_ they can be isolated easily
lways* passing. It's impossible to maintain a stable
code base the size of Phoenix otherwise.
-- Lars
On Tuesday, January 14, 2020, 10:04:12 AM PST, la...@apache.org
wrote:
I spent a lot of time making QA better. It can be better, but it's stable
enough. There're now
Just looking at the Phoenix Jenkins jobs I noticed that was no build on master
since for 3 weeks.
Is that in purpose? There were clearly changes on the master branch since then.
Cheers.
-- Lars
/Phoenix-master/
[2]
https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matrix/
On 4/8/20 2:00 PM, la...@apache.org wrote:
> Just looking at the Phoenix Jenkins jobs I noticed that was no build on
> master since for 3 weeks.
> Is that in purpose? There were clearly chan
.apache.org/view/M-R/view/Phoenix/job/PhoenixFindTestTimeout/
though I haven't looked into the last one.
István
On Thu, Apr 9, 2020 at 1:30 AM la...@apache.org wrote:
> Thanks Josh.
>
> unfortunately
>
> https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix-master-matr
This is the exception I'm seeing.
2020-05-15 15:35:36,098 FATAL [RS_OPEN_PRIORITY_REGION-think:16201-1]
regionserver.HRegionServer: ABORTING region server think,16201,1589581955446:
The coprocessor org.apache.phoenix.coprocessor.UngroupedAggregateRegionObserver
threw java.lang.NoClassDefFoundEr
PHOENIX-5808 looks suspicious (I do like the change, it just may introduce this
problem)
On Friday, May 15, 2020, 3:48:02 PM PDT, la...@apache.org
wrote:
This is the exception I'm seeing.
2020-05-15 15:35:36,098 FATAL [RS_OPEN_PRIORITY_REGION-think:16201-1]
regionserver.HRegionS
I can fix that by copying phoenix-hbase-compat-1.5.0-4.16.0-SNAPSHOT.jar from
phoenix/lib to hbase/lib.
That is not intended I assume. There used to be just the Phoenix server jar
needed.
On Friday, May 15, 2020, 3:55:32 PM PDT, la...@apache.org
wrote:
PHOENIX-5808 looks suspicious (I
ppropriate compatibility module
and add it too. At the least installation documentation should be updated.
On Fri, May 15, 2020 at 3:48 PM la...@apache.org wrote:
> This is the exception I'm seeing.
>
> 2020-05-15 15:35:36,098 FATAL [RS_OPEN_PRIORITY_REGION-think:16201-1]
>
Thanks Istvan.
Just checked the builds. Looks like the 4.x builds have not passed a single
time since May 20th.
I hope I am missing something... Otherwise this would be pretty frustrating. :)
(Since pleading doesn't appear to help, maybe we should automatically block all
commits until all tests
Hi All,
I won't have time to go through various tests again to speed them up as I did
last year.
Instead let me at least publicly shame the slowest tests that take more than 10
minutes to run:
1,620.111 org.apache.phoenix.end2end.InListIT
1,486.974 org.apache.phoenix.end2end.ParameterizedIndex
Geoffrey did the forward port for consistent indexes.
I'll add PHOENIX-5712 to the list of blockers - we've gotten ourselves into a
bind there with backwards compatibility,
and there's still not clear fix in sight as far as I can see. That same problem
exists for4.16.
On the HBase front all inn
Sorry for coming a bit late to this. I've been thinking about some of lines
for a bit.
It seems Phoenix serves 4 distinct purposes:
1. Query parsing and compiling.2. A type system3. Query execution4. Efficient
HBase interface
Each of these is useful by itself, but we do not expose these as stabl
I added some comments on the PHOENIX-4757
On Thursday, September 13, 2018, 6:42:12 PM PDT, Josh Elser
wrote:
Ahh, I get you now.
For a composite primary key made up of columns 1 through N, you want
similar controls to compute the value of the salt based on a sequence of
the columns
Lars. I like it very much.
Just the easy part of doing it... ;)
On 9/11/18 4:53 PM, la...@apache.org wrote:
> Sorry for coming a bit late to this. I've been thinking about some of lines
>for a bit.
> It seems Phoenix serves 4 distinct purposes:
> 1. Query parsing and compilin
I will point out that the thin client can have advantages too:1. The query
engine pool can be sized independently of clients and region servers now.2.
Appropriate machine/VM configurations can be picked that are optimal for query
execution.3. Client and (region) servers can be upgraded entirely
ot; API as opposed to an annotation-based
approach. I find a separate module helps to catch problematic API design
faster, and make it crystal clear what users should (and should not) be
relying upon).
On 9/17/18 1:00 AM, la...@apache.org wrote:
> I think we can start by implementing a ti
Hi all,
I'm planning to put together a Phoenix developer meetup at the Salesforce
office (with video conference for those who cannot attend in person) in the
next few weeks.
If you're interested please put your name in this
spreadsheet:https://docs.google.com/spreadsheets/d/1j4QSk53B0ZIl_qq1XX3o
10 people signed up so far.This is a good chance to make your voice heard,
give input, and help point the project in the right direction going forward.
-- Lars
On Friday, September 28, 2018, 10:39:41 AM PDT, la...@apache.org
wrote:
Hi all,
I'm planning to put together a Ph
Last call :)
On Monday, October 1, 2018, 10:15:07 AM PDT, la...@apache.org
wrote:
10 people signed up so far.This is a good chance to make your voice heard,
give input, and help point the project in the right direction going forward.
-- Lars
On Friday, September 28, 2018, 10:39
er 5, 2018, 1:01:06 PM PDT, la...@apache.org
wrote:
Last call :)
On Monday, October 1, 2018, 10:15:07 AM PDT, la...@apache.org
wrote:
10 people signed up so far.This is a good chance to make your voice heard,
give input, and help point the project in the right direction going f
would be great for planning food, etc. I will send out an agenda.
Thanks.
-- Lars
On Tuesday, October 23, 2018, 4:01:33 PM PDT, la...@apache.org
wrote:
This is still on.
I'm trying to get us a spot in the Salesforce tower top floor. As you can
imagine it's a coveted spot.If I c
ically!
Marked myself as a "M" for maybe on the spreadsheet :)
On 11/6/18 7:07 PM, la...@apache.org wrote:
> Ok. The room is booked for Wednesday November 14th from 4-7pm, in the
>Salesforce Tower (but not the top floor :( )
> If you can confirm your attendance here (see the e
Belated +1
Ran my usually tests. With upserts, deleted, global and local indexes, larger
upsert/selects, etc. Nothing undue in the logs, all works.
-- Lars
On Thursday, November 8, 2018, 3:55:07 PM PST, Vincent Poon
wrote:
The vote is now closed and passes with 4 binding +1s and no 0
let you up)
Thanks.
-- Lars
On Friday, November 9, 2018, 10:30:09 AM PST, la...@apache.org
wrote:
Great.
And sorry for the folks in other TZs, it's impossible to find a time for
everyone.I'll try to record the session via hangouts and post the recording
here, and I will post
om
On Tue, Nov 13, 2018 at 11:50 PM Jaanai Zhang
wrote:
> How to connect video conference？
>
>
> Jaanai Zhang
> Best regards!
>
>
>
> la...@apache.org 于2018年11月10日周六 上午6:48写道：
>
> > To confirm:
> > Phoenix
FWIW, I agree.
As I'm experiencing with the Trino (formerly Presto) Phoenix connector, it is
hard as is to support different versions of Phoenix (and HBase)...
To the point where I'm adding a second Phoenix connector to Trino just for
Phoenix 5.1.0+ support (and Phoenix 5.0 cannot be supported a
Actually it was relatively easy to work around PHOENIX-6377 - at least with
Trino (formerly Presto) where we discovered the problem in the first place.
That said, I'll hold off Phoenix 5.x support for Trino until after Phoenix
5.1.1 as long as we can get a release out soon'ish.
On Sunday, Febr
-1 (binding)
See https://issues.apache.org/jira/browse/PHOENIX-6400
I'm testing a bit more, but that looks wrong.
-- Lars
On Sunday, February 28, 2021, 7:32:09 PM PST, Xinyi Yan
wrote:
+1 (non-binding) based on the signature, checksum and mvn clean
install/verify.
On Sun, Feb 28, 202
My apologies if this is dumb question - I've been working on other projects for
a while, now coming back to some Phoenix work.
I'm trying to simply run mvn test -Dtest=LocalIndexIT locally.
And the test always fails with:
[ERROR] org.apache.phoenix.end2end.index.LocalIndexIT Time elapsed: 39.41
AHA...
Looks like hadoop-ci is failing with the same exception, since Feb 18th, looks
like PHOENIX-6359 is the culprit.
So it's not me.
On Monday, March 1, 2021, 5:46:51 PM PST, la...@apache.org
wrote:
My apologies if this is dumb question - I've been working on other proje
On 2021/03/02 02:03:03, "la...@apache.org" wrote:
> AHA...
> Looks like hadoop-ci is failing with the same exception, since Feb 18th,
> looks like PHOENIX-6359 is the culprit.
>
> So it's not me.
>
>
> On Monday, March 1, 2021, 5:46:51 PM PST, la...@apa
I have a real fix ready in PHOENIX-6402. Let's wait for that and then do a
5.1.1 release.
On Monday, March 1, 2021, 4:15:40 PM PST, la...@apache.org
wrote:
-1 (binding)
See https://issues.apache.org/jira/browse/PHOENIX-6400
I'm testing a bit more, but that looks wrong
I just committed PHOENIX-6402
Let's have another attempt at an RC for 5.1.1.
(Assuming all tests continue to pass)
-- Lars
On Sunday, March 7, 2021, 3:30:46 PM PST, la...@apache.org
wrote:
I have a real fix ready in PHOENIX-6402. Let's wait for that and then do a
5.1
Just came here to say the same.
While we're at it, let's also pull in PHOENIX-6409, as it bring better
visibility into local index plans.
-- Lars
On Thursday, March 11, 2021, 11:41:52 PM PST, Viraj Jasani
wrote:
Thanks Istvan.
I believe we can get in PHOENIX-6385 with 5.1.1 since it is
+1 (binding)
Built from source, ran some test loads with a few million rows on a local
install.
Ran some choice tests.
Nothing weird in the logs.
-- Lars
On Tuesday, March 16, 2021, 8:28:43 AM PDT, Istvan Toth
wrote:
Please vote on this Apache phoenix release candidate,
phoenix-5.1.
>
> at org.junit.Assert.assertEquals(Assert.java:117)
>
> at
> org.apache.phoenix.end2end.ViewTTLIT.verifyRowsBeforeTTLExpiration(ViewTTLIT.java:2462)
>
> at
> org.apache.phoenix.end2end.ViewTTLIT.validateExpiredRowsAreNotReturnedUsingData(ViewTTLIT.java:2390)
>
> at
> org.apache.phoenix.end2end.ViewTTLIT.upsertDataAndRunVa
In addition to the technical implementation of the PQS an interesting topic for
the PQS would be how to scale it.
How many PQSs compared to the number of region servers? How to size the
machine/VM? Etc.
I think just that could take more than 15 minutes. :)
On Thursday, March 18, 2021, 9:18:40 AM
An interesting topic would BigData ecosystem integration, which is clearly one
of the strengths of Phoenix.
I.e. with Trino (formerly Presto), Spark, and classical MapReduce. Perhaps this
could cover also HBase snapshot support.
I'm happy to cover this. But I can't to that for April 1st - juggl
If 5.1.1 is sunk for any reason, I'd like to get PHOENIX-6421 in. (By itself
it's not enough to sink the release, I think)
On Wednesday, March 17, 2021, 8:53:59 PM PDT, Xinyi Yan
wrote:
+1 (non-binding)
Besides the signature, checksum, and mvn install/verify, I built from the
source and
M PDT, la...@apache.org
wrote:
If 5.1.1 is sunk for any reason, I'd like to get PHOENIX-6421 in. (By itself
it's not enough to sink the release, I think)
On Wednesday, March 17, 2021, 8:53:59 PM PDT, Xinyi Yan
wrote:
+1 (non-binding)
Besides the signature, checksum,
leave the decision to the PMC.
We have two binding +2s at the moment, so I'll just follow procedure, and
make the decision based on the next binding vote.
Istvan
On Sat, Mar 20, 2021 at 7:30 PM la...@apache.org wrote:
> PHOENIX-6423 could be blocker...?
>
> What happens is that SEL
As you may or may not know, Phoenix allows for duplicate column names as long
as they are placed in different column families.
You can create a table such as CREATE TABLE t (pk1 ..., x.v1, y.v1, ...).
Now each time you want to refer to v1 you need to qualify it with its column
family or you get
gt; aliasing the columns may solve that)
> Another thing to consider is how this would affect dynamic column use cases
> for either native Phoenix tables of views on HBase tables.
>
> Istvan
>
> On Sat, Mar 27, 2021 at 12:20 AM la...@apache.org
> wrote:
>
> > As yo
column features are not
affected.
We may or may not want to add a property to override it (with the
default being disallowing the duplicate column names)
Istvan
On Sat, Mar 27, 2021 at 5:59 PM la...@apache.org wrote:
> Viraj, yeah similar discussion.
>
> Istvan, good point. Of course y
Please comment on the Jira if you have an opinion :)
On Monday, March 29, 2021, 10:48:34 AM PDT, la...@apache.org
wrote:
Filed https://issues.apache.org/jira/browse/PHOENIX-6433
We can discuss there.
In the end, IMHO, placing columns in distinct column families is a physical
There is also another angle to look at. A long time ago I wrote this:
"
It seems Phoenix serves 4 distinct purposes:
1. Query parsing and compiling.
2. A type system
3. Query execution
4. Efficient HBase interface
Each of these is useful by itself, but we do not expose these as stable
interfaces
Hi all,
I noticed some changes that went into both master and the 4.x branch, but not
into branch-5.1.
Unfortunately I do not have time to check each edit.
When you commit changes, please do not forget about branch-5.1, which will
produce our next version of Phoenix.
Cheers.
-- Lars
d hence can't go out in 4.16.2 or 5.1.2. (See PHOENIX-6247
> -- which should be marked Resolved -- and PHOENIX-6457).
>
> Do we need the dual maintenance of a 5.1 patch branch?
>
> Geoffrey
>
> On Wed, May 12, 2021 at 12:55 PM la...@apache.org
> wrote:
>
> > Hi
There are 17 resolved issues against it.
PHOENIX-6436 is needed for further integration with Trino (formerly Presto).
It is time for another point release?
-- Lars
y.
I will also look for missing fixes before release, but if anyone is aware
of any fix that is needed in 5.1.2 , but
hasn't been backported, then please try to get it resolved by Monday.
regards
Istvan
On Wed, May 26, 2021 at 4:19 AM la...@apache.org wrote:
> There are 17 resolved issu
Will sqlline still be part of the Phoenix "distribution"? Or will it become a
separate package to install?
On Wednesday, May 26, 2021, 1:07:17 AM PDT, Istvan Toth
wrote:
Hi!
The current purpose of the phoenix-client JAR is twofold:
- It servers as a generic JDBC driver for embedding
- if so - should not be in 5.1.2.
-- Lars
On Wednesday, May 26, 2021, 10:15:31 AM PDT, la...@apache.org
wrote:
Awesome. Thanks Istvan.
I'll do a pass through the issues too.
-- Lars
On Tuesday, May 25, 2021, 8:45:00 PM PDT, Istvan Toth wrote:
I am not aware of any blockers i
ded is great, so I'd lean towards #2.
>
> We can see what adoption of phoenix-client-embedded looks like now that
> we have it in releases. I imagine most folks haven't yet realized that
> it's even an option that's available.
>
> On 5/26/21 1:16 PM, la...@
1 - 100 of 105 matches
Mail list logo
