Re: [Discuss] Releasing Phoenix 4.16
Hi! A question of process: Should we backport fixes to the 4.16 branch at our discretion, or is backporting those handled by the release manager (Xinyi) ? On Thu, Jan 7, 2021 at 5:42 AM Istvan Toth wrote: > Hi! > > Thanks for everyone's effort on fixing the flakey tests. > However, our ASF Jenkins runs are still very unstable, and I am afraid > that the single clean 4.x run was down more to luck than to fixing the > underlying problem. > While I do not consider this a blocker, fixing this would make the pre- > and post commit tests far more useful, and let us start with a clean slate > for the next release. > I have created https://issues.apache.org/jira/browse/PHOENIX-6288 to > track the generic cluster setup issue, but my attempts to fix this, or at > least figure out the root cause have been unsuccessful so far. > > I ask for your help in fixing this issue. I have added some inconclusive > analysis to the ticket, and the full failsafe output directory is > downloadable as artifacts from the failed multibranch runs (stored for a > few days), which should hold the answer to this riddle. > > regards, > Istvan > > On Thu, Jan 7, 2021 at 4:58 AM Xinyi Yan wrote: > >> Hi, >> >> We finally have a stable 4.x branch build after many flapper test fixing >> contributions from the community. I'm going to fork a new branch(4.16) >> from >> the current 4.x branch for the 4.16 release. As a cutoff, I will not >> include any new features other than PHOENIX-6211 and bug fix. Please let >> me >> know if you have any questions or concerns. >> >> Thanks, >> Xinyi >> >> On Wed, Dec 23, 2020 at 6:07 AM Viraj Jasani wrote: >> >> > An update on test stability: >> > >> > As per recent 4.x build results, we are left with very few flappers and >> > specifically >> > with HBase profile 1.6, I can see recent 7 build (multibranch + PR >> > precommit results) >> > results without any test failure. >> > >> > >> > On Tue, Dec 15, 2020 at 5:52 AM Xinyi Yan wrote: >> > >> > > Yes, we are currently working on fixing the 4.x branch test flappers >> > while >> > > waiting for the PHOENIX-5435. After that, I will try to have an RC >> ASAP. >> > > >> > > On Sun, Dec 13, 2020 at 3:29 PM Ankit Singhal < >> ankitsingha...@gmail.com> >> > > wrote: >> > > >> > > > I see that both the blockers listed here PHOENIX-5712 and >> PHOENIX-6241 >> > > > have been resolved(Thanks to Xinyi), and also as per the JIRA query >> > there >> > > > is no Jira marked as a blocker for 4.16 except the one related to >> > > > documentation >> > > > for "splittable catalog table". >> > > > >> > > > Xinyi, so are we good to start the release process now? >> > > > >> > > > On Wed, Dec 2, 2020 at 9:32 PM Xinyi Yan >> wrote: >> > > > >> > > > > Thanks for replying and providing suggestions. I looked at the >> wrong >> > > > result >> > > > > Jira list that Daniel provided and did some local testing, and >> here >> > is >> > > > the >> > > > > result: >> > > > > [resolved] PHOENIX-4116, PHOENIX-4419, and PHOENIX-4642: cannot >> > > reproduce >> > > > > it. >> > > > > [More information is required] PHOENIX-4504 cannot reproduce it >> but >> > > > someone >> > > > > claimed that he had a similar issue. >> > > > > [unusual query] PHOENIX-4540 and PHOENIX-6217 >> > > > > >> > > > > Based on my finding, I think it's better to have more frequent >> > > > housekeeping >> > > > > and resolve unreproducible bugs especially since many of them are >> > > > > considering out of date (phoenix-4.11 or even phoenix-4.6). Since >> I >> > > still >> > > > > need time to work on the blocker Jira(PHOENIX-5712, PHOENIX-6241) >> and >> > > fix >> > > > > test flappers, if you want to fix "unusual query" bugs, feel free >> to >> > do >> > > > so. >> > > > > >> > > > > >> > > > > Sincerely, >> > > > > Xinyi >> > > > > >> > > > > On Wed, Dec 2, 2020 at 12:41 AM Ankit Singhal >> > > wrote: >> > > > > >> > > > > > Thanks Daniel and appreciate the effort you put in getting the >> list >> > > > ready >> > > > > > for bugs producing wrong results >> > > > > > but none of them seems to be a blocker to me for 4.16 as they >> are >> > not >> > > > the >> > > > > > regression and doesn't break the general functionality >> > > > > > except for specific features, RVC/desc as Chenglei also pointed >> out >> > > > > (though >> > > > > > I'll defer the assessment to RM "Xinyi"). >> > > > > > Probably these can be a part of 4.16.1 or we can do 4.17.0 soon >> > maybe >> > > > > after >> > > > > > a few weeks/month? >> > > > > > >> > > > > > Considering that we have already fixed 137 bugs and done 85+ >> > > > > > improvements/features in 4.16, >> > > > > > it will not be a good idea to deprive the user from such fixes. >> > > > > > It's been a year since our last 4.15 release, having no release >> > > brings >> > > > > more >> > > > > > questions on the project >> > > > > > rather than the bugs which affect a certain % of feature/users, >> > would >> > > > the >> > > > > > release notes >> > > > > >
[jira] [Created] (PHOENIX-6304) Fix TenantSpecificTablesDMLIT failed
Chao Wang created PHOENIX-6304: -- Summary: Fix TenantSpecificTablesDMLIT failed Key: PHOENIX-6304 URL: https://issues.apache.org/jira/browse/PHOENIX-6304 Project: Phoenix Issue Type: Test Affects Versions: 5.0.0 Reporter: Chao Wang Assignee: Chao Wang TenantSpecificTablesDMLIT is failing some times. org.apache.phoenix.thirdparty.com.google.common.util.concurrent.UncheckedExecutionException: org.apache.phoenix.exception.PhoenixNonRetryableRuntimeException: java.lang.ClassNotFoundException: org.notreal.class at org.apache.phoenix.thirdparty.com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2049) at org.apache.phoenix.thirdparty.com.google.common.cache.LocalCache.get(LocalCache.java:3849) at org.apache.phoenix.thirdparty.com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4711) at org.apache.phoenix.jdbc.PhoenixDriver.getConnectionQueryServices(PhoenixDriver.java:261) at org.apache.phoenix.jdbc.PhoenixEmbeddedDriver.createConnection(PhoenixEmbeddedDriver.java:142) at org.apache.phoenix.jdbc.PhoenixDriver.connect(PhoenixDriver.java:241) at java.sql.DriverManager.getConnection(DriverManager.java:664) at java.sql.DriverManager.getConnection(DriverManager.java:270) at org.apache.phoenix.coprocessor.WhereConstantParser.getConnectionlessConnection(WhereConstantParser.java:106) at org.apache.phoenix.coprocessor.WhereConstantParser.addViewInfoToPColumnsIfNeeded(W -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [Discuss] Releasing Phoenix 4.16
Hi! Thanks for everyone's effort on fixing the flakey tests. However, our ASF Jenkins runs are still very unstable, and I am afraid that the single clean 4.x run was down more to luck than to fixing the underlying problem. While I do not consider this a blocker, fixing this would make the pre- and post commit tests far more useful, and let us start with a clean slate for the next release. I have created https://issues.apache.org/jira/browse/PHOENIX-6288 to track the generic cluster setup issue, but my attempts to fix this, or at least figure out the root cause have been unsuccessful so far. I ask for your help in fixing this issue. I have added some inconclusive analysis to the ticket, and the full failsafe output directory is downloadable as artifacts from the failed multibranch runs (stored for a few days), which should hold the answer to this riddle. regards, Istvan On Thu, Jan 7, 2021 at 4:58 AM Xinyi Yan wrote: > Hi, > > We finally have a stable 4.x branch build after many flapper test fixing > contributions from the community. I'm going to fork a new branch(4.16) from > the current 4.x branch for the 4.16 release. As a cutoff, I will not > include any new features other than PHOENIX-6211 and bug fix. Please let me > know if you have any questions or concerns. > > Thanks, > Xinyi > > On Wed, Dec 23, 2020 at 6:07 AM Viraj Jasani wrote: > > > An update on test stability: > > > > As per recent 4.x build results, we are left with very few flappers and > > specifically > > with HBase profile 1.6, I can see recent 7 build (multibranch + PR > > precommit results) > > results without any test failure. > > > > > > On Tue, Dec 15, 2020 at 5:52 AM Xinyi Yan wrote: > > > > > Yes, we are currently working on fixing the 4.x branch test flappers > > while > > > waiting for the PHOENIX-5435. After that, I will try to have an RC > ASAP. > > > > > > On Sun, Dec 13, 2020 at 3:29 PM Ankit Singhal < > ankitsingha...@gmail.com> > > > wrote: > > > > > > > I see that both the blockers listed here PHOENIX-5712 and > PHOENIX-6241 > > > > have been resolved(Thanks to Xinyi), and also as per the JIRA query > > there > > > > is no Jira marked as a blocker for 4.16 except the one related to > > > > documentation > > > > for "splittable catalog table". > > > > > > > > Xinyi, so are we good to start the release process now? > > > > > > > > On Wed, Dec 2, 2020 at 9:32 PM Xinyi Yan > wrote: > > > > > > > > > Thanks for replying and providing suggestions. I looked at the > wrong > > > > result > > > > > Jira list that Daniel provided and did some local testing, and here > > is > > > > the > > > > > result: > > > > > [resolved] PHOENIX-4116, PHOENIX-4419, and PHOENIX-4642: cannot > > > reproduce > > > > > it. > > > > > [More information is required] PHOENIX-4504 cannot reproduce it but > > > > someone > > > > > claimed that he had a similar issue. > > > > > [unusual query] PHOENIX-4540 and PHOENIX-6217 > > > > > > > > > > Based on my finding, I think it's better to have more frequent > > > > housekeeping > > > > > and resolve unreproducible bugs especially since many of them are > > > > > considering out of date (phoenix-4.11 or even phoenix-4.6). Since I > > > still > > > > > need time to work on the blocker Jira(PHOENIX-5712, PHOENIX-6241) > and > > > fix > > > > > test flappers, if you want to fix "unusual query" bugs, feel free > to > > do > > > > so. > > > > > > > > > > > > > > > Sincerely, > > > > > Xinyi > > > > > > > > > > On Wed, Dec 2, 2020 at 12:41 AM Ankit Singhal > > > wrote: > > > > > > > > > > > Thanks Daniel and appreciate the effort you put in getting the > list > > > > ready > > > > > > for bugs producing wrong results > > > > > > but none of them seems to be a blocker to me for 4.16 as they are > > not > > > > the > > > > > > regression and doesn't break the general functionality > > > > > > except for specific features, RVC/desc as Chenglei also pointed > out > > > > > (though > > > > > > I'll defer the assessment to RM "Xinyi"). > > > > > > Probably these can be a part of 4.16.1 or we can do 4.17.0 soon > > maybe > > > > > after > > > > > > a few weeks/month? > > > > > > > > > > > > Considering that we have already fixed 137 bugs and done 85+ > > > > > > improvements/features in 4.16, > > > > > > it will not be a good idea to deprive the user from such fixes. > > > > > > It's been a year since our last 4.15 release, having no release > > > brings > > > > > more > > > > > > questions on the project > > > > > > rather than the bugs which affect a certain % of feature/users, > > would > > > > the > > > > > > release notes > > > > > > explaining the stability of certain features set the right > > > expectation > > > > > for > > > > > > those users who rely on these features to wait for a future > > release? > > > > > > > > > > > > Regards, > > > > > > Ankit Singhal > > > > > > > > > > > > On Tue, Dec 1, 2020 at 8:21 PM cheng...@apache.org < > > > > cheng...@apache.org> > > > > > > wrote: > > > > > > > > > > >
Re: [Discuss] Releasing Phoenix 4.16
Hi, We finally have a stable 4.x branch build after many flapper test fixing contributions from the community. I'm going to fork a new branch(4.16) from the current 4.x branch for the 4.16 release. As a cutoff, I will not include any new features other than PHOENIX-6211 and bug fix. Please let me know if you have any questions or concerns. Thanks, Xinyi On Wed, Dec 23, 2020 at 6:07 AM Viraj Jasani wrote: > An update on test stability: > > As per recent 4.x build results, we are left with very few flappers and > specifically > with HBase profile 1.6, I can see recent 7 build (multibranch + PR > precommit results) > results without any test failure. > > > On Tue, Dec 15, 2020 at 5:52 AM Xinyi Yan wrote: > > > Yes, we are currently working on fixing the 4.x branch test flappers > while > > waiting for the PHOENIX-5435. After that, I will try to have an RC ASAP. > > > > On Sun, Dec 13, 2020 at 3:29 PM Ankit Singhal > > wrote: > > > > > I see that both the blockers listed here PHOENIX-5712 and PHOENIX-6241 > > > have been resolved(Thanks to Xinyi), and also as per the JIRA query > there > > > is no Jira marked as a blocker for 4.16 except the one related to > > > documentation > > > for "splittable catalog table". > > > > > > Xinyi, so are we good to start the release process now? > > > > > > On Wed, Dec 2, 2020 at 9:32 PM Xinyi Yan wrote: > > > > > > > Thanks for replying and providing suggestions. I looked at the wrong > > > result > > > > Jira list that Daniel provided and did some local testing, and here > is > > > the > > > > result: > > > > [resolved] PHOENIX-4116, PHOENIX-4419, and PHOENIX-4642: cannot > > reproduce > > > > it. > > > > [More information is required] PHOENIX-4504 cannot reproduce it but > > > someone > > > > claimed that he had a similar issue. > > > > [unusual query] PHOENIX-4540 and PHOENIX-6217 > > > > > > > > Based on my finding, I think it's better to have more frequent > > > housekeeping > > > > and resolve unreproducible bugs especially since many of them are > > > > considering out of date (phoenix-4.11 or even phoenix-4.6). Since I > > still > > > > need time to work on the blocker Jira(PHOENIX-5712, PHOENIX-6241) and > > fix > > > > test flappers, if you want to fix "unusual query" bugs, feel free to > do > > > so. > > > > > > > > > > > > Sincerely, > > > > Xinyi > > > > > > > > On Wed, Dec 2, 2020 at 12:41 AM Ankit Singhal > > wrote: > > > > > > > > > Thanks Daniel and appreciate the effort you put in getting the list > > > ready > > > > > for bugs producing wrong results > > > > > but none of them seems to be a blocker to me for 4.16 as they are > not > > > the > > > > > regression and doesn't break the general functionality > > > > > except for specific features, RVC/desc as Chenglei also pointed out > > > > (though > > > > > I'll defer the assessment to RM "Xinyi"). > > > > > Probably these can be a part of 4.16.1 or we can do 4.17.0 soon > maybe > > > > after > > > > > a few weeks/month? > > > > > > > > > > Considering that we have already fixed 137 bugs and done 85+ > > > > > improvements/features in 4.16, > > > > > it will not be a good idea to deprive the user from such fixes. > > > > > It's been a year since our last 4.15 release, having no release > > brings > > > > more > > > > > questions on the project > > > > > rather than the bugs which affect a certain % of feature/users, > would > > > the > > > > > release notes > > > > > explaining the stability of certain features set the right > > expectation > > > > for > > > > > those users who rely on these features to wait for a future > release? > > > > > > > > > > Regards, > > > > > Ankit Singhal > > > > > > > > > > On Tue, Dec 1, 2020 at 8:21 PM cheng...@apache.org < > > > cheng...@apache.org> > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In my opinion, we should keep releases light and frequent, and > for > > > > some > > > > > > unusual query bugs like RVC and DESC > > > > > > we could delay fix to next release . I think we should release > > 4.16.0 > > > > and > > > > > > 5.1.0 as quickly as possible. In China, many users > > > > > > in HBase User Group thought that Phoenix was dead > because > > > our > > > > > too > > > > > > long interval release and stopped using > > > > > > Phoenix. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > At 2020-12-02 08:45:46, "Chinmay Kulkarni" < > > > chinmayskulka...@gmail.com > > > > > > > > > > > wrote: > > > > > > >I agree. These are all major bugs and we should aim at solving > > them > > > > > after > > > > > > >checking that they are still issues. I am +1 on 5833 and I think > > > 5484 > > > > > > would > > > > > > >be a great addition to 4.16 as well. We should aim at resolving > > high > > > > > > >priority bugs like this in every release. > > > > > > > > > > > > > >Sometimes we let these bugs slip
[jira] [Updated] (PHOENIX-6262) Bulk Load have a bug in lowercase tablename
[
https://issues.apache.org/jira/browse/PHOENIX-6262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chao Wang updated PHOENIX-6262:
---
Attachment: PHOENIX-6262.master.003.patch
> Bulk Load have a bug in lowercase tablename
> ---
>
> Key: PHOENIX-6262
> URL: https://issues.apache.org/jira/browse/PHOENIX-6262
> Project: Phoenix
> Issue Type: Bug
> Components: core
>Affects Versions: 5.0.0
>Reporter: zhengjiewen
>Assignee: Chao Wang
>Priority: Major
> Fix For: 5.1.0
>
> Attachments: PHOENIX-6262.master.001.patch,
> PHOENIX-6262.master.002.patch, PHOENIX-6262.master.003.patch
>
>
> h1. Bulk Load in lowercase tablename
> {color:#172b4d}when I use phoenix bulk load command to import csv file to
> phoenix table，{color} there{color:#172b4d} are get error.{color}
> {code:java}
> //代码占位符
> Exception in thread "main" java.lang.IllegalArgumentException: Table
> "test"."ods_om_om_order_test" not foundException in thread "main"
> java.lang.IllegalArgumentException: Table "test"."ods_om_om_order_test" not
> found at
> org.apache.phoenix.util.SchemaUtil.generateColumnInfo(SchemaUtil.java:956) at
> org.apache.phoenix.mapreduce.AbstractBulkLoadTool.buildImportColumns(AbstractBulkLoadTool.java:377)
> at
> org.apache.phoenix.mapreduce.AbstractBulkLoadTool.loadData(AbstractBulkLoadTool.java:211)
> at
> org.apache.phoenix.mapreduce.AbstractBulkLoadTool.run(AbstractBulkLoadTool.java:180)
> at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:76) at
> org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:90) at
> org.apache.phoenix.mapreduce.CsvBulkLoadTool.main(CsvBulkLoadTool.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498) at
> org.apache.hadoop.util.RunJar.run(RunJar.java:313) at
> org.apache.hadoop.util.RunJar.main(RunJar.java:227)
> {code}
> my command is ：
> {code:java}
> hadoop jar
> /opt/cloudera/parcels/CDH/lib/hbase/lib/phoenix-5.0.0-cdh6.2.0-client.jar
> org.apache.phoenix.mapreduce.CsvBulkLoadTool -s \"\"test\"\" -t
> \"\"ods_om_om_order_test\"\" -i
> /tmp/phoenix/ods_om_om_order_test5/data.csv{code}
> {color:#172b4d}And I found the source code have a bug in
> *org.apache.phoenix.jdbc.PhoenixDatabaseMetaData#*{color}*getColumns.*
> This method splices the tableName and schemaName into SQL statements to query
> the System.catalog. but if your tableName or schemaName is lowercase，that
> would be the *'"test"'* and *'"ods_om_om_order_test"'* so that will can not
> query the result and then return table not found exception.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6257) Fix PartialIndexRebuilderIT test flapper
[ https://issues.apache.org/jira/browse/PHOENIX-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xinyi Yan resolved PHOENIX-6257. Resolution: Duplicate > Fix PartialIndexRebuilderIT test flapper > > > Key: PHOENIX-6257 > URL: https://issues.apache.org/jira/browse/PHOENIX-6257 > Project: Phoenix > Issue Type: Improvement >Reporter: Xinyi Yan >Assignee: Xinyi Yan >Priority: Major > Fix For: 4.16.0 > > > PartialIndexRebuilderIT failed 2 out of last 10 runs. > > h3. Error Message > expected:<3> but was:<2> > h3. Stacktrace > java.lang.AssertionError: expected:<3> but was:<2> at > org.junit.Assert.fail(Assert.java:89) at > org.junit.Assert.failNotEquals(Assert.java:835) at > org.junit.Assert.assertEquals(Assert.java:647) at > org.junit.Assert.assertEquals(Assert.java:633) at > org.apache.phoenix.end2end.index.PartialIndexRebuilderIT.testIndexWriteFailureDuringRebuild(PartialIndexRebuilderIT.java:895) > at > org.apache.phoenix.end2end.index.PartialIndexRebuilderIT.testIndexWriteFailureDisablingIndex(PartialIndexRebuilderIT.java:818) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at > org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) at > org.junit.rules.RunRules.evaluate(RunRules.java:20) at > org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.ParentRunner.run(ParentRunner.java:413) at > org.junit.runners.Suite.runChild(Suite.java:128) at > org.junit.runners.Suite.runChild(Suite.java:27) at > org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at > org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at > org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at > org.junit.runners.ParentRunner.run(ParentRunner.java:413) at > org.apache.maven.surefire.junitcore.JUnitCore.run(JUnitCore.java:55) at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:137) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:107) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:83) > at > org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:75) > at > org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:158) > at > org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383) > at > org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344) > at > org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6303) bump Scala version for spark connector to 2.11.12, the same that Spark 2.4.7 uses
[ https://issues.apache.org/jira/browse/PHOENIX-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth resolved PHOENIX-6303. -- Fix Version/s: connectors-6.0.0 Resolution: Fixed Committed. Thanks for the review [~RichardAntal] > bump Scala version for spark connector to 2.11.12, the same that Spark 2.4.7 > uses > - > > Key: PHOENIX-6303 > URL: https://issues.apache.org/jira/browse/PHOENIX-6303 > Project: Phoenix > Issue Type: Improvement > Components: connectors, spark-connector >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Fix For: connectors-6.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6302) Fix ConcurrentUpsertsWithoutIndexedColsIT flapper
[
https://issues.apache.org/jira/browse/PHOENIX-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xinyi Yan resolved PHOENIX-6302.
Resolution: Fixed
Thanks for the patch [~vjasani]!
> Fix ConcurrentUpsertsWithoutIndexedColsIT flapper
> -
>
> Key: PHOENIX-6302
> URL: https://issues.apache.org/jira/browse/PHOENIX-6302
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Viraj Jasani
>Assignee: Viraj Jasani
>Priority: Major
> Fix For: 5.1.0, 4.16.0
>
>
> ConcurrentUpsertsWithoutIndexedColsIT.testConcurrentUpsertsWithoutIndexedColumns
> is failing some times.
> Logs:
> {code:java}
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.phoenix.end2end.ConcurrentMutationsExtendedIT.verifyIndexTable(ConcurrentMutationsExtendedIT.java:95)
> {code}
> e.g
> [build|https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-mulitbranch/job/master/176/testReport/org.apache.phoenix.end2end/ConcurrentUpsertsWithoutIndexedColsIT/MatrixBuild___Matrix___HBASE_PROFILE2_2BuildAndTest___testConcurrentUpsertsWithoutIndexedColumns/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6303) bump Scala version for spark connector to 2.11.12, the same that Spark 2.4.7 uses
[ https://issues.apache.org/jira/browse/PHOENIX-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6303: - Summary: bump Scala version for spark connector to 2.11.12, the same that Spark 2.4.7 uses (was: bump Scala version for spark connector to 2.11.12, the same as Spark 2.4.7 uses) > bump Scala version for spark connector to 2.11.12, the same that Spark 2.4.7 > uses > - > > Key: PHOENIX-6303 > URL: https://issues.apache.org/jira/browse/PHOENIX-6303 > Project: Phoenix > Issue Type: Improvement > Components: connectors, spark-connector >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-6303) bump Scala version for spark connector to 2.11.12, the same as Spark 2.4.7 uses
[ https://issues.apache.org/jira/browse/PHOENIX-6303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth reassigned PHOENIX-6303: Assignee: Istvan Toth > bump Scala version for spark connector to 2.11.12, the same as Spark 2.4.7 > uses > --- > > Key: PHOENIX-6303 > URL: https://issues.apache.org/jira/browse/PHOENIX-6303 > Project: Phoenix > Issue Type: Improvement > Components: connectors, spark-connector >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-6303) bump Scala version for spark connector to 2.11.12, the same as Spark 2.4.7 uses
Istvan Toth created PHOENIX-6303: Summary: bump Scala version for spark connector to 2.11.12, the same as Spark 2.4.7 uses Key: PHOENIX-6303 URL: https://issues.apache.org/jira/browse/PHOENIX-6303 Project: Phoenix Issue Type: Improvement Components: connectors, spark-connector Reporter: Istvan Toth -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-3710) Cannot use lowername data table name with indextool
[
https://issues.apache.org/jira/browse/PHOENIX-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-3710:
-
Affects Version/s: 5.1.0
> Cannot use lowername data table name with indextool
> ---
>
> Key: PHOENIX-3710
> URL: https://issues.apache.org/jira/browse/PHOENIX-3710
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0, 5.1.0
>Reporter: Matthew Shipton
>Assignee: Istvan Toth
>Priority: Minor
> Attachments: PHOENIX-3710.002.patch, PHOENIX-3710.002.rebased.patch,
> PHOENIX-3710.patch, test.sh, test.sql
>
>
> {code}
> hbase org.apache.phoenix.mapreduce.index.IndexTool --data-table
> \"my_lowcase_table\" --index-table INDEX_TABLE --output-path /tmp/some_path
> {code}
> results in:
> {code}
> java.lang.IllegalArgumentException: INDEX_TABLE is not an index table for
> MY_LOWCASE_TABLE
> {code}
> This is despite the data table being explictly lowercased.
> Appears to be referring to the lowcase table, not the uppercase version.
> Workaround exists by changing the tablename, but this is not always feasible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (PHOENIX-3710) Cannot use lowername data table name with indextool
[
https://issues.apache.org/jira/browse/PHOENIX-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth reassigned PHOENIX-3710:
Assignee: Istvan Toth (was: Josh Elser)
> Cannot use lowername data table name with indextool
> ---
>
> Key: PHOENIX-3710
> URL: https://issues.apache.org/jira/browse/PHOENIX-3710
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.8.0
>Reporter: Matthew Shipton
>Assignee: Istvan Toth
>Priority: Minor
> Attachments: PHOENIX-3710.002.patch, PHOENIX-3710.002.rebased.patch,
> PHOENIX-3710.patch, test.sh, test.sql
>
>
> {code}
> hbase org.apache.phoenix.mapreduce.index.IndexTool --data-table
> \"my_lowcase_table\" --index-table INDEX_TABLE --output-path /tmp/some_path
> {code}
> results in:
> {code}
> java.lang.IllegalArgumentException: INDEX_TABLE is not an index table for
> MY_LOWCASE_TABLE
> {code}
> This is despite the data table being explictly lowercased.
> Appears to be referring to the lowcase table, not the uppercase version.
> Workaround exists by changing the tablename, but this is not always feasible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (PHOENIX-5834) IndexTool cannot support tablename lowercase
[
https://issues.apache.org/jira/browse/PHOENIX-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth resolved PHOENIX-5834.
--
Resolution: Duplicate
> IndexTool cannot support tablename lowercase
> -
>
> Key: PHOENIX-5834
> URL: https://issues.apache.org/jira/browse/PHOENIX-5834
> Project: Phoenix
> Issue Type: Bug
> Components: core
>Affects Versions: 5.0.0
>Reporter: shining
>Priority: Major
>
> 1. Create table in hbase
>>> create 'ns:phoenix01','info'
>>> put 'ns:phoenix1','row001','info:id',''
>>> put 'ns:phoenix1','row001','info:name','manager'
> 2. Create table and async index in phoenix
> >> create schema "ns"
> >> create table "ns"."phoenix01"(ROW varchar primary key, "info"."id"
> varchar, "info"."name" varchar)column_encoded_bytes=0;
>>> create index "phoenix01_index" on "ns"."phoenix01"("info"."name") ASYNC;
> 3. Use IndexTool build index
>hbase org.apache.phoenix.mapreduce.index.IndexTool -s "ns" -dt "phoenix01"
> -it "phoenix01_index" -op /indextest
> Then i get nothing and return directly.
> I check the code and find the error position:
> {code:java}
> private boolean isValidIndexTable(final Connection connection, final String
> masterTable,
> final String indexTable) throws SQLException {
> final DatabaseMetaData dbMetaData = connection.getMetaData();
> final String schemaName =
> SchemaUtil.getSchemaNameFromFullName(masterTable);
> final String tableName =
> SchemaUtil.normalizeIdentifier(SchemaUtil.getTableNameFromFullName(masterTable));
> ResultSet rs = null;
> try {
> rs = dbMetaData.getIndexInfo(null, schemaName, tableName, false,
> false);
> while (rs.next()) {
> final String indexName = rs.getString(6);
> if (indexTable.equalsIgnoreCase(indexName)) {
> return true;
> }
> }
> } finally {
> if (rs != null) {
> rs.close();
> }
> }
> return false;
> }
> {code}
> I give the lowcase tablename,but indexTool change it uppercase,the
> validIndexTable get null.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6302) Fix ConcurrentUpsertsWithoutIndexedColsIT flapper
[
https://issues.apache.org/jira/browse/PHOENIX-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-6302:
--
Fix Version/s: 4.16.0
5.1.0
> Fix ConcurrentUpsertsWithoutIndexedColsIT flapper
> -
>
> Key: PHOENIX-6302
> URL: https://issues.apache.org/jira/browse/PHOENIX-6302
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Viraj Jasani
>Assignee: Viraj Jasani
>Priority: Major
> Fix For: 5.1.0, 4.16.0
>
>
> ConcurrentUpsertsWithoutIndexedColsIT.testConcurrentUpsertsWithoutIndexedColumns
> is failing some times.
> Logs:
> {code:java}
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.phoenix.end2end.ConcurrentMutationsExtendedIT.verifyIndexTable(ConcurrentMutationsExtendedIT.java:95)
> {code}
> e.g
> [build|https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-mulitbranch/job/master/176/testReport/org.apache.phoenix.end2end/ConcurrentUpsertsWithoutIndexedColsIT/MatrixBuild___Matrix___HBASE_PROFILE2_2BuildAndTest___testConcurrentUpsertsWithoutIndexedColumns/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6302) Fix ConcurrentUpsertsWithoutIndexedColsIT flapper
[
https://issues.apache.org/jira/browse/PHOENIX-6302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-6302:
--
Affects Version/s: 5.0.0
4.15.0
> Fix ConcurrentUpsertsWithoutIndexedColsIT flapper
> -
>
> Key: PHOENIX-6302
> URL: https://issues.apache.org/jira/browse/PHOENIX-6302
> Project: Phoenix
> Issue Type: Test
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Viraj Jasani
>Assignee: Viraj Jasani
>Priority: Major
>
> ConcurrentUpsertsWithoutIndexedColsIT.testConcurrentUpsertsWithoutIndexedColumns
> is failing some times.
> Logs:
> {code:java}
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.phoenix.end2end.ConcurrentMutationsExtendedIT.verifyIndexTable(ConcurrentMutationsExtendedIT.java:95)
> {code}
> e.g
> [build|https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-mulitbranch/job/master/176/testReport/org.apache.phoenix.end2end/ConcurrentUpsertsWithoutIndexedColsIT/MatrixBuild___Matrix___HBASE_PROFILE2_2BuildAndTest___testConcurrentUpsertsWithoutIndexedColumns/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-6302) Fix ConcurrentUpsertsWithoutIndexedColsIT flapper
Viraj Jasani created PHOENIX-6302:
-
Summary: Fix ConcurrentUpsertsWithoutIndexedColsIT flapper
Key: PHOENIX-6302
URL: https://issues.apache.org/jira/browse/PHOENIX-6302
Project: Phoenix
Issue Type: Test
Reporter: Viraj Jasani
Assignee: Viraj Jasani
ConcurrentUpsertsWithoutIndexedColsIT.testConcurrentUpsertsWithoutIndexedColumns
is failing some times.
Logs:
{code:java}
java.lang.AssertionError: expected:<0> but was:<1>
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:633)
at
org.apache.phoenix.end2end.ConcurrentMutationsExtendedIT.verifyIndexTable(ConcurrentMutationsExtendedIT.java:95)
{code}
e.g
[build|https://ci-hadoop.apache.org/job/Phoenix/job/Phoenix-mulitbranch/job/master/176/testReport/org.apache.phoenix.end2end/ConcurrentUpsertsWithoutIndexedColsIT/MatrixBuild___Matrix___HBASE_PROFILE2_2BuildAndTest___testConcurrentUpsertsWithoutIndexedColumns/]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6215) Failed to create local index if I set column type is tinyint with default value
[
https://issues.apache.org/jira/browse/PHOENIX-6215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
张嘉昊 updated PHOENIX-6215:
-
Description: Is this error caused by the way phoenix splits fields for
different types? If not , can you briefly describe the reason, thanks (was:
this is my sql:
{code:java}
//代码占位符
CREATE TABLE TEST4PHOENIX.MYTEST (
tag_id varchar(200) not null,
user_id varchar(200) not null ,
tag_name varchar(200) null,
is_delete tinyint default 0,
CONSTRAINT pk PRIMARY KEY (tag_id, user_id) ) SALT_BUCKETS = 10 ;
upsert into TEST4PHOENIX.MYTEST values('LB_001', '10077110', 'test', 0);
upsert into TEST4PHOENIX.MYTEST values('LB_002', '10077110', 'test', 1);
create local index MYTEST_INDEX on TEST4PHOENIX.MYTEST("TAG_NAME",
"IS_DELETE");{code}
I set column `is_delete` default 0.
After I create a local index, I don't know if this is a bug, I find this below.
select * from TEST4PHOENIX.MYTEST;
||TAG_ID||USER_ID||TAG_NAME||IS_DELETE||
|LB_001|10077110| test|0|
|LB_002|10077110| test|1|
select * from TEST4PHOENIX.MYTEST_INDEX;
||0:TAG_NAME||0:IS_DELETE||:TAG_ID||:USER_ID||
|test|0| |LB_00210077110|
|test|0| |LB_00210077110|
First, `is_delete` has 2 different values, but `MYTEST_INDEX` only shows 0,
which is default value;
Second, we can find that in `MYTEST_INDEX` column ''TAG_ID" and "USER_ID"
values have been changed. If query sql uses index, then we may return wrong
data. *While column value in `MYTEST` is right*
Actually after I tried many times, I found that if I create a local index ,
including a column which may be `tinyint` or `integer` and has been set a
dafault value, then the data in the index table will be wrong.
Is this a bug or I make a mistake?
)
Environment: (was: phoenix-5.0.0-cdh6.2.0)
> Failed to create local index if I set column type is tinyint with default
> value
>
>
> Key: PHOENIX-6215
> URL: https://issues.apache.org/jira/browse/PHOENIX-6215
> Project: Phoenix
> Issue Type: Bug
> Components: core
>Affects Versions: 5.0.0
>Reporter: 张嘉昊
>Assignee: Chao Wang
>Priority: Major
> Attachments: image-2020-11-05-17-32-00-661.png
>
>
> Is this error caused by the way phoenix splits fields for different types? If
> not , can you briefly describe the reason, thanks
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6297) Fix IndexMetadataIT.testAsyncRebuildAll test flapper
[
https://issues.apache.org/jira/browse/PHOENIX-6297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xinyi Yan updated PHOENIX-6297:
---
Attachment: PHOENIX-6297.master.v3.patch
> Fix IndexMetadataIT.testAsyncRebuildAll test flapper
>
>
> Key: PHOENIX-6297
> URL: https://issues.apache.org/jira/browse/PHOENIX-6297
> Project: Phoenix
> Issue Type: Test
>Reporter: Xinyi Yan
>Assignee: Xinyi Yan
>Priority: Major
> Fix For: 5.1.0, 4.16.0
>
> Attachments: PHOENIX-6297.4.x.patch, PHOENIX-6297.4.x.v3.patch,
> PHOENIX-6297.master.patch, PHOENIX-6297.master.v3.patch
>
>
> Based on the Jenkins log, we need to fix it before the 4.16 release.
> {code:java}
> Error Messageexpected:<[COMPLE]TED> but
> was:<[STAR]TED>Stacktraceorg.junit.ComparisonFailure: expected:<[COMPLE]TED>
> but was:<[STAR]TED>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.phoenix.end2end.DropTableWithViewsIT.assertTaskColumns(DropTableWithViewsIT.java:184)
> at
> org.apache.phoenix.end2end.index.IndexMetadataIT.testAsyncRebuildAll(IndexMetadataIT.java:691)
> {code}
>
> {code:java}
> Error MessageRan out of time waiting for index state to become ACTIVE last
> seen actual state is BUILDINGStacktracejava.lang.AssertionError: Ran out of
> time waiting for index state to become ACTIVE last seen actual state is
> BUILDING
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.phoenix.util.TestUtil.waitForIndexState(TestUtil.java:1081)
> at
> org.apache.phoenix.end2end.index.IndexMetadataIT.testAsyncRebuildAll(IndexMetadataIT.java:688)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6297) Fix IndexMetadataIT.testAsyncRebuildAll test flapper
[
https://issues.apache.org/jira/browse/PHOENIX-6297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xinyi Yan updated PHOENIX-6297:
---
Attachment: PHOENIX-6297.4.x.v3.patch
> Fix IndexMetadataIT.testAsyncRebuildAll test flapper
>
>
> Key: PHOENIX-6297
> URL: https://issues.apache.org/jira/browse/PHOENIX-6297
> Project: Phoenix
> Issue Type: Test
>Reporter: Xinyi Yan
>Assignee: Xinyi Yan
>Priority: Major
> Fix For: 5.1.0, 4.16.0
>
> Attachments: PHOENIX-6297.4.x.patch, PHOENIX-6297.4.x.v3.patch,
> PHOENIX-6297.master.patch
>
>
> Based on the Jenkins log, we need to fix it before the 4.16 release.
> {code:java}
> Error Messageexpected:<[COMPLE]TED> but
> was:<[STAR]TED>Stacktraceorg.junit.ComparisonFailure: expected:<[COMPLE]TED>
> but was:<[STAR]TED>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.phoenix.end2end.DropTableWithViewsIT.assertTaskColumns(DropTableWithViewsIT.java:184)
> at
> org.apache.phoenix.end2end.index.IndexMetadataIT.testAsyncRebuildAll(IndexMetadataIT.java:691)
> {code}
>
> {code:java}
> Error MessageRan out of time waiting for index state to become ACTIVE last
> seen actual state is BUILDINGStacktracejava.lang.AssertionError: Ran out of
> time waiting for index state to become ACTIVE last seen actual state is
> BUILDING
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.phoenix.util.TestUtil.waitForIndexState(TestUtil.java:1081)
> at
> org.apache.phoenix.end2end.index.IndexMetadataIT.testAsyncRebuildAll(IndexMetadataIT.java:688)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-3633) null pointer exception when subsquery for not exists returns empty result set
[ https://issues.apache.org/jira/browse/PHOENIX-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-3633: - Affects Version/s: 5.1.0 > null pointer exception when subsquery for not exists returns empty result set > - > > Key: PHOENIX-3633 > URL: https://issues.apache.org/jira/browse/PHOENIX-3633 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.7.0, 5.1.0 >Reporter: N Campbell >Assignee: Istvan Toth >Priority: Major > Attachments: PHOENIX-3633.patch > > > phoenix-4.7.0.2.5.3.0-37-client > select RNUM, C1, C2 from TJOIN2 where not exists ( select C1 from TJOIN1 > where C2=500) > Error while executing SQL "select RNUM, C1, C2 from TJOIN2 where not exists ( > select C1 from TJOIN1 where C2=500)": Remote driver error: > NullPointerException: (null exception message) > create table if not exists TJOIN1 (RNUM integer not null primary key , C1 > integer, C2 integer); > upsert into TJOIN1 (RNUM, C1, C2) values ( 0, 10, 15); > upsert into TJOIN1 (RNUM, C1, C2) values ( 1, 20, 25); > upsert into TJOIN1 (RNUM, C1, C2) values ( 2, NULL, 50); > create table if not exists TJOIN2 (RNUM integer not null primary key , C1 > integer, C2 char(2)); > upsert into TJOIN2 (RNUM, C1, C2) values ( 0, 10, 'BB'); > upsert into TJOIN2 (RNUM, C1, C2) values ( 1, 15, 'DD'); > upsert into TJOIN2 (RNUM, C1, C2) values ( 2, NULL, 'EE'); > upsert into TJOIN2 (RNUM, C1, C2) values ( 3, 10, 'FF'); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-3633) null pointer exception when subsquery for not exists returns empty result set
[ https://issues.apache.org/jira/browse/PHOENIX-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth reassigned PHOENIX-3633: Assignee: Istvan Toth (was: Jerry He) > null pointer exception when subsquery for not exists returns empty result set > - > > Key: PHOENIX-3633 > URL: https://issues.apache.org/jira/browse/PHOENIX-3633 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.7.0 >Reporter: N Campbell >Assignee: Istvan Toth >Priority: Major > Attachments: PHOENIX-3633.patch > > > phoenix-4.7.0.2.5.3.0-37-client > select RNUM, C1, C2 from TJOIN2 where not exists ( select C1 from TJOIN1 > where C2=500) > Error while executing SQL "select RNUM, C1, C2 from TJOIN2 where not exists ( > select C1 from TJOIN1 where C2=500)": Remote driver error: > NullPointerException: (null exception message) > create table if not exists TJOIN1 (RNUM integer not null primary key , C1 > integer, C2 integer); > upsert into TJOIN1 (RNUM, C1, C2) values ( 0, 10, 15); > upsert into TJOIN1 (RNUM, C1, C2) values ( 1, 20, 25); > upsert into TJOIN1 (RNUM, C1, C2) values ( 2, NULL, 50); > create table if not exists TJOIN2 (RNUM integer not null primary key , C1 > integer, C2 char(2)); > upsert into TJOIN2 (RNUM, C1, C2) values ( 0, 10, 'BB'); > upsert into TJOIN2 (RNUM, C1, C2) values ( 1, 15, 'DD'); > upsert into TJOIN2 (RNUM, C1, C2) values ( 2, NULL, 'EE'); > upsert into TJOIN2 (RNUM, C1, C2) values ( 3, 10, 'FF'); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (PHOENIX-3499) Enable null value for quote character for CSVBulkLoad tool
[ https://issues.apache.org/jira/browse/PHOENIX-3499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth reassigned PHOENIX-3499: Assignee: Istvan Toth (was: Sergey Soldatov) > Enable null value for quote character for CSVBulkLoad tool > -- > > Key: PHOENIX-3499 > URL: https://issues.apache.org/jira/browse/PHOENIX-3499 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.7.0, 4.8.0 >Reporter: Sergey Soldatov >Assignee: Istvan Toth >Priority: Major > Attachments: PHOENIX-3499-1.patch > > > It's quite often that CSV data contains '"' character as part of the user > data. At the moment user has to replace quote character with something that > is not used in the data. More convenient if we allow to set it to null (using > empty character). -- This message was sent by Atlassian Jira (v8.3.4#803005)
