[jira] [Updated] (PHOENIX-5275) Remove accidental imports from curator-client-2.12.0

[William Shen (JIRA)]

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

William Shen updated PHOENIX-5275:
--
Attachment: PHOENIX-5275.4.14-HBase-1.3.v1.patch

> Remove accidental imports from curator-client-2.12.0
> 
>
> Key: PHOENIX-5275
> URL: https://issues.apache.org/jira/browse/PHOENIX-5275
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Jacob Isaac
>Assignee: William Shen
>Priority: Minor
> Fix For: 4.15.0, 5.1.0, 4.14.3
>
> Attachments: PHOENIX-5275.4.14-HBase-1.3.v1.patch, 
> PHOENIX-5275.4.x-HBase-1.3.v1.patch, PHOENIX-5275.master.v1.patch, 
> PHOENIX-5275.master.v2.patch
>
>
> The following imports 
> import org.apache.curator.shaded.com.google.common.*
> were accidentally introduced in
> phoenix-core/src/test/java/org/apache/phoenix/query/QueryServicesTestImpl.java
> phoenix-core/src/it/java/org/apache/phoenix/end2end/UpgradeIT.java
> phoenix-core/src/test/java/org/apache/phoenix/compile/WhereOptimizerTest.java



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (PHOENIX-4845) Support using Row Value Constructors in OFFSET clause for paging in tables where the sort order of PK columns varies

[Daniel Wong (JIRA)]

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

