[jira] [Updated] (PHOENIX-3304) Tracing tests failing
[ https://issues.apache.org/jira/browse/PHOENIX-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-3304: -- Fix Version/s: 4.9.0 > Tracing tests failing > - > > Key: PHOENIX-3304 > URL: https://issues.apache.org/jira/browse/PHOENIX-3304 > Project: Phoenix > Issue Type: Bug >Reporter: Samarth Jain >Assignee: James Taylor > Fix For: 4.9.0 > > > Sample run: > https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/lastCompletedBuild/testReport/ > I reverted by changes for PHOENIX-3174 since that was the last commit that > modified PhoenixMetricsSink but that didn't fix the test failures. It may > have to do with the refactoring to enable running test methods in parallel. > FYI, [~jamestaylor]. I am able to reproduce the failure locally on > 4.x-HBase-1.1 branch too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (PHOENIX-3304) Tracing tests failing
[ https://issues.apache.org/jira/browse/PHOENIX-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor reassigned PHOENIX-3304: - Assignee: James Taylor > Tracing tests failing > - > > Key: PHOENIX-3304 > URL: https://issues.apache.org/jira/browse/PHOENIX-3304 > Project: Phoenix > Issue Type: Bug >Reporter: Samarth Jain >Assignee: James Taylor > Fix For: 4.9.0 > > > Sample run: > https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/lastCompletedBuild/testReport/ > I reverted by changes for PHOENIX-3174 since that was the last commit that > modified PhoenixMetricsSink but that didn't fix the test failures. It may > have to do with the refactoring to enable running test methods in parallel. > FYI, [~jamestaylor]. I am able to reproduce the failure locally on > 4.x-HBase-1.1 branch too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-3304) Tracing tests failing
[ https://issues.apache.org/jira/browse/PHOENIX-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-3304: -- Attachment: PHOENIX-3304.patch Tests were passing individually, but not when run together because they were not registering a new uniquely named sink for each one. > Tracing tests failing > - > > Key: PHOENIX-3304 > URL: https://issues.apache.org/jira/browse/PHOENIX-3304 > Project: Phoenix > Issue Type: Bug >Reporter: Samarth Jain >Assignee: James Taylor > Fix For: 4.9.0 > > Attachments: PHOENIX-3304.patch > > > Sample run: > https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/lastCompletedBuild/testReport/ > I reverted by changes for PHOENIX-3174 since that was the last commit that > modified PhoenixMetricsSink but that didn't fix the test failures. It may > have to do with the refactoring to enable running test methods in parallel. > FYI, [~jamestaylor]. I am able to reproduce the failure locally on > 4.x-HBase-1.1 branch too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-3174) Make minor upgrade a manual step
[ https://issues.apache.org/jira/browse/PHOENIX-3174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508514#comment-15508514 ] Lars Hofhansl commented on PHOENIX-3174: This is awesome! One question: In 4.9.x (or 5.x) should we default auto-upgrade to false? (not sure what the best answer is, but it's worth considering) > Make minor upgrade a manual step > > > Key: PHOENIX-3174 > URL: https://issues.apache.org/jira/browse/PHOENIX-3174 > Project: Phoenix > Issue Type: Bug >Reporter: James Taylor >Assignee: Samarth Jain > Fix For: 4.9.0 > > Attachments: PHOENIX-3174.patch, PHOENIX-3174_v2.patch, > PHOENIX-3174_v3_master.patch, PHOENIX-3174_v4_master.patch, > PHOENIX-3174_v5_master.patch > > > Instead of automatically performing minor release upgrades to system tables > in an automated manner (on first connection), we should make upgrade a > separate manual step. If a newer client attempts to connect to a newer server > without the upgrade step having occurred, we'd fail the connection. > Though not as automated, this would give users more control and visibility > into when an upgrade over system tables occurs. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-3290) Move and/or combine as many NeedsOwnCluster tests to bring down test run time
[ https://issues.apache.org/jira/browse/PHOENIX-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508512#comment-15508512 ] Hudson commented on PHOENIX-3290: - FAILURE: Integrated in Jenkins build Phoenix-master #1410 (See [https://builds.apache.org/job/Phoenix-master/1410/]) PHOENIX-3290 Move and/or combine as many NeedsOwnCluster tests to bring (jamestaylor: rev 2d27179b3fcfc7a8d2c8f7bad4a37b3071c81961) * (edit) phoenix-core/src/test/java/org/apache/phoenix/util/TestUtil.java * (delete) phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseOwnClusterHBaseManagedTimeIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/SpillableGroupByIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/index/ImmutableIndexWithStatsIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseOwnClusterIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryWithLimitIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/CsvBulkLoadToolIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/ParallelIteratorsIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/ParallelStatsEnabledIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryTimeoutIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/index/ReadOnlyIndexFailureIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/CountDistinctCompressionIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/TransactionalViewIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseViewIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/ViewIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/coprocessor/StatisticsCollectionRunTrackerIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/StatsCollectorIT.java * (delete) phoenix-core/src/it/java/org/apache/phoenix/end2end/StatsCollectorWithSplitsAndMultiCFIT.java * (edit) pom.xml * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/index/txn/TxWriteFailureIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/index/MutableIndexFailureIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/UpgradeIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/KeyOnlyIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/MultiCfQueryExecIT.java * (delete) phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseOwnClusterClientManagedTimeIT.java * (edit) phoenix-core/src/test/java/org/apache/phoenix/query/BaseTest.java * (delete) phoenix-core/src/it/java/org/apache/phoenix/end2end/StatsCollectionDisabledIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/iterate/RoundRobinResultIteratorWithStatsIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/RenewLeaseIT.java * (delete) phoenix-core/src/it/java/org/apache/phoenix/end2end/StatsCollectorAbstractIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/rpc/PhoenixServerRpcIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/TenantSpecificTablesDDLIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/monitoring/PhoenixMetricsIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/IndexExtendedIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/UserDefinedFunctionsIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/QueryWithOffsetIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseTenantSpecificTablesIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/TenantSpecificTablesDMLIT.java * (edit) phoenix-core/src/main/java/org/apache/phoenix/util/MetaDataUtil.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/rpc/PhoenixClientRpcIT.java * (edit) phoenix-core/src/it/java/org/apache/phoenix/execute/PartialCommitIT.java > Move and/or combine as many NeedsOwnCluster tests to bring down test run time > - > > Key: PHOENIX-3290 > URL: https://issues.apache.org/jira/browse/PHOENIX-3290 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor > Attachments: PHOENIX-3290_WIP.patch, PHOENIX-3290_addendum1.patch, > PHOENIX-3290_v2.patch, PHOENIX-3290_v3.patch, PHOENIX-3290_v4.patch, > PHOENIX-3290_v5.patch, PHOENIX-3290_v6.patch, PHOENIX-3290_v7.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-3290) Move and/or combine as many NeedsOwnCluster tests to bring down test run time
[ https://issues.apache.org/jira/browse/PHOENIX-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-3290: -- Attachment: PHOENIX-3290_addendum1.patch Final patch > Move and/or combine as many NeedsOwnCluster tests to bring down test run time > - > > Key: PHOENIX-3290 > URL: https://issues.apache.org/jira/browse/PHOENIX-3290 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor > Attachments: PHOENIX-3290_WIP.patch, PHOENIX-3290_addendum1.patch, > PHOENIX-3290_v2.patch, PHOENIX-3290_v3.patch, PHOENIX-3290_v4.patch, > PHOENIX-3290_v5.patch, PHOENIX-3290_v6.patch, PHOENIX-3290_v7.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-3290) Move and/or combine as many NeedsOwnCluster tests to bring down test run time
[ https://issues.apache.org/jira/browse/PHOENIX-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-3290: -- Attachment: (was: PHOENIX-3290_addendum2.patch) > Move and/or combine as many NeedsOwnCluster tests to bring down test run time > - > > Key: PHOENIX-3290 > URL: https://issues.apache.org/jira/browse/PHOENIX-3290 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor > Attachments: PHOENIX-3290_WIP.patch, PHOENIX-3290_addendum1.patch, > PHOENIX-3290_v2.patch, PHOENIX-3290_v3.patch, PHOENIX-3290_v4.patch, > PHOENIX-3290_v5.patch, PHOENIX-3290_v6.patch, PHOENIX-3290_v7.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-3290) Move and/or combine as many NeedsOwnCluster tests to bring down test run time
[ https://issues.apache.org/jira/browse/PHOENIX-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-3290: -- Attachment: (was: PHOENIX-3290_addendum1.patch) > Move and/or combine as many NeedsOwnCluster tests to bring down test run time > - > > Key: PHOENIX-3290 > URL: https://issues.apache.org/jira/browse/PHOENIX-3290 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor > Attachments: PHOENIX-3290_WIP.patch, PHOENIX-3290_addendum1.patch, > PHOENIX-3290_v2.patch, PHOENIX-3290_v3.patch, PHOENIX-3290_v4.patch, > PHOENIX-3290_v5.patch, PHOENIX-3290_v6.patch, PHOENIX-3290_v7.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-3301) Row Value Constructors Against Indexes Don't Work Correctly
[
https://issues.apache.org/jira/browse/PHOENIX-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508124#comment-15508124
]
Brian Esserlieu commented on PHOENIX-3301:
--
[~jamestaylor] I updated the description to include proper repro steps. Please
let me know if anything there is unclear. CC [~samarthjain]
> Row Value Constructors Against Indexes Don't Work Correctly
> ---
>
> Key: PHOENIX-3301
> URL: https://issues.apache.org/jira/browse/PHOENIX-3301
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Brian Esserlieu
>
> Why does adding an ORDER BY change the number of records returned when there
> is a secondary index?
> Why without including an ORDER by are no records returned (seems to be
> hitting the base table and not the index)?
> I've included repro steps below:
> *Repro*
> {code:title=repro.sql|borderStyle=solid}
> DROP INDEX IF EXISTS TEST_INDEX ON TEST_TABLE;
> DROP TABLE IF EXISTS TEST_TABLE;
> CREATE TABLE IF NOT EXISTS TEST_TABLE (
> PK1 CHAR(15) NOT NULL,
> PK2 DATE NOT NULL
> CONSTRAINT PK PRIMARY KEY
> (
> PK1,
> PK2 DESC
> )
> );
> CREATE INDEX IF NOT EXISTS TEST_INDEX ON TEST_TABLE (PK2, PK1);
> UPSERT INTO TEST_TABLE (PK1, PK2)
> VALUES ('abc123',TO_DATE('2010-01-01T00:00:01Z'));
> UPSERT INTO TEST_TABLE (PK1, PK2)
> VALUES ('abc123',TO_DATE('2010-01-01T00:00:02Z'));
> UPSERT INTO TEST_TABLE (PK1, PK2)
> VALUES ('abc123',TO_DATE('2010-01-01T00:00:03Z'));
> -- Selects
> --This select statement returns 0 rows, though it should be returning the 3
> upserted rows from above
> SELECT PK1, PK2
> FROM TEST_TABLE
> WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
> -- the EXPLAIN shows the base table is being hit. Why is the base table hit
> with this RVC?
> explain SELECT PK1, PK2
> FROM TEST_TABLE
> WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
> --Note: by adding an ORDER BY statement, the query returns all 3 rows
> SELECT PK1, PK2
> FROM TEST_TABLE
> WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
> ORDER BY PK2, PK1;
> -- the EXPLAIN shows the secondary index is now being used by this query
> explain SELECT PK1, PK2
> FROM TEST_TABLE
> WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
> ORDER BY PK2, PK1;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Reopened] (PHOENIX-3301) Row Value Constructors Against Indexes Don't Work Correctly
[
https://issues.apache.org/jira/browse/PHOENIX-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Esserlieu reopened PHOENIX-3301:
--
> Row Value Constructors Against Indexes Don't Work Correctly
> ---
>
> Key: PHOENIX-3301
> URL: https://issues.apache.org/jira/browse/PHOENIX-3301
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Brian Esserlieu
>
> Why does adding an ORDER BY change the number of records returned when there
> is a secondary index?
> Why without including an ORDER by are no records returned (seems to be
> hitting the base table and not the index)?
> I've included repro steps below:
> *Repro*
> {code:title=repro.sql|borderStyle=solid}
> DROP INDEX IF EXISTS TEST_INDEX ON TEST_TABLE;
> DROP TABLE IF EXISTS TEST_TABLE;
> CREATE TABLE IF NOT EXISTS TEST_TABLE (
> PK1 CHAR(15) NOT NULL,
> PK2 DATE NOT NULL
> CONSTRAINT PK PRIMARY KEY
> (
> PK1,
> PK2 DESC
> )
> );
> CREATE INDEX IF NOT EXISTS TEST_INDEX ON TEST_TABLE (PK2, PK1);
> UPSERT INTO TEST_TABLE (PK1, PK2)
> VALUES ('abc123',TO_DATE('2010-01-01T00:00:01Z'));
> UPSERT INTO TEST_TABLE (PK1, PK2)
> VALUES ('abc123',TO_DATE('2010-01-01T00:00:02Z'));
> UPSERT INTO TEST_TABLE (PK1, PK2)
> VALUES ('abc123',TO_DATE('2010-01-01T00:00:03Z'));
> -- Selects
> --This select statement returns 0 rows, though it should be returning the 3
> upserted rows from above
> SELECT PK1, PK2
> FROM TEST_TABLE
> WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
> -- the EXPLAIN shows the base table is being hit. Why is the base table hit
> with this RVC?
> explain SELECT PK1, PK2
> FROM TEST_TABLE
> WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
> --Note: by adding an ORDER BY statement, the query returns all 3 rows
> SELECT PK1, PK2
> FROM TEST_TABLE
> WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
> ORDER BY PK2, PK1;
> -- the EXPLAIN shows the secondary index is now being used by this query
> explain SELECT PK1, PK2
> FROM TEST_TABLE
> WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
> ORDER BY PK2, PK1;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-3301) Row Value Constructors Against Indexes Don't Work Correctly
[
https://issues.apache.org/jira/browse/PHOENIX-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Esserlieu updated PHOENIX-3301:
-
Description:
Why does adding an ORDER BY change the number of records returned when there is
a secondary index?
Why without including an ORDER by are no records returned (seems to be hitting
the base table and not the index)?
I've included repro steps below:
*Repro*
{code:title=repro.sql|borderStyle=solid}
DROP INDEX IF EXISTS TEST_INDEX ON TEST_TABLE;
DROP TABLE IF EXISTS TEST_TABLE;
CREATE TABLE IF NOT EXISTS TEST_TABLE (
PK1 CHAR(15) NOT NULL,
PK2 DATE NOT NULL
CONSTRAINT PK PRIMARY KEY
(
PK1,
PK2 DESC
)
);
CREATE INDEX IF NOT EXISTS TEST_INDEX ON TEST_TABLE (PK2, PK1);
UPSERT INTO TEST_TABLE (PK1, PK2)
VALUES ('abc123',TO_DATE('2010-01-01T00:00:01Z'));
UPSERT INTO TEST_TABLE (PK1, PK2)
VALUES ('abc123',TO_DATE('2010-01-01T00:00:02Z'));
UPSERT INTO TEST_TABLE (PK1, PK2)
VALUES ('abc123',TO_DATE('2010-01-01T00:00:03Z'));
-- Selects
--This select statement returns 0 rows, though it should be returning the 3
upserted rows from above
SELECT PK1, PK2
FROM TEST_TABLE
WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
-- the EXPLAIN shows the base table is being hit. Why is the base table hit
with this RVC?
explain SELECT PK1, PK2
FROM TEST_TABLE
WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
--Note: by adding an ORDER BY statement, the query returns all 3 rows
SELECT PK1, PK2
FROM TEST_TABLE
WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
ORDER BY PK2, PK1;
-- the EXPLAIN shows the secondary index is now being used by this query
explain SELECT PK1, PK2
FROM TEST_TABLE
WHERE (PK2, PK1) >= (TO_DATE('1970-01-01'), null)
ORDER BY PK2, PK1;
{code}
was:
I was trying to run a delete statement using a row value constructor against a
table's secondary index, and noticed no data was being deleted. Digging into
the problem a bit more, I cant get any queries using a row value constructor
against the secondary index to work at all. I've included repro steps below:
*Repro*
{code:title=repro.sql|borderStyle=solid}
DROP INDEX IF EXISTS TEST_INDEX ON TEST_TABLE;
DROP TABLE IF EXISTS TEST_TABLE;
CREATE TABLE IF NOT EXISTS TEST_TABLE (
pk1 VARCHAR NOT NULL,
pk2 VARCHAR NOT NULL,
pk3 VARCHAR NOT NULL,
pk4 DATE NOT NULL,
pk5 VARCHAR NOT NULL,
v1 VARCHAR
CONSTRAINT PK PRIMARY KEY
(
pk1,
pk2,
pk3,
pk4 DESC,
pk5
)
) MULTI_TENANT=true,IMMUTABLE_ROWS=true;
CREATE INDEX TEST_INDEX ON TEST_TABLE (pk2, pk4, pk3, pk5);
upsert into TEST_TABLE (pk1, pk2, pk3, pk4, pk5, v1) values ('a', '001', '1',
TO_DATE('2000-01-01'), 'A', 'value');
upsert into TEST_TABLE (pk1, pk2, pk3, pk4, pk5, v1) values ('a', '001', '1',
TO_DATE('2000-01-01'), 'B', 'value');
-- THIS IS THIE ORDERING USING A DEFAULT ROW VALUE CONSTRUCTOR, USING
-- VALUES FOR THE ROW VALUE CONSTRUCTOR SUCH THAT BOTH TEST ROWS
-- SHOULD BE RETURNED
SELECT *
FROM TEST_TABLE
WHERE
pk1 = 'a' AND pk2 = '001' AND
(pk1, pk2, pk3, pk4, pk5) >= ('a', '001', '0', TO_DATE('1999-01-01'), 'A')
-- HERE ARE THE EXACT SAME VALUES, WITH FIELDS pk3 AND pk4 TRANSPOSED
SELECT *
FROM TEST_TABLE
WHERE
pk1 = 'a' AND pk2 = '001' AND
(pk1, pk2, pk4, pk3, pk5) >= ('a', '001', TO_DATE('1999-01-01'), '0', 'A')
-- NOTE, THAT NOTHING IS RETURNED BY THIS QUERY, BUT THE TWO TEST ROWS SHOULD
BE.
-- THIS SHOULD BE USING THE INDEX, BUT ISN'T:
EXPLAIN SELECT * FROM TEST_TABLE WHERE pk1 = 'a' AND pk2 = '001' AND
(pk1, pk2, pk4, pk3, pk5) >= ('a', '001', TO_DATE('1999-01-01'), '0', 'A')
-- IF WE CHANGE THE INEQUALITY TO BE LESS THAN OR EQUALS WITH THE TRANSPOSED ROW
-- KEY, NOTE THAT THE TEST ROWS ARE RETURNED (THEY SHOULDN'T BE):
SELECT *
FROM TEST_TABLE
WHERE
pk1 = 'a' AND pk2 = '001' AND
(pk1, pk2, pk4, pk3, pk5) <= ('a', '001', TO_DATE('1999-01-01'), '0', 'A')
-- HINTING TO USE AN INDEX DOESN'T WORK:
SELECT /*+ INDEX(TEST_TABLE TEST_INDEX) */ *
FROM TEST_TABLE
WHERE
pk1 = 'a' AND pk2 = '001' AND
(pk1, pk2, pk4, pk3, pk5) >= ('a', '001', TO_DATE('1999-01-01'), '0', 'A')
-- FORCING AN ORDERING THAT WOULD CAUSE THE INDEX TO BE USED DOESN'T WORK
EITHER:
SELECT *
FROM TEST_TABLE
WHERE
pk1 = 'a' AND pk2 = '001' AND
(pk1, pk2, pk4, pk3, pk5) >= ('a', '001', TO_DATE('1999-01-01'), '0', 'A')
ORDER BY pk1, pk2, pk4, pk3, pk5
-- THIS IS THE ORIGINAL DELETE STATEMENT I TRIED TO RUN, BUT IS FAILING
-- LIKELY FOR THE SAME REASON AS SELECTS ARE FAILING ABOVE
DELETE
FROM TEST_TABLE
WHERE
pk1 = 'a' AND pk2 = '001' AND
(pk1, pk2, pk4, pk3, pk5) >= ('a', '001', TO_DATE('1999-01-01'), '0', 'A')
{code}
> Row Value Constructors Against Indexes Don't Work Correctly
> ---
>
> Key: PHOENIX-3301
> URL: https://issues.apache.org/jira/browse/PHOENIX-3301
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter:
[jira] [Created] (PHOENIX-3304) Tracing tests failing
Samarth Jain created PHOENIX-3304: - Summary: Tracing tests failing Key: PHOENIX-3304 URL: https://issues.apache.org/jira/browse/PHOENIX-3304 Project: Phoenix Issue Type: Bug Reporter: Samarth Jain Sample run: https://builds.apache.org/job/Phoenix-4.x-HBase-1.1/lastCompletedBuild/testReport/ I reverted by changes for PHOENIX-3174 since that was the last commit that modified PhoenixMetricsSink but that didn't fix the test failures. It may have to do with the refactoring to enable running test methods in parallel. FYI, [~jamestaylor]. I am able to reproduce the failure locally on 4.x-HBase-1.1 branch too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-3290) Move and/or combine as many NeedsOwnCluster tests to bring down test run time
[ https://issues.apache.org/jira/browse/PHOENIX-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-3290: -- Attachment: PHOENIX-3290_addendum2.patch > Move and/or combine as many NeedsOwnCluster tests to bring down test run time > - > > Key: PHOENIX-3290 > URL: https://issues.apache.org/jira/browse/PHOENIX-3290 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor > Attachments: PHOENIX-3290_WIP.patch, PHOENIX-3290_addendum1.patch, > PHOENIX-3290_addendum2.patch, PHOENIX-3290_v2.patch, PHOENIX-3290_v3.patch, > PHOENIX-3290_v4.patch, PHOENIX-3290_v5.patch, PHOENIX-3290_v6.patch, > PHOENIX-3290_v7.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-3290) Move and/or combine as many NeedsOwnCluster tests to bring down test run time
[ https://issues.apache.org/jira/browse/PHOENIX-3290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Taylor updated PHOENIX-3290: -- Attachment: PHOENIX-3290_addendum1.patch > Move and/or combine as many NeedsOwnCluster tests to bring down test run time > - > > Key: PHOENIX-3290 > URL: https://issues.apache.org/jira/browse/PHOENIX-3290 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor > Attachments: PHOENIX-3290_WIP.patch, PHOENIX-3290_addendum1.patch, > PHOENIX-3290_v2.patch, PHOENIX-3290_v3.patch, PHOENIX-3290_v4.patch, > PHOENIX-3290_v5.patch, PHOENIX-3290_v6.patch, PHOENIX-3290_v7.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-476) Support declaration of DEFAULT in CREATE statement
[
https://issues.apache.org/jira/browse/PHOENIX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507262#comment-15507262
]
James Taylor commented on PHOENIX-476:
--
Yep, we'll disallow {{CURRENT_DATE}}. If we support it down the road, we'd have
to persist the value for the reason Julian mentioned.
bq. By the way, it's CURRENT_DATE not CURRENT_DATE().
Yeah, we're not following the standard - we should change it when we move to
Calcite. SQL is weird, though - what's wrong with the parens...
> Support declaration of DEFAULT in CREATE statement
> --
>
> Key: PHOENIX-476
> URL: https://issues.apache.org/jira/browse/PHOENIX-476
> Project: Phoenix
> Issue Type: Task
>Affects Versions: 3.0-Release
>Reporter: James Taylor
>Assignee: Kevin Liew
> Labels: enhancement
> Attachments: PHOENIX-476.2.patch, PHOENIX-476.3.patch,
> PHOENIX-476.patch
>
>
> Support the declaration of a default value in the CREATE TABLE/VIEW statement
> like this:
> CREATE TABLE Persons (
> Pid int NOT NULL PRIMARY KEY,
> LastName varchar(255) NOT NULL,
> FirstName varchar(255),
> Address varchar(255),
> City varchar(255) DEFAULT 'Sandnes'
> )
> To implement this, we'd need to:
> 1. add a new DEFAULT_VALUE key value column in SYSTEM.TABLE and pass through
> the value when the table is created (in MetaDataClient).
> 2. always set NULLABLE to ResultSetMetaData.columnNoNulls if a default value
> is present, since the column will never be null.
> 3. add a getDefaultValue() accessor in PColumn
> 4. for a row key column, during UPSERT use the default value if no value was
> specified for that column. This could be done in the PTableImpl.newKey method.
> 5. for a key value column with a default value, we can get away without
> incurring any storage cost. Although a little bit of extra effort than if we
> persisted the default value on an UPSERT for key value columns, this approach
> has the benefit of not incurring any storage cost for a default value.
> * serialize any default value into KeyValueColumnExpression
> * in the evaluate method of KeyValueColumnExpression, conditionally use
> the default value if the column value is not present. If doing partial
> evaluation, you should not yet return the default value, as we may not have
> encountered the the KeyValue for the column yet (since a filter evaluates
> each time it sees each KeyValue, and there may be more than one KeyValue
> referenced in the expression). Partial evaluation is determined by calling
> Tuple.isImmutable(), where false means it is NOT doing partial evaluation,
> while true means it is.
> * modify EvaluateOnCompletionVisitor by adding a visitor method for
> RowKeyColumnExpression and KeyValueColumnExpression to set
> evaluateOnCompletion to true if they have a default value specified. This
> will cause filter evaluation to execute one final time after all KeyValues
> for a row have been seen, since it's at this time we know we should use the
> default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (PHOENIX-3303) Handle Date/Time/Timestamp objects and interval types in RexNode-to-Expression translation
[ https://issues.apache.org/jira/browse/PHOENIX-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maryann Xue resolved PHOENIX-3303. -- Resolution: Fixed > Handle Date/Time/Timestamp objects and interval types in > RexNode-to-Expression translation > -- > > Key: PHOENIX-3303 > URL: https://issues.apache.org/jira/browse/PHOENIX-3303 > Project: Phoenix > Issue Type: Bug >Reporter: Maryann Xue >Assignee: Maryann Xue > Labels: calcite > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-476) Support declaration of DEFAULT in CREATE statement
[
https://issues.apache.org/jira/browse/PHOENIX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507229#comment-15507229
]
Julian Hyde commented on PHOENIX-476:
-
I don't think you should allow {{CURRENT_DATE}} or similar. The standard says
you should get the current date as of insert, but with your proposed
implementation mechanism you will get the current date as of when the statement
is executed.
By the way, it's {{CURRENT_DATE}} not {{CURRENT_DATE()}}. SQL doesn't use
parentheses for functions with zero arguments.
> Support declaration of DEFAULT in CREATE statement
> --
>
> Key: PHOENIX-476
> URL: https://issues.apache.org/jira/browse/PHOENIX-476
> Project: Phoenix
> Issue Type: Task
>Affects Versions: 3.0-Release
>Reporter: James Taylor
>Assignee: Kevin Liew
> Labels: enhancement
> Attachments: PHOENIX-476.2.patch, PHOENIX-476.3.patch,
> PHOENIX-476.patch
>
>
> Support the declaration of a default value in the CREATE TABLE/VIEW statement
> like this:
> CREATE TABLE Persons (
> Pid int NOT NULL PRIMARY KEY,
> LastName varchar(255) NOT NULL,
> FirstName varchar(255),
> Address varchar(255),
> City varchar(255) DEFAULT 'Sandnes'
> )
> To implement this, we'd need to:
> 1. add a new DEFAULT_VALUE key value column in SYSTEM.TABLE and pass through
> the value when the table is created (in MetaDataClient).
> 2. always set NULLABLE to ResultSetMetaData.columnNoNulls if a default value
> is present, since the column will never be null.
> 3. add a getDefaultValue() accessor in PColumn
> 4. for a row key column, during UPSERT use the default value if no value was
> specified for that column. This could be done in the PTableImpl.newKey method.
> 5. for a key value column with a default value, we can get away without
> incurring any storage cost. Although a little bit of extra effort than if we
> persisted the default value on an UPSERT for key value columns, this approach
> has the benefit of not incurring any storage cost for a default value.
> * serialize any default value into KeyValueColumnExpression
> * in the evaluate method of KeyValueColumnExpression, conditionally use
> the default value if the column value is not present. If doing partial
> evaluation, you should not yet return the default value, as we may not have
> encountered the the KeyValue for the column yet (since a filter evaluates
> each time it sees each KeyValue, and there may be more than one KeyValue
> referenced in the expression). Partial evaluation is determined by calling
> Tuple.isImmutable(), where false means it is NOT doing partial evaluation,
> while true means it is.
> * modify EvaluateOnCompletionVisitor by adding a visitor method for
> RowKeyColumnExpression and KeyValueColumnExpression to set
> evaluateOnCompletion to true if they have a default value specified. This
> will cause filter evaluation to execute one final time after all KeyValues
> for a row have been seen, since it's at this time we know we should use the
> default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PHOENIX-3303) Handle Date/Time/Timestamp objects and interval types in RexNode-to-Expression translation
Maryann Xue created PHOENIX-3303: Summary: Handle Date/Time/Timestamp objects and interval types in RexNode-to-Expression translation Key: PHOENIX-3303 URL: https://issues.apache.org/jira/browse/PHOENIX-3303 Project: Phoenix Issue Type: Bug Reporter: Maryann Xue Assignee: Maryann Xue -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-476) Support declaration of DEFAULT in CREATE statement
[
https://issues.apache.org/jira/browse/PHOENIX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507199#comment-15507199
]
James Taylor commented on PHOENIX-476:
--
Thanks for the patch, [~kliew]. Nice work so far - it's coming along nicely.
Here's some comments:
- Instead of using ExpressionUtil.isConstant(), use the following check:
{code}
expression.isStateless() && expression.getDeterminism() == Determinism.ALWAYS
{code}
Maybe we should rename ExpressionUtil.isConstant() to
ExpressionUtil.isConstantPerStatement() and use the above for a new
ExpressionUtil.isConstant()?
- We can't keep trailing nulls - that'll cause a world of problems. But on the
plus side, since we put default values explicitly into rows, we don't need to
wrap RowKeyExpression with getDefaultExpression. So you can just change this in
ExpressionCompiler:
{code}
+if (column.getDefaultExpression() != null &&
!SchemaUtil.isPKColumn(column)) {
+expression = new DefaultValueExpression(Arrays.asList(expression,
column.getDefaultExpression()));
+}
{code}
- Minor nit. Instead of ptr.copyBytes(), use
ByteUtil.copyKeyBytesIfNecessary(ptr) as that prevents a copy when it's not
necessary.
- Not sure on the test failure, but I suspect you'll want to tweak the
PRowImpl.setValue() call in PTableImpl. You'll want to be careful about the
{{isNull}} setting and the case when there's a default value. You likely need
to differentiate here between byteValue of null and a byteValue of an empty
byteValue:
{code}
public void setValue(PColumn column, byte[] byteValue) {
deleteRow = null;
byte[] family = column.getFamilyName().getBytes();
byte[] qualifier = column.getName().getBytes();
PDataType type = column.getDataType();
// Check null, since some types have no byte representation for null
boolean isNull = type.isNull(byteValue); // TODO: this might need
to change
{code}
> Support declaration of DEFAULT in CREATE statement
> --
>
> Key: PHOENIX-476
> URL: https://issues.apache.org/jira/browse/PHOENIX-476
> Project: Phoenix
> Issue Type: Task
>Affects Versions: 3.0-Release
>Reporter: James Taylor
>Assignee: Kevin Liew
> Labels: enhancement
> Attachments: PHOENIX-476.2.patch, PHOENIX-476.3.patch,
> PHOENIX-476.patch
>
>
> Support the declaration of a default value in the CREATE TABLE/VIEW statement
> like this:
> CREATE TABLE Persons (
> Pid int NOT NULL PRIMARY KEY,
> LastName varchar(255) NOT NULL,
> FirstName varchar(255),
> Address varchar(255),
> City varchar(255) DEFAULT 'Sandnes'
> )
> To implement this, we'd need to:
> 1. add a new DEFAULT_VALUE key value column in SYSTEM.TABLE and pass through
> the value when the table is created (in MetaDataClient).
> 2. always set NULLABLE to ResultSetMetaData.columnNoNulls if a default value
> is present, since the column will never be null.
> 3. add a getDefaultValue() accessor in PColumn
> 4. for a row key column, during UPSERT use the default value if no value was
> specified for that column. This could be done in the PTableImpl.newKey method.
> 5. for a key value column with a default value, we can get away without
> incurring any storage cost. Although a little bit of extra effort than if we
> persisted the default value on an UPSERT for key value columns, this approach
> has the benefit of not incurring any storage cost for a default value.
> * serialize any default value into KeyValueColumnExpression
> * in the evaluate method of KeyValueColumnExpression, conditionally use
> the default value if the column value is not present. If doing partial
> evaluation, you should not yet return the default value, as we may not have
> encountered the the KeyValue for the column yet (since a filter evaluates
> each time it sees each KeyValue, and there may be more than one KeyValue
> referenced in the expression). Partial evaluation is determined by calling
> Tuple.isImmutable(), where false means it is NOT doing partial evaluation,
> while true means it is.
> * modify EvaluateOnCompletionVisitor by adding a visitor method for
> RowKeyColumnExpression and KeyValueColumnExpression to set
> evaluateOnCompletion to true if they have a default value specified. This
> will cause filter evaluation to execute one final time after all KeyValues
> for a row have been seen, since it's at this time we know we should use the
> default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-3279) QueryPlan.iterator(ParallelScanGrouper scanGrouper) should pass null ('unknown') as scan parameter when calling this.iterator(ParallelScanGrouper scanGrouper, Scan sc
[
https://issues.apache.org/jira/browse/PHOENIX-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507201#comment-15507201
]
Hudson commented on PHOENIX-3279:
-
FAILURE: Integrated in Jenkins build Phoenix-master #1409 (See
[https://builds.apache.org/job/Phoenix-master/1409/])
PHOENIX-3279 QueryPlan.iterator(ParallelScanGrouper scanGrouper) should
(maryannxue: rev 7601d5942fdeb55c114295292e2100aafb84e861)
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/execute/ClientProcessingPlan.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/execute/TupleProjectionPlan.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/execute/DelegateQueryPlan.java
* (edit) phoenix-core/src/it/java/org/apache/phoenix/end2end/DerivedTableIT.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/execute/BaseQueryPlan.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/execute/CorrelatePlan.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/execute/ClientScanPlan.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/execute/ClientAggregatePlan.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/iterate/UnionResultIterators.java
* (edit)
phoenix-core/src/main/java/org/apache/phoenix/execute/UnnestArrayPlan.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/execute/HashJoinPlan.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/execute/UnionPlan.java
> QueryPlan.iterator(ParallelScanGrouper scanGrouper) should pass null
> ('unknown') as scan parameter when calling this.iterator(ParallelScanGrouper
> scanGrouper, Scan scan)
> -
>
> Key: PHOENIX-3279
> URL: https://issues.apache.org/jira/browse/PHOENIX-3279
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3279.patch
>
>
> This issue was introduced by PHOENIX-2628, and it caused a regression in
> CalciteIT after calcite branch was synced with master branch.
>
> In most implementations of QueryPlan.iterator(ParallelScanGrouper
> scanGrouper), the QueryPlan calls this.iterator(ParallelScanGrouper
> scanGrouper, Scan scan) with a Scan object it gets from its inner QueryPlan.
> This logic is actually wrong when a ScanPlan (or AggregatePlan) is nested in
> two or more DelegateQueryPlans. For example,
> TupleProjectionPlan(ClientScanPlan(ScanPlan), the TupleProjectionPlan will
> pass the ClientScanPlan.getContext().getScan() to
> ClientScanPlan.iterator(ParallelScanGrouper scanGrouper, Scan scan), and in
> turn to ScanPlan.iterator(ParallelScanGrouper scanGrouper, Scan scan), which
> will shadow the original Scan object in the ScanPlan.
>
> It would be better to just pass "null" in indicate "unknown" in this case.
> The QueryPlan which does care about the Scan object, which is mostly
> BaseQueryPlan, will have to handle this "null" value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-3299) Janino could not work in shaded package
[
https://issues.apache.org/jira/browse/PHOENIX-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507187#comment-15507187
]
Julian Hyde commented on PHOENIX-3299:
--
If you hard-code a package name or class name, shade can't re-locate it. But it
you instantiate an object, then ask it its class name or package name, it will
return the shaded path. Can you do that? Maybe have a dummy singleton object,
say {{enum Dummy { INSTANCE } }}.
> Janino could not work in shaded package
> ---
>
> Key: PHOENIX-3299
> URL: https://issues.apache.org/jira/browse/PHOENIX-3299
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>
> Calcite-Phoenix would encounter this ClassNotFoundException when trying to
> initiate its compiler. It was caused by putting janino into shaded packages.
> {code}
> imit 100": Unable to instantiate java compiler
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:199)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:807)
> at sqlline.SqlLine.runCommands(SqlLine.java:1710)
> at sqlline.Commands.run(Commands.java:1285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
> at sqlline.SqlLine.dispatch(SqlLine.java:803)
> at sqlline.SqlLine.initArgs(SqlLine.java:613)
> at sqlline.SqlLine.begin(SqlLine.java:656)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> Caused by: java.lang.IllegalStateException: Unable to instantiate java
> compiler
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.compile(JaninoRelMetadataProvider.java:417)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.load3(JaninoRelMetadataProvider.java:358)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.access$000(JaninoRelMetadataProvider.java:94)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$1.load(JaninoRelMetadataProvider.java:113)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$1.load(JaninoRelMetadataProvider.java:110)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3990)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.create(JaninoRelMetadataProvider.java:448)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.revise(JaninoRelMetadataProvider.java:460)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.revise(RelMetadataQuery.java:186)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:484)
> at
> org.apache.calcite.rel.metadata.RelMdCollation.filter(RelMdCollation.java:187)
> at
> org.apache.calcite.rel.logical.LogicalFilter$2.get(LogicalFilter.java:115)
> at
> org.apache.calcite.rel.logical.LogicalFilter$2.get(LogicalFilter.java:113)
> at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:238)
> at
> org.apache.calcite.rel.logical.LogicalFilter.create(LogicalFilter.java:111)
> at
> org.apache.calcite.rel.logical.LogicalFilter.create(LogicalFilter.java:103)
> at
> org.apache.calcite.rel.core.RelFactories$FilterFactoryImpl.createFilter(RelFactories.java:225)
> at org.apache.calcite.plan.RelOptUtil.createFilter(RelOptUtil.java:595)
> at org.apache.calcite.plan.RelOptUtil.createFilter(RelOptUtil.java:581)
> at
> org.apache.calcite.sql2rel.SqlToRelConverter.convertWhere(SqlToRelConverter.java:966)
> at
>
[jira] [Comment Edited] (PHOENIX-3299) Janino could not work in shaded package
[
https://issues.apache.org/jira/browse/PHOENIX-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507187#comment-15507187
]
Julian Hyde edited comment on PHOENIX-3299 at 9/20/16 5:23 PM:
---
If you hard-code a package name or class name, shade can't re-locate it. But it
you instantiate an object, then ask it its class name or package name, it will
return the shaded path. Can you do that? Maybe have a dummy singleton object.
was (Author: julianhyde):
If you hard-code a package name or class name, shade can't re-locate it. But it
you instantiate an object, then ask it its class name or package name, it will
return the shaded path. Can you do that? Maybe have a dummy singleton object,
say {{enum Dummy { INSTANCE } }}.
> Janino could not work in shaded package
> ---
>
> Key: PHOENIX-3299
> URL: https://issues.apache.org/jira/browse/PHOENIX-3299
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>
> Calcite-Phoenix would encounter this ClassNotFoundException when trying to
> initiate its compiler. It was caused by putting janino into shaded packages.
> {code}
> imit 100": Unable to instantiate java compiler
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:199)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:807)
> at sqlline.SqlLine.runCommands(SqlLine.java:1710)
> at sqlline.Commands.run(Commands.java:1285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
> at sqlline.SqlLine.dispatch(SqlLine.java:803)
> at sqlline.SqlLine.initArgs(SqlLine.java:613)
> at sqlline.SqlLine.begin(SqlLine.java:656)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> Caused by: java.lang.IllegalStateException: Unable to instantiate java
> compiler
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.compile(JaninoRelMetadataProvider.java:417)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.load3(JaninoRelMetadataProvider.java:358)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.access$000(JaninoRelMetadataProvider.java:94)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$1.load(JaninoRelMetadataProvider.java:113)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$1.load(JaninoRelMetadataProvider.java:110)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3990)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.create(JaninoRelMetadataProvider.java:448)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.revise(JaninoRelMetadataProvider.java:460)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.revise(RelMetadataQuery.java:186)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:484)
> at
> org.apache.calcite.rel.metadata.RelMdCollation.filter(RelMdCollation.java:187)
> at
> org.apache.calcite.rel.logical.LogicalFilter$2.get(LogicalFilter.java:115)
> at
> org.apache.calcite.rel.logical.LogicalFilter$2.get(LogicalFilter.java:113)
> at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:238)
> at
> org.apache.calcite.rel.logical.LogicalFilter.create(LogicalFilter.java:111)
> at
> org.apache.calcite.rel.logical.LogicalFilter.create(LogicalFilter.java:103)
> at
>
[jira] [Commented] (PHOENIX-3299) Janino could not work in shaded package
[
https://issues.apache.org/jira/browse/PHOENIX-3299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507072#comment-15507072
]
Maryann Xue commented on PHOENIX-3299:
--
Looks like after being moved to the shaded package, Janino could not locate the
corresponding packages for implementation classes. I tried removing the
"relocation" node for codehaus in pom files and it worked, but I'm wondering if
there's a better way to resolve this issue. [~jamestaylor], [~julianhyde], any
ideas?
> Janino could not work in shaded package
> ---
>
> Key: PHOENIX-3299
> URL: https://issues.apache.org/jira/browse/PHOENIX-3299
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
>
> Calcite-Phoenix would encounter this ClassNotFoundException when trying to
> initiate its compiler. It was caused by putting janino into shaded packages.
> {code}
> imit 100": Unable to instantiate java compiler
> at org.apache.calcite.avatica.Helper.createException(Helper.java:56)
> at org.apache.calcite.avatica.Helper.createException(Helper.java:41)
> at
> org.apache.calcite.avatica.AvaticaStatement.executeInternal(AvaticaStatement.java:147)
> at
> org.apache.calcite.avatica.AvaticaStatement.execute(AvaticaStatement.java:199)
> at sqlline.Commands.execute(Commands.java:822)
> at sqlline.Commands.sql(Commands.java:732)
> at sqlline.SqlLine.dispatch(SqlLine.java:807)
> at sqlline.SqlLine.runCommands(SqlLine.java:1710)
> at sqlline.Commands.run(Commands.java:1285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:36)
> at sqlline.SqlLine.dispatch(SqlLine.java:803)
> at sqlline.SqlLine.initArgs(SqlLine.java:613)
> at sqlline.SqlLine.begin(SqlLine.java:656)
> at sqlline.SqlLine.start(SqlLine.java:398)
> at sqlline.SqlLine.main(SqlLine.java:292)
> Caused by: java.lang.IllegalStateException: Unable to instantiate java
> compiler
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.compile(JaninoRelMetadataProvider.java:417)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.load3(JaninoRelMetadataProvider.java:358)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.access$000(JaninoRelMetadataProvider.java:94)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$1.load(JaninoRelMetadataProvider.java:113)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider$1.load(JaninoRelMetadataProvider.java:110)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3589)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2374)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2337)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2252)
> at com.google.common.cache.LocalCache.get(LocalCache.java:3990)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3994)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4878)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.create(JaninoRelMetadataProvider.java:448)
> at
> org.apache.calcite.rel.metadata.JaninoRelMetadataProvider.revise(JaninoRelMetadataProvider.java:460)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.revise(RelMetadataQuery.java:186)
> at
> org.apache.calcite.rel.metadata.RelMetadataQuery.collations(RelMetadataQuery.java:484)
> at
> org.apache.calcite.rel.metadata.RelMdCollation.filter(RelMdCollation.java:187)
> at
> org.apache.calcite.rel.logical.LogicalFilter$2.get(LogicalFilter.java:115)
> at
> org.apache.calcite.rel.logical.LogicalFilter$2.get(LogicalFilter.java:113)
> at org.apache.calcite.plan.RelTraitSet.replaceIfs(RelTraitSet.java:238)
> at
> org.apache.calcite.rel.logical.LogicalFilter.create(LogicalFilter.java:111)
> at
> org.apache.calcite.rel.logical.LogicalFilter.create(LogicalFilter.java:103)
> at
> org.apache.calcite.rel.core.RelFactories$FilterFactoryImpl.createFilter(RelFactories.java:225)
> at org.apache.calcite.plan.RelOptUtil.createFilter(RelOptUtil.java:595)
> at org.apache.calcite.plan.RelOptUtil.createFilter(RelOptUtil.java:581)
> at
>
[jira] [Resolved] (PHOENIX-3279) QueryPlan.iterator(ParallelScanGrouper scanGrouper) should pass null ('unknown') as scan parameter when calling this.iterator(ParallelScanGrouper scanGrouper, Scan sca
[
https://issues.apache.org/jira/browse/PHOENIX-3279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maryann Xue resolved PHOENIX-3279.
--
Resolution: Fixed
Committed. Thank you, [~jamestaylor], for the review!
> QueryPlan.iterator(ParallelScanGrouper scanGrouper) should pass null
> ('unknown') as scan parameter when calling this.iterator(ParallelScanGrouper
> scanGrouper, Scan scan)
> -
>
> Key: PHOENIX-3279
> URL: https://issues.apache.org/jira/browse/PHOENIX-3279
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Maryann Xue
>Assignee: Maryann Xue
> Fix For: 4.9.0
>
> Attachments: PHOENIX-3279.patch
>
>
> This issue was introduced by PHOENIX-2628, and it caused a regression in
> CalciteIT after calcite branch was synced with master branch.
>
> In most implementations of QueryPlan.iterator(ParallelScanGrouper
> scanGrouper), the QueryPlan calls this.iterator(ParallelScanGrouper
> scanGrouper, Scan scan) with a Scan object it gets from its inner QueryPlan.
> This logic is actually wrong when a ScanPlan (or AggregatePlan) is nested in
> two or more DelegateQueryPlans. For example,
> TupleProjectionPlan(ClientScanPlan(ScanPlan), the TupleProjectionPlan will
> pass the ClientScanPlan.getContext().getScan() to
> ClientScanPlan.iterator(ParallelScanGrouper scanGrouper, Scan scan), and in
> turn to ScanPlan.iterator(ParallelScanGrouper scanGrouper, Scan scan), which
> will shadow the original Scan object in the ScanPlan.
>
> It would be better to just pass "null" in indicate "unknown" in this case.
> The QueryPlan which does care about the Scan object, which is mostly
> BaseQueryPlan, will have to handle this "null" value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (PHOENIX-476) Support declaration of DEFAULT in CREATE statement
[
https://issues.apache.org/jira/browse/PHOENIX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15505920#comment-15505920
]
Kevin Liew edited comment on PHOENIX-476 at 9/20/16 7:51 AM:
-
I attached a new patch implementing default values for both primary and
row-value columns.
There are a few issues though.
* After compiling a default value ParseNode into an Expression, it becomes a
LiteralExpression. For `CURRENT_DATE()`, the ParseNode is stateless and the
compiled `Expression.isConstant` is true so we aren’t able to throw an
exception. Is there a existing expression compiler or a flag that will not
convert the default value ParseNode to LiteralExpression?
Setting `requiresFinalEvaluation` did not change the result.
* DefaultValueExpression wraps a ProjectedColumnExpression in
ExpressionCompiler.
I modified `ProjectedColumnExpression.evaluate` so that it returns true if the
cell contains a null value.
But `KeyValueSchema.next` returns `null` for trailing nulls in a row so
`ProjectedColumnExpression.evaluate` cannot differentiate between a trailing
null and trailing default value.
If we change the return value contract of `KeyValueSchema.next`, it causes
failures in other test cases (ie. SortMergeIT).
I’m not familiar with the serialization scheme for rows returned by the region
servers, but I suspect that trailing nulls are trimmed, which might be why
`KeyValueSchema.next` does not account for trailing nulls.
To fix this, we might have to provide an option to serialize trailing nulls
from region servers, change the return contract of `KeyValueSchema.next`, and
modify the affected components.
The following test case (which isn't in the patch) fails due to a trailing
default value that is overwritten by a null value:
{code:java}
@Test
public void testCreateTableTrailingNullOverwritingDefault() throws
Exception {
String table = generateRandomString();
String ddl = "CREATE TABLE " + table + " (" +
"pk INTEGER PRIMARY KEY, " +
"def INTEGER DEFAULT 1 + 9)";
long ts = nextTimestamp();
Properties props = new Properties();
props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(ts));
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.createStatement().execute(ddl);
String dml = "UPSERT INTO " + table + " VALUES (1, null)";
conn.createStatement().execute(dml);
conn.commit();
props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(ts +
10));
conn = DriverManager.getConnection(getUrl(), props);
ResultSet rs = conn.createStatement().executeQuery("SELECT * FROM " +
table + " WHERE pk = 1");
assertTrue(rs.next());
assertEquals(1, rs.getInt(1));
assertEquals(0, rs.getInt(2));
assertTrue(rs.wasNull());
assertFalse(rs.next());
}
{code}
was (Author: kliew):
I attached a new patch implementing default values for both primary and
row-value columns.
There are a few issues though.
* After compiling a default value ParseNode into an Expression, it becomes a
LiteralExpression. For `CURRENT_DATE()`, the ParseNode is stateless and the
compiled `Expression.isConstant` is true so we aren’t able to throw an
exception. Is there a existing expression compiler or a flag that will not
convert the default value ParseNode to LiteralExpression?
Setting `requiresFinalEvaluation` did not change the result.
* DefaultValueExpression wraps a ProjectedColumnExpression in
ExpressionCompiler.
I modified `ProjectedColumnExpression.evaluate` so that it returns true if the
cell contains a null value.
But `KeyValueSchema.next` returns `null` for trailing nulls in a row so
`ProjectedColumnExpression.evaluate` cannot differentiate between a trailing
null and trailing default value.
If we change the return value contract of `KeyValueSchema.next`, it causes
failures in other test cases (ie. SortMergeIT).
I’m not familiar with the serialization scheme for rows returned by the region
servers, but I suspect that trailing nulls are trimmed, which might be why
`KeyValueSchema.next` does not account for trailing nulls.
The following test case (which isn't in the patch) fails due to a trailing
default value that is overwritten by a null value:
{code:java}
@Test
public void testCreateTableTrailingNullOverwritingDefault() throws
Exception {
String table = generateRandomString();
String ddl = "CREATE TABLE " + table + " (" +
"pk INTEGER PRIMARY KEY, " +
"def INTEGER DEFAULT 1 + 9)";
long ts = nextTimestamp();
Properties props = new Properties();
props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(ts));
Connection conn = DriverManager.getConnection(getUrl(), props);
[jira] [Comment Edited] (PHOENIX-476) Support declaration of DEFAULT in CREATE statement
[
https://issues.apache.org/jira/browse/PHOENIX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15505920#comment-15505920
]
Kevin Liew edited comment on PHOENIX-476 at 9/20/16 7:47 AM:
-
I attached a new patch implementing default values for both primary and
row-value columns.
There are a few issues though.
* After compiling a default value ParseNode into an Expression, it becomes a
LiteralExpression. For `CURRENT_DATE()`, the ParseNode is stateless and the
compiled `Expression.isConstant` is true so we aren’t able to throw an
exception. Is there a existing expression compiler or a flag that will not
convert the default value ParseNode to LiteralExpression?
Setting `requiresFinalEvaluation` did not change the result.
* DefaultValueExpression wraps a ProjectedColumnExpression in
ExpressionCompiler.
I modified `ProjectedColumnExpression.evaluate` so that it returns true if the
cell contains a null value.
But `KeyValueSchema.next` returns `null` for trailing nulls in a row so
`ProjectedColumnExpression.evaluate` cannot differentiate between a trailing
null and trailing default value.
If we change the return value contract of `KeyValueSchema.next`, it causes
failures in other test cases (ie. SortMergeIT).
I’m not familiar with the serialization scheme for rows returned by the region
servers, but I suspect that trailing nulls are trimmed, which might be why
`KeyValueSchema.next` does not account for trailing nulls.
The following test case (which isn't in the patch) fails due to a trailing
default value that is overwritten by a null value:
{code:java}
@Test
public void testCreateTableTrailingNullOverwritingDefault() throws
Exception {
String table = generateRandomString();
String ddl = "CREATE TABLE " + table + " (" +
"pk INTEGER PRIMARY KEY, " +
"def INTEGER DEFAULT 1 + 9)";
long ts = nextTimestamp();
Properties props = new Properties();
props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(ts));
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.createStatement().execute(ddl);
String dml = "UPSERT INTO " + table + " VALUES (1, null)";
conn.createStatement().execute(dml);
conn.commit();
props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(ts +
10));
conn = DriverManager.getConnection(getUrl(), props);
ResultSet rs = conn.createStatement().executeQuery("SELECT * FROM " +
table + " WHERE pk = 1");
assertTrue(rs.next());
assertEquals(1, rs.getInt(1));
assertEquals(0, rs.getInt(2));
assertTrue(rs.wasNull());
assertFalse(rs.next());
}
{code}
was (Author: kliew):
I attached a new patch implementing default values for both primary and
row-value columns.
There are a few issues though.
* After compiling a default value ParseNode into an Expression, it becomes a
LiteralExpression. For `CURRENT_DATE()`, the ParseNode is stateless and the
compiled `Expression.isConstant` is true so we aren’t able to throw an
exception. Is there a existing expression compiler or a flag that will not
convert the default value ParseNode to LiteralExpression?
Setting `requiresFinalEvaluation` did not change the result.
* DefaultValueExpression wraps a ProjectedColumnExpression in
ExpressionCompiler.
I modified `ProjectedColumnExpression.evaluate` so that it returns true if the
cell contains a null value.
But `KeyValueSchema.next` returns `null` for trailing nulls in a row
`ProjectedColumnExpression.evaluate` cannot differentiate between a trailing
null and trailing default value.
If we change the return value contract of `KeyValueSchema.next`, it causes
failures in other test cases (ie. SortMergeIT).
I’m not familiar with the serialization scheme for rows returned by the region
servers, but I suspect that trailing nulls are trimmed, which might be why
`KeyValueSchema.next` does not account for trailing nulls.
The following test case (which isn't in the patch) fails due to a trailing
default value that is overwritten by a null value:
{code:java}
@Test
public void testCreateTableTrailingNullOverwritingDefault() throws
Exception {
String table = generateRandomString();
String ddl = "CREATE TABLE " + table + " (" +
"pk INTEGER PRIMARY KEY, " +
"def INTEGER DEFAULT 1 + 9)";
long ts = nextTimestamp();
Properties props = new Properties();
props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(ts));
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.createStatement().execute(ddl);
String dml = "UPSERT INTO " + table + " VALUES (1, null)";
conn.createStatement().execute(dml);
conn.commit();
[jira] [Updated] (PHOENIX-476) Support declaration of DEFAULT in CREATE statement
[
https://issues.apache.org/jira/browse/PHOENIX-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Liew updated PHOENIX-476:
---
Attachment: PHOENIX-476.3.patch
I attached a new patch implementing default values for both primary and
row-value columns.
There are a few issues though.
* After compiling a default value ParseNode into an Expression, it becomes a
LiteralExpression. For `CURRENT_DATE()`, the ParseNode is stateless and the
compiled `Expression.isConstant` is true so we aren’t able to throw an
exception. Is there a existing expression compiler or a flag that will not
convert the default value ParseNode to LiteralExpression?
Setting `requiresFinalEvaluation` did not change the result.
* DefaultValueExpression wraps a ProjectedColumnExpression in
ExpressionCompiler.
I modified `ProjectedColumnExpression.evaluate` so that it returns true if the
cell contains a null value.
But `KeyValueSchema.next` returns `null` for trailing nulls in a row
`ProjectedColumnExpression.evaluate` cannot differentiate between a trailing
null and trailing default value.
If we change the return value contract of `KeyValueSchema.next`, it causes
failures in other test cases (ie. SortMergeIT).
I’m not familiar with the serialization scheme for rows returned by the region
servers, but I suspect that trailing nulls are trimmed, which might be why
`KeyValueSchema.next` does not account for trailing nulls.
The following test case (which isn't in the patch) fails due to a trailing
default value that is overwritten by a null value:
{code:java}
@Test
public void testCreateTableTrailingNullOverwritingDefault() throws
Exception {
String table = generateRandomString();
String ddl = "CREATE TABLE " + table + " (" +
"pk INTEGER PRIMARY KEY, " +
"def INTEGER DEFAULT 1 + 9)";
long ts = nextTimestamp();
Properties props = new Properties();
props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(ts));
Connection conn = DriverManager.getConnection(getUrl(), props);
conn.createStatement().execute(ddl);
String dml = "UPSERT INTO " + table + " VALUES (1, null)";
conn.createStatement().execute(dml);
conn.commit();
props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(ts +
10));
conn = DriverManager.getConnection(getUrl(), props);
ResultSet rs = conn.createStatement().executeQuery("SELECT * FROM " +
table + " WHERE pk = 1");
assertTrue(rs.next());
assertEquals(1, rs.getInt(1));
assertEquals(0, rs.getInt(2));
assertTrue(rs.wasNull());
assertFalse(rs.next());
}
{code}
> Support declaration of DEFAULT in CREATE statement
> --
>
> Key: PHOENIX-476
> URL: https://issues.apache.org/jira/browse/PHOENIX-476
> Project: Phoenix
> Issue Type: Task
>Affects Versions: 3.0-Release
>Reporter: James Taylor
>Assignee: Kevin Liew
> Labels: enhancement
> Attachments: PHOENIX-476.2.patch, PHOENIX-476.3.patch,
> PHOENIX-476.patch
>
>
> Support the declaration of a default value in the CREATE TABLE/VIEW statement
> like this:
> CREATE TABLE Persons (
> Pid int NOT NULL PRIMARY KEY,
> LastName varchar(255) NOT NULL,
> FirstName varchar(255),
> Address varchar(255),
> City varchar(255) DEFAULT 'Sandnes'
> )
> To implement this, we'd need to:
> 1. add a new DEFAULT_VALUE key value column in SYSTEM.TABLE and pass through
> the value when the table is created (in MetaDataClient).
> 2. always set NULLABLE to ResultSetMetaData.columnNoNulls if a default value
> is present, since the column will never be null.
> 3. add a getDefaultValue() accessor in PColumn
> 4. for a row key column, during UPSERT use the default value if no value was
> specified for that column. This could be done in the PTableImpl.newKey method.
> 5. for a key value column with a default value, we can get away without
> incurring any storage cost. Although a little bit of extra effort than if we
> persisted the default value on an UPSERT for key value columns, this approach
> has the benefit of not incurring any storage cost for a default value.
> * serialize any default value into KeyValueColumnExpression
> * in the evaluate method of KeyValueColumnExpression, conditionally use
> the default value if the column value is not present. If doing partial
> evaluation, you should not yet return the default value, as we may not have
> encountered the the KeyValue for the column yet (since a filter evaluates
> each time it sees each KeyValue, and there may be more than one KeyValue
> referenced in the expression). Partial evaluation is determined by calling
> Tuple.isImmutable(), where false
[jira] [Comment Edited] (PHOENIX-3298) Create Table: Single column primary key may not be null
[
https://issues.apache.org/jira/browse/PHOENIX-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15505747#comment-15505747
]
James Taylor edited comment on PHOENIX-3298 at 9/20/16 6:46 AM:
Phoenix assumes that a single column PK is not nullable because it doesn't
allow a nullable single column PK. Since we're parsing the create table
statement, seems like we can handle this ourselves. We could deprecate this
behavior potentially too and change the tests.
was (Author: jamestaylor):
Phoenix assumes that a single column PK is not nullable because it doesn't
allow a non nullable single column PK. Since we're parsing the create table
statement, seems like we can handle this ourselves. We could deprecate this
behavior potentially too and change the tests.
> Create Table: Single column primary key may not be null
> ---
>
> Key: PHOENIX-3298
> URL: https://issues.apache.org/jira/browse/PHOENIX-3298
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Eric Lomore
>
> Create table statements with a single column currently must have "NOT NULL"
> identifier to pass tests.
> Running this code results in failure
> {code}CREATE TABLE t (k VARCHAR PRIMARY KEY DESC){code}
> While this allows tests to pass
> {code}CREATE TABLE t (k VARCHAR NOT NULL PRIMARY KEY DESC){code}
> Must either enforce the not null condition and update test cases, or apply a
> fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-3298) Create Table: Single column primary key may not be null
[
https://issues.apache.org/jira/browse/PHOENIX-3298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15505747#comment-15505747
]
James Taylor commented on PHOENIX-3298:
---
Phoenix assumes that a single column PK is not nullable because it doesn't
allow a non nullable single column PK. Since we're parsing the create table
statement, seems like we can handle this ourselves. We could deprecate this
behavior potentially too and change the tests.
> Create Table: Single column primary key may not be null
> ---
>
> Key: PHOENIX-3298
> URL: https://issues.apache.org/jira/browse/PHOENIX-3298
> Project: Phoenix
> Issue Type: Sub-task
>Reporter: Eric Lomore
>
> Create table statements with a single column currently must have "NOT NULL"
> identifier to pass tests.
> Running this code results in failure
> {code}CREATE TABLE t (k VARCHAR PRIMARY KEY DESC){code}
> While this allows tests to pass
> {code}CREATE TABLE t (k VARCHAR NOT NULL PRIMARY KEY DESC){code}
> Must either enforce the not null condition and update test cases, or apply a
> fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-3221) "LOCAL" keyword is not adhered for "phoenix.query.dateFormatTimeZone"
[ https://issues.apache.org/jira/browse/PHOENIX-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15505731#comment-15505731 ] Rajeshbabu Chintaguntla commented on PHOENIX-3221: -- Good catch [~an...@apache.org]. +1 > "LOCAL" keyword is not adhered for "phoenix.query.dateFormatTimeZone" > - > > Key: PHOENIX-3221 > URL: https://issues.apache.org/jira/browse/PHOENIX-3221 > Project: Phoenix > Issue Type: Bug >Reporter: Ankit Singhal >Assignee: Ankit Singhal > Fix For: 4.9.0 > > Attachments: PHOENIX-3221.patch > > > Currently, it is falling back to GMT. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