Daniel Wong updated PHOENIX-4845:
-
Description: 
RVCs along with the LIMIT clause are useful for efficiently paging through rows 
(see [http://phoenix.apache.org/paged.html]). This works well if the pk columns 
are sorted ascending, we can always use the > operator to query for the next 
batch of row.

However if the PK of a table is (A  DESC, B DESC) we cannot use the following 
query to page through the data
{code:java}
SELECT * FROM TABLE WHERE (A, B) > (?, ?) ORDER BY A DESC, B DESC LIMIT 20
{code}
Since the rows are sorted by A desc and then by B descending we need change the 
comparison order
{code:java}
SELECT * FROM TABLE WHERE (A, B) < (?, ?) ORDER BY A DESC, B DESC LIMIT 20
{code}
If the PK of a table contains columns with mixed sort order for eg (A  DESC, B) 
then we cannot use RVC to page through data.

If we supported using RVCs in the offset clause we could use the offset to set 
the start row of the scan. Clients would not have to have logic to determine 
the comparison operator. This would also support paging through data for tables 
where the PK columns are sorted in mixed order.
{code:java}
SELECT * FROM TABLE ORDER BY A DESC, B LIMIT 20 OFFSET (?,?)
{code}
We would only allow using the offset if the rows are ordered by the sort order 
of the PK columns of and Index or Primary Table.

Note that there is some care is needed in the use of OFFSET with indexes.  If 
the OFFSET is coercible to multiple indexes/base table it could mean very 
different positions based on key.  To Handle This the INDEX hint needs to be 
used to specify an index offset for safety.

  was:
RVCs along with the LIMIT clause are useful for efficiently paging through rows 
(see [http://phoenix.apache.org/paged.html]). This works well if the pk columns 
are sorted ascending, we can always use the > operator to query for the next 
batch of row. 

However if the PK of a table is (A  DESC, B DESC) we cannot use the following 
query to page through the data
{code:java}
SELECT * FROM TABLE WHERE (A, B) > (?, ?) ORDER BY A DESC, B DESC LIMIT 20
{code}
Since the rows are sorted by A desc and then by B descending we need change the 
comparison order
{code:java}
SELECT * FROM TABLE WHERE (A, B) < (?, ?) ORDER BY A DESC, B DESC LIMIT 20
{code}

If the PK of a table contains columns with mixed sort order for eg (A  DESC, B) 
then we cannot use RVC to page through data. 

If we supported using RVCs in the offset clause we could use the offset to set 
the start row of the scan. Clients would not have to have logic to determine 
the comparison operator. This would also support paging through data for tables 
where the PK columns are sorted in mixed order. 
{code:java}
SELECT * FROM TABLE ORDER BY A DESC, B LIMIT 20 OFFSET (?,?)
{code}
We would only allow using the offset if the rows are ordered by the sort order 
of the PK columns.

 

FYI [~jfernando_sfdc]


> Support using Row Value Constructors in OFFSET clause for paging in tables 
> where the sort order of PK columns varies
> 
>
> Key: PHOENIX-4845
> URL: https://issues.apache.org/jira/browse/PHOENIX-4845
> Project: Phoenix
>  Issue Type: New Feature
>Reporter: Thomas D'Silva
>Assignee: Daniel Wong
>Priority: Major
>  Labels: DESC, SFDC
> Attachments: PHOENIX-offset.txt
>
>
> RVCs along with the LIMIT clause are useful for efficiently paging through 
> rows (see [http://phoenix.apache.org/paged.html]). This works well if the pk 
> columns are sorted ascending, we can always use the > operator to query for 
> the next batch of row.
> However if the PK of a table is (A  DESC, B DESC) we cannot use the following 
> query to page through the data
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) > (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> Since the rows are sorted by A desc and then by B descending we need change 
> the comparison order
> {code:java}
> SELECT * FROM TABLE WHERE (A, B) < (?, ?) ORDER BY A DESC, B DESC LIMIT 20
> {code}
> If the PK of a table contains columns with mixed sort order for eg (A  DESC, 
> B) then we cannot use RVC to page through data.
> If we supported using RVCs in the offset clause we could use the offset to 
> set the start row of the scan. Clients would not have to have logic to 
> determine the comparison operator. This would also support paging through 
> data for tables where the PK columns are sorted in mixed order.
> {code:java}
> SELECT * FROM TABLE ORDER BY A DESC, B LIMIT 20 OFFSET (?,?)
> {code}
> We would only allow using the offset if the rows are ordered by the sort 
> order of the PK columns of and Index or Primary Table.
> Note that there is 

Re: [VOTE] Release of Apache Phoenix 4.14.3 RC0

[swaroopa kadam]

Please use the following key: 48B7807D95F127B5

https://dist.apache.org/repos/dist/dev/phoenix/KEYS

Sorry about the inconvenience.

Thanks.

On Mon, Jul 29, 2019 at 11:13 AM swaroopa kadam 
wrote:

> That's a good point, Geoffrey.
> Let me update the release notes.
>
> Thanks.
>
> On Mon, Jul 29, 2019 at 9:45 AM Geoffrey Jacoby 
> wrote:
>
>> Exciting to see these changes about to be released!
>>
>> However, since the index changes will need some manual work by operators
>> to
>> upgrade their existing indexes to the new framework, shouldn't we have a
>> release note explaining to operators how to use the upgrade tool in
>> PHOENIX-5333? (Not upgrading indexes will just keep them working under the
>> old framework.)
>>
>> Also, maybe after release, we'll need some doc modification to the Phoenix
>> Secondary Index doc page at
>> http://phoenix.apache.org/secondary_indexing.html explaining the new
>> framework. In particular, some of the consistency guarantees are subtly
>> different (and better) now.
>>
>> I'll post a vote after testing the bits.
>>
>> Geoffrey
>>
>> On Mon, Jul 29, 2019 at 9:18 AM swaroopa kadam <
>> swaroopa.kada...@gmail.com>
>> wrote:
>>
>> > Hello Everyone,
>> >
>> > Happy Monday!
>> >
>> > This is a call for a vote on Apache Phoenix 4.14.3 RC0. This is a patch
>> > release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and
>> > 1.4. The release includes both a source-only release and a convenience
>> > binary
>> > release for each supported HBase version.
>> >
>> > This release includes critical bug fixes and improvements for secondary
>> > indexes -- making them self-consistent.
>> >
>> > The source tarball, including signatures, digests, etc can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc0/src/
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc0/src/
>> >
>> > The binary artifacts can be found at:
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc0/bin/
>> >
>> >
>> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc0/bin/
>> >
>> > For a complete list of changes, see:
>> >
>> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12345601
>> >
>> > Artifacts are signed with my "CODE SIGNING KEY": 95F127B5
>> >
>> > KEYS file available here:
>> > https://dist.apache.org/repos/dist/dev/phoenix/KEYS
>> >
>> > The hash and tag to be voted upon:
>> >
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=bfaa27edbc4029b5240d50689511d8b62457526e
>> >
>> >
>> >
>> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=2997bfb3c318825a5264ecee72e4214112a10151
>> >
>> > The vote will be open for at least 72 hours. Please vote:
>> >
>> > [ ] +1 approve
>> > [ ] +0 no opinion
>> > [ ] -1 disapprove (and the reason why)
>> >
>> > Thanks,
>> > The Apache Phoenix Team
>> > --
>> >
>> >
>> > Swaroopa Kadam
>> > [image: https://]about.me/swaroopa_kadam
>> > <
>> >
>> https://about.me/swaroopa_kadam?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api
>> > >
>> >
>>
>
>
> --
>
>
> Swaroopa Kadam
> [image: https://]about.me/swaroopa_kadam
> 
>


-- 


Swaroopa Kadam
[image: https://]about.me/swaroopa_kadam

[jira] [Updated] (PHOENIX-5411) Incorrect result is returned when using sum function with case when statement

[Geoffrey Jacoby (JIRA)]

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

Geoffrey Jacoby updated PHOENIX-5411:
-
Fix Version/s: 5.1.0

> Incorrect result is returned when using sum function with case when statement
> -
>
> Key: PHOENIX-5411
> URL: https://issues.apache.org/jira/browse/PHOENIX-5411
> Project: Phoenix
>  Issue Type: Bug
>Reporter: Toshihiro Suzuki
>Assignee: Toshihiro Suzuki
>Priority: Major
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5411.master.v1.patch, 
> PHOENIX-5411.master.v2.patch
>
>
> In the following case, incorrect result is returned:
> {code}
> 0: jdbc:phoenix:> create table tbl (id varchar primary key, col1 varchar, 
> col2 integer);
> No rows affected (0.86 seconds)
> 0: jdbc:phoenix:> upsert into tbl values('id1', 'aaa', 2);
> 1 row affected (0.078 seconds)
> 0: jdbc:phoenix:> upsert into tbl values('id2', null, 1);
> 1 row affected (0.008 seconds)
> 0: jdbc:phoenix:> select sum(case when col1 is not null then col2 else 0 
> end), sum(case when col1 is null then col2 else 0 end) from tbl;
> +---+---+
> | SUM(CASE WHEN COL1 IS NOT NULL THEN COL2 ELSE 0 END)  | SUM(CASE WHEN COL1 
> IS NOT NULL THEN COL2 ELSE 0 END)  |
> +---+---+
> | 2 | 2   
>   |
> +---+---+
> 1 row selected (0.03 seconds)
> {code}
> The correct result is (2, 1), but (2, 2) is returned.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: [VOTE] Release of Apache Phoenix 4.14.3 RC0

[swaroopa kadam]

That's a good point, Geoffrey.
Let me update the release notes.

Thanks.

On Mon, Jul 29, 2019 at 9:45 AM Geoffrey Jacoby  wrote:

> Exciting to see these changes about to be released!
>
> However, since the index changes will need some manual work by operators to
> upgrade their existing indexes to the new framework, shouldn't we have a
> release note explaining to operators how to use the upgrade tool in
> PHOENIX-5333? (Not upgrading indexes will just keep them working under the
> old framework.)
>
> Also, maybe after release, we'll need some doc modification to the Phoenix
> Secondary Index doc page at
> http://phoenix.apache.org/secondary_indexing.html explaining the new
> framework. In particular, some of the consistency guarantees are subtly
> different (and better) now.
>
> I'll post a vote after testing the bits.
>
> Geoffrey
>
> On Mon, Jul 29, 2019 at 9:18 AM swaroopa kadam  >
> wrote:
>
> > Hello Everyone,
> >
> > Happy Monday!
> >
> > This is a call for a vote on Apache Phoenix 4.14.3 RC0. This is a patch
> > release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and
> > 1.4. The release includes both a source-only release and a convenience
> > binary
> > release for each supported HBase version.
> >
> > This release includes critical bug fixes and improvements for secondary
> > indexes -- making them self-consistent.
> >
> > The source tarball, including signatures, digests, etc can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc0/src/
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc0/src/
> >
> > The binary artifacts can be found at:
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc0/bin/
> >
> >
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc0/bin/
> >
> > For a complete list of changes, see:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12345601
> >
> > Artifacts are signed with my "CODE SIGNING KEY": 95F127B5
> >
> > KEYS file available here:
> > https://dist.apache.org/repos/dist/dev/phoenix/KEYS
> >
> > The hash and tag to be voted upon:
> >
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=bfaa27edbc4029b5240d50689511d8b62457526e
> >
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=2997bfb3c318825a5264ecee72e4214112a10151
> >
> > The vote will be open for at least 72 hours. Please vote:
> >
> > [ ] +1 approve
> > [ ] +0 no opinion
> > [ ] -1 disapprove (and the reason why)
> >
> > Thanks,
> > The Apache Phoenix Team
> > --
> >
> >
> > Swaroopa Kadam
> > [image: https://]about.me/swaroopa_kadam
> > <
> >
> https://about.me/swaroopa_kadam?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api
> > >
> >
>


-- 


Swaroopa Kadam
[image: https://]about.me/swaroopa_kadam

Re: [VOTE] Release of Apache Phoenix 4.14.3 RC0

[Geoffrey Jacoby]

Exciting to see these changes about to be released!

However, since the index changes will need some manual work by operators to
upgrade their existing indexes to the new framework, shouldn't we have a
release note explaining to operators how to use the upgrade tool in
PHOENIX-5333? (Not upgrading indexes will just keep them working under the
old framework.)

Also, maybe after release, we'll need some doc modification to the Phoenix
Secondary Index doc page at
http://phoenix.apache.org/secondary_indexing.html explaining the new
framework. In particular, some of the consistency guarantees are subtly
different (and better) now.

I'll post a vote after testing the bits.

Geoffrey

On Mon, Jul 29, 2019 at 9:18 AM swaroopa kadam 
wrote:

> Hello Everyone,
>
> Happy Monday!
>
> This is a call for a vote on Apache Phoenix 4.14.3 RC0. This is a patch
> release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and
> 1.4. The release includes both a source-only release and a convenience
> binary
> release for each supported HBase version.
>
> This release includes critical bug fixes and improvements for secondary
> indexes -- making them self-consistent.
>
> The source tarball, including signatures, digests, etc can be found at:
>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc0/src/
>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc0/src/
>
> The binary artifacts can be found at:
>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc0/bin/
>
> https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc0/bin/
>
> For a complete list of changes, see:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12345601
>
> Artifacts are signed with my "CODE SIGNING KEY": 95F127B5
>
> KEYS file available here:
> https://dist.apache.org/repos/dist/dev/phoenix/KEYS
>
> The hash and tag to be voted upon:
>
>
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=bfaa27edbc4029b5240d50689511d8b62457526e
>
>
> https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=2997bfb3c318825a5264ecee72e4214112a10151
>
> The vote will be open for at least 72 hours. Please vote:
>
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and the reason why)
>
> Thanks,
> The Apache Phoenix Team
> --
>
>
> Swaroopa Kadam
> [image: https://]about.me/swaroopa_kadam
> <
> https://about.me/swaroopa_kadam?promo=email_sig_source=product_medium=email_sig_campaign=gmail_api
> >
>

[jira] [Updated] (PHOENIX-5104) PHOENIX-3547 breaks client backwards compatability

[Thomas D'Silva (JIRA)]

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

Thomas D'Silva updated PHOENIX-5104:

Fix Version/s: 5.1.0

> PHOENIX-3547 breaks client backwards compatability
> --
>
> Key: PHOENIX-5104
> URL: https://issues.apache.org/jira/browse/PHOENIX-5104
> Project: Phoenix
>  Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Lars Hofhansl
>Assignee: Mehdi Salarkia
>Priority: Blocker
>  Labels: SFDC
> Fix For: 4.15.0, 5.1.0
>
> Attachments: PHOENIX-5104.4.x-HBase-1.3.v1.patch, PHOENIX-5104.patch
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Scenario:
> * New 4.15 client
> ** {{create table ns1.test (pk1 integer not null, pk2 integer not null, pk3 
> integer not null, v1 float, v2 float, v3 integer CONSTRAINT pk PRIMARY KEY 
> (pk1, pk2, pk3));}}
> ** {{create local index l1 on ns1.test(v1);}}
> * Old 4.14.x client
> ** {{explain select count\(*) from test t1 where t1.v1 < 0.01;}}
> Result:
> {code}
> 0: jdbc:phoenix:localhost> explain select count(*) from ns1.test t1 where 
> t1.v1 < 0.01;
> Error: ERROR 201 (22000): Illegal data. Expected length of at least 8 bytes, 
> but had 2 (state=22000,code=201)
> java.sql.SQLException: ERROR 201 (22000): Illegal data. Expected length of at 
> least 8 bytes, but had 2
> at 
> org.apache.phoenix.exception.SQLExceptionCode$Factory$1.newException(SQLExceptionCode.java:494)
> at 
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:150)
> at 
> org.apache.phoenix.schema.types.PDataType.checkForSufficientLength(PDataType.java:290)
> at 
> org.apache.phoenix.schema.types.PLong$LongCodec.decodeLong(PLong.java:256)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:115)
> at org.apache.phoenix.schema.types.PLong.toObject(PLong.java:31)
> at 
> org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:994)
> at 
> org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:1035)
> at 
> org.apache.phoenix.schema.types.PDataType.toObject(PDataType.java:1031)
> at 
> org.apache.phoenix.iterate.ExplainTable.appendPKColumnValue(ExplainTable.java:207)
> at 
> org.apache.phoenix.iterate.ExplainTable.appendScanRow(ExplainTable.java:282)
> at 
> org.apache.phoenix.iterate.ExplainTable.appendKeyRanges(ExplainTable.java:297)
> at 
> org.apache.phoenix.iterate.ExplainTable.explain(ExplainTable.java:127)
> at 
> org.apache.phoenix.iterate.BaseResultIterators.explain(BaseResultIterators.java:1544)
> at 
> org.apache.phoenix.iterate.ConcatResultIterator.explain(ConcatResultIterator.java:92)
> at 
> org.apache.phoenix.iterate.BaseGroupedAggregatingResultIterator.explain(BaseGroupedAggregatingResultIterator.java:103)
> at 
> org.apache.phoenix.execute.BaseQueryPlan.getPlanSteps(BaseQueryPlan.java:524)
> at 
> org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:372)
> at 
> org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:217)
> at 
> org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:212)
> at 
> org.apache.phoenix.execute.BaseQueryPlan.iterator(BaseQueryPlan.java:207)
> at 
> org.apache.phoenix.execute.BaseQueryPlan.getExplainPlan(BaseQueryPlan.java:516)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableExplainStatement.compilePlan(PhoenixStatement.java:603)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement$ExecutableExplainStatement.compilePlan(PhoenixStatement.java:575)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:302)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement$1.call(PhoenixStatement.java:291)
> at org.apache.phoenix.call.CallRunner.run(CallRunner.java:53)
> at 
> org.apache.phoenix.jdbc.PhoenixStatement.executeQuery(PhoenixStatement.java:290)
> ...
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[VOTE] Release of Apache Phoenix 4.14.3 RC0

[swaroopa kadam]

Hello Everyone,

Happy Monday!

This is a call for a vote on Apache Phoenix 4.14.3 RC0. This is a patch
release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and
1.4. The release includes both a source-only release and a convenience
binary
release for each supported HBase version.

This release includes critical bug fixes and improvements for secondary
indexes -- making them self-consistent.

The source tarball, including signatures, digests, etc can be found at:
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc0/src/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc0/src/

The binary artifacts can be found at:
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.3-rc0/bin/
https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.3-HBase-1.4-rc0/bin/

For a complete list of changes, see:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12345601

Artifacts are signed with my "CODE SIGNING KEY": 95F127B5

KEYS file available here:
https://dist.apache.org/repos/dist/dev/phoenix/KEYS

The hash and tag to be voted upon:

https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=bfaa27edbc4029b5240d50689511d8b62457526e

https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=2997bfb3c318825a5264ecee72e4214112a10151

The vote will be open for at least 72 hours. Please vote:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and the reason why)

Thanks,
The Apache Phoenix Team
-- 


Swaroopa Kadam
[image: https://]about.me/swaroopa_kadam

Where to write JUnit test cases for phoenix function

[Vikash Talanki]

Hi,

I have started working on a JIRA  - implementing few missing functions on
Binary/Varbinary datatypes. This is going to be my first contribution to
Phoenix.
I have gone thru
http://phoenix-hbase.blogspot.com/2013/04/how-to-add-your-own-built-in-function.html
which was very helpful.
I have finished implementing the function and have to start writing the
test cases.
After going thru existing test cases for available functions which are
under src/it/java/org/apache/phoenix/end2end folder, I got an idea how to
write the test cases. But I am stuck at how to create and run these tests
in eclipse.
All the existing *FunctionIT classes have
*package* org.apache.phoenix.end2end;

But I do not see any package with name org.apache.phoenix.end2end under
phoenix-core. When I try to create a new class, its creating a new package with
name org.apache.phoenix.end2end which may be the correct way.
I think I'm missing something basic in creating the test classes.
Looking for some help in this area. Request someone to please provide any
reference on how to create and run the test cases.
-- 
Regards...

Vikash Talanki,
+1 408.203.2151