Re: [VOTE] Release of Apache Phoenix 4.14.2 RC1
+1 Jaanai Zhang Best regards! Thomas D'Silva 于2019年5月18日周六 下午3:38写道： > Hello Everyone, > > This is a call for a vote on Apache Phoenix 4.14.2 RC1. This is a patch > release of Phoenix 4.14 and is compatible with Apache HBase 1.3 and 1.4. > The release includes both a source-only release and a convenience binary > release for each supported HBase version. > > This release has feature parity with supported HBase versions and includes > several critical bug fixes. > > The source tarball, including signatures, digests, etc can be found at: > > https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.3-rc1/src/ > > https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.4-rc1/src/ > > The binary artifacts can be found at: > > https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.3-rc1/bin/ > > https://dist.apache.org/repos/dist/dev/phoenix/apache-phoenix-4.14.2-HBase-1.4-rc1/bin/ > > For a complete list of changes, see: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12315120=12344379 > > Artifacts are signed with my "CODE SIGNING KEY": DFD86C02 > > KEYS file available here: > https://dist.apache.org/repos/dist/dev/phoenix/KEYS > > The hash and tag to be voted upon: > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=e3505d91e46de1a1756a145d396f27a3c70e927f > > https://git-wip-us.apache.org/repos/asf?p=phoenix.git;a=commit;h=4b717825fb284c1f9fbdeee3d0e5391f5baf13bb > > > Vote will be open for at least 72 hours. Please vote: > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Thanks, > The Apache Phoenix Team >
Re: [DISCUSS] Making a 5.0.1 RC for bug fixes
Thanks, Thomas. It works for me now. Jaanai Zhang Best regards! Thomas D'Silva 于2019年5月17日周五 上午3:24写道： > Jaanai, > > I added you to the JIRA administrators role, so you should be able to do > think now. Please let us know if it doesn't work. > > Thanks, > Thomas > > On Mon, May 13, 2019 at 6:22 PM Jaanai Zhang > wrote: > > > Could you please help me add a 5.0.1 version > > > > > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=58=PHOENIX=planning.nodetail=visible=visible > > , > > it seems that I don't have the authority. Josh, Thomas > > > >Jaanai Zhang > >Best regards! > > > > > > > > > > Josh Elser 于2019年5月13日周一 下午10:54写道： > > > > > How did you identify the below issues? > > > > > > As I said in the other thread, I think we should move to the latest, > > > working HBase release for a 5.0.1 (which is 2.0.3 AFAIK). > > > > > > On 5/13/19 9:07 AM, Jaanai Zhang wrote: > > > > Hi, folks > > > > We decided to release a 5.0.1 that is discussed in the thread[1] and > > > > thread[2]. > > > > > > > > Since there is a lot of work to make Phoenix compatible with the > newer > > > > HBase 2.0.x(especially contains HBASE-21401), > > > > we try to fix HBase compat in a 5.1.0 version. In 5.0.1 we might > keep > > > the > > > > current HBase version? Josh, Thomas > > > > > > > > Right now I find the following issues, Is there anything else that > > needs > > > > to add to this release? > > > > > > > > *Bug* > > > > > > > > <https://issues.apache.org/jira/browse/PHOENIX-5266> > > > > > > > > PHOENIX-5266 <https://issues.apache.org/jira/browse/PHOENIX-5266> > > Client > > > > can only write on Index Table and skip data table if failure happens > > > > because of region split/move etc > > > > > > > > PHOENIX-5132 <https://issues.apache.org/jira/browse/PHOENIX-5132> > View > > > > indexes with different owners but of the same base table can be > > assigned > > > > same ViewIndexId > > > > > > > > PHOENIX-5138 <https://issues.apache.org/jira/browse/PHOENIX-5138> > > > ViewIndexId > > > > sequences created after PHOENIX-5132 shouldn't collide with ones > > created > > > > before it > > > > > > > > PHOENIX-4759 <https://issues.apache.org/jira/browse/PHOENIX-4759> > > During > > > > restart RS that hosts SYSTEM.CATALOG table may get stuck > > > > > > > > PHOENIX-5055 <https://issues.apache.org/jira/browse/PHOENIX-5055> > > Split > > > > mutations batches probably affects correctness of index data > > > > > > > > PHOENIX-5226 <https://issues.apache.org/jira/browse/PHOENIX-5226> > The > > > > format of VIEW_MODIFIED_PROPERTY_BYTES is incorrect as a tag of the > > cell > > > > > > > > PHOENIX-5018 <https://issues.apache.org/jira/browse/PHOENIX-5018> > > Index > > > > mutations created by UPSERT SELECT will have wrong timestamps > > > > > > > > PHOENIX-5019 <https://issues.apache.org/jira/browse/PHOENIX-5019> > > Index > > > > mutations created by synchronous index builds will have wrong > > timestamps > > > > > > > > PHOENIX-5169 <https://issues.apache.org/jira/browse/PHOENIX-5169> > > Query > > > > logger is still initialized for each query when the log level is off > > > > > > > > PHOENIX-5188 <https://issues.apache.org/jira/browse/PHOENIX-5188> > > > > IndexedKeyValue > > > > should populate KeyValue fields > > > > > > > > PHOENIX-5094 <https://issues.apache.org/jira/browse/PHOENIX-5094> > > Index > > > > can transition from INACTIVE to ACTIVE via Phoenix Client > > > > > > > > PHOENIX-5217 <https://issues.apache.org/jira/browse/PHOENIX-5217> > > > Incorrect > > > > result for COUNT DISTINCT limit > > > > > > > > PHOENIX-5184 <https://issues.apache.org/jira/browse/PHOENIX-5184> > > HBase > > > and > > > > Phoenix connection leaks in Indexing code path, OrphanViewTool and > > > > PhoenixConfigurationUtil > > > > > >
Re: [DISCUSS] Making a 5.0.1 RC for bug fixes
Could you please help me add a 5.0.1 version https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=58=PHOENIX=planning.nodetail=visible=visible , it seems that I don't have the authority. Josh, Thomas Jaanai Zhang Best regards! Josh Elser 于2019年5月13日周一 下午10:54写道： > How did you identify the below issues? > > As I said in the other thread, I think we should move to the latest, > working HBase release for a 5.0.1 (which is 2.0.3 AFAIK). > > On 5/13/19 9:07 AM, Jaanai Zhang wrote: > > Hi, folks > > We decided to release a 5.0.1 that is discussed in the thread[1] and > > thread[2]. > > > > Since there is a lot of work to make Phoenix compatible with the newer > > HBase 2.0.x(especially contains HBASE-21401), > > we try to fix HBase compat in a 5.1.0 version. In 5.0.1 we might keep > the > > current HBase version? Josh, Thomas > > > > Right now I find the following issues, Is there anything else that needs > > to add to this release? > > > > *Bug* > > > > <https://issues.apache.org/jira/browse/PHOENIX-5266> > > > > PHOENIX-5266 <https://issues.apache.org/jira/browse/PHOENIX-5266> Client > > can only write on Index Table and skip data table if failure happens > > because of region split/move etc > > > > PHOENIX-5132 <https://issues.apache.org/jira/browse/PHOENIX-5132> View > > indexes with different owners but of the same base table can be assigned > > same ViewIndexId > > > > PHOENIX-5138 <https://issues.apache.org/jira/browse/PHOENIX-5138> > ViewIndexId > > sequences created after PHOENIX-5132 shouldn't collide with ones created > > before it > > > > PHOENIX-4759 <https://issues.apache.org/jira/browse/PHOENIX-4759> During > > restart RS that hosts SYSTEM.CATALOG table may get stuck > > > > PHOENIX-5055 <https://issues.apache.org/jira/browse/PHOENIX-5055> Split > > mutations batches probably affects correctness of index data > > > > PHOENIX-5226 <https://issues.apache.org/jira/browse/PHOENIX-5226> The > > format of VIEW_MODIFIED_PROPERTY_BYTES is incorrect as a tag of the cell > > > > PHOENIX-5018 <https://issues.apache.org/jira/browse/PHOENIX-5018> Index > > mutations created by UPSERT SELECT will have wrong timestamps > > > > PHOENIX-5019 <https://issues.apache.org/jira/browse/PHOENIX-5019> Index > > mutations created by synchronous index builds will have wrong timestamps > > > > PHOENIX-5169 <https://issues.apache.org/jira/browse/PHOENIX-5169> Query > > logger is still initialized for each query when the log level is off > > > > PHOENIX-5188 <https://issues.apache.org/jira/browse/PHOENIX-5188> > > IndexedKeyValue > > should populate KeyValue fields > > > > PHOENIX-5094 <https://issues.apache.org/jira/browse/PHOENIX-5094> Index > > can transition from INACTIVE to ACTIVE via Phoenix Client > > > > PHOENIX-5217 <https://issues.apache.org/jira/browse/PHOENIX-5217> > Incorrect > > result for COUNT DISTINCT limit > > > > PHOENIX-5184 <https://issues.apache.org/jira/browse/PHOENIX-5184> HBase > and > > Phoenix connection leaks in Indexing code path, OrphanViewTool and > > PhoenixConfigurationUtil > > > > PHOENIX-5207 <https://issues.apache.org/jira/browse/PHOENIX-5207> > Create > > index if not exists fails incorrectly if table has 'maxIndexesPerTable' > > indexes already > > > > PHOENIX-5126 <https://issues.apache.org/jira/browse/PHOENIX-5126> > RegionScanner > > leak leading to store files not getting cleared > > > > PHOENIX-5122 <https://issues.apache.org/jira/browse/PHOENIX-5122> > PHOENIX-4322 > > breaks client backward compatibility > > > > PHOENIX-5101 <https://issues.apache.org/jira/browse/PHOENIX-5101> > > ScanningResultIterator > > getScanMetrics throws NPE > > > > > > > > > > *Improvement* > > > > PHOENIX-5213 <https://issues.apache.org/jira/browse/PHOENIX-5213> > > Phoenix-client > > improvements: add more relocations, exclude log binding, add source jar > > > > PHOENIX-5048 <https://issues.apache.org/jira/browse/PHOENIX-5048> Index > > Rebuilder does not handle INDEX_STATE timestamp check for all index > > > > PHOENIX-4907 <https://issues.apache.org/jira/browse/PHOENIX-4907> > > IndexScrutinyTool > > should use empty catalog instead of null > > > > PHOENIX-5131 <https://issues.apache.org/jira/browse/PHOENIX
Re: [DISCUSS] Next Phoenix 5.x release (was "Board report due in ~1 week")
So we can keep the current HBase version in 5.0.1? Jaanai Zhang Best regards! Jaanai Zhang 于2019年5月13日周一 下午8:22写道： > +1 > > ---- >Jaanai Zhang >Best regards! > > > > Thomas D'Silva 于2019年5月10日周五 下午1:25写道： > >> +1 to this approach. >> >> On Thu, May 9, 2019 at 9:22 AM Josh Elser wrote: >> >> > After working on trying to make Phoenix compatible with >=HBase 2.0.4, >> > I'm wondering if it would just be good to get 5.0.1 out the door and try >> > to fix HBase compat in a 5.1.0, acknowledging that we don't work with >> > the newer 2.0.x HBase versions (really, anything that contains >> > HBASE-21401[1]). >> > >> > I feel like it's much less risky to just acknowledge that we're limited >> > in target HBase version for a bug-fix release. >> > >> > What do folks think? That would lessen the burden on you, Jaanai. >> > >> > [1] https://issues.apache.org/jira/browse/HBASE-21401 >> > >> > On 5/1/19 5:35 PM, Josh Elser wrote: >> > > I think it would be better to figure out if there is anything >> currently >> > > on master that _shouldn't_ be included in a 5.0.1. My guess would be >> > > "no". It feels like branching for the sake of branching to keep 5.0.1 >> > > and 5.1.0 distinct. >> > > >> > > On 5/1/19 12:38 AM, Thomas D'Silva wrote:> Should we use 2.0.5 ( the >> > > latest released HBase version )? If PHOENIX-5250 >> > > > <https://issues.apache.org/jira/browse/PHOENIX-5250> is a blocker >> > we >> > > will >> > > > need to fix it before we can release 5.0.1 (or 5.1). >> > > > >> > > > These are the list of bugs that have a fix version of 5.1 : >> > > > >> > > >> > >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20fixVersion%20%3D%205.1.0%20AND%20issuetype%20%20%3D%20Bug >> > > >> > > > We should figure out which of these we want to cherrypick for the >> > 5.0.1 >> > > > release. >> > > >> > > On 4/30/19 10:39 AM, Josh Elser wrote: >> > >> Let's leave the other thread for the board report, please. I've >> > >> changed the subject as such. >> > >> >> > >> Thanks for volunteering to be RM. >> > >> >> > >> I'm of the opinion that we should just update to the latest HBase >> > >> 2.0.x line. The compatibility assertions from HBase should make this >> a >> > >> no-op for us to change versions. There are arguments, however, in >> both >> > >> ways that we should use the earliest, non-breaking version of HBase. >> > >> >> > >> As the RM, it is your prerogative to tell everyone else how you are >> > >> tracking it :). Figure out what fixVersion you're using on Jira, and >> > >> then either manage the list of open issues in there yourself, or push >> > >> out issues and have folks put issues back in which they feel must be >> > >> included. >> > >> >> > >> Since this is your first time, I would prioritize an rc0 ASAP so that >> > >> you can get comfortable with the process (even if we know that there >> > >> are other fixes which must be made before the final release). >> > >> >> > >> On 4/30/19 2:34 AM, Jaanai Zhang wrote: >> > >>> I will try doing release 5.0.1. Tow things need to confirm: >> > >>> >> > >>> 1. According to the thread[1], a new Phoenix 5.0.1 will support >> HBase >> > >>> 2.0.2, right? As far as I know, some improvements of HBase 2.0.2 >> will >> > >>> cause >> > >>> some critical issues, for example, >> > >>> https://issues.apache.org/jira/browse/PHOENIX-5250 (This issue from >> > our >> > >>> production environments, we had used HBase 2.0.2 in Phoenix 5.0). >> > >>> >> > >>> 2. We should have a clear JIRA list for a 5.0.1, I am not sure what >> > >>> JIRAs >> > >>> should go into it, only critical and blocked JIRAs apply for a >> 5.0.1? >> > >>> If I >> > >>> know what priority need to pick, I will collect them. >> > >>> >> > >>> >> > >
[DISCUSS] Making a 5.0.1 RC for bug fixes
Hi, folks We decided to release a 5.0.1 that is discussed in the thread[1] and thread[2]. Since there is a lot of work to make Phoenix compatible with the newer HBase 2.0.x(especially contains HBASE-21401), we try to fix HBase compat in a 5.1.0 version. In 5.0.1 we might keep the current HBase version? Josh, Thomas Right now I find the following issues, Is there anything else that needs to add to this release? *Bug* <https://issues.apache.org/jira/browse/PHOENIX-5266> PHOENIX-5266 <https://issues.apache.org/jira/browse/PHOENIX-5266> Client can only write on Index Table and skip data table if failure happens because of region split/move etc PHOENIX-5132 <https://issues.apache.org/jira/browse/PHOENIX-5132> View indexes with different owners but of the same base table can be assigned same ViewIndexId PHOENIX-5138 <https://issues.apache.org/jira/browse/PHOENIX-5138> ViewIndexId sequences created after PHOENIX-5132 shouldn't collide with ones created before it PHOENIX-4759 <https://issues.apache.org/jira/browse/PHOENIX-4759> During restart RS that hosts SYSTEM.CATALOG table may get stuck PHOENIX-5055 <https://issues.apache.org/jira/browse/PHOENIX-5055> Split mutations batches probably affects correctness of index data PHOENIX-5226 <https://issues.apache.org/jira/browse/PHOENIX-5226> The format of VIEW_MODIFIED_PROPERTY_BYTES is incorrect as a tag of the cell PHOENIX-5018 <https://issues.apache.org/jira/browse/PHOENIX-5018> Index mutations created by UPSERT SELECT will have wrong timestamps PHOENIX-5019 <https://issues.apache.org/jira/browse/PHOENIX-5019> Index mutations created by synchronous index builds will have wrong timestamps PHOENIX-5169 <https://issues.apache.org/jira/browse/PHOENIX-5169> Query logger is still initialized for each query when the log level is off PHOENIX-5188 <https://issues.apache.org/jira/browse/PHOENIX-5188> IndexedKeyValue should populate KeyValue fields PHOENIX-5094 <https://issues.apache.org/jira/browse/PHOENIX-5094> Index can transition from INACTIVE to ACTIVE via Phoenix Client PHOENIX-5217 <https://issues.apache.org/jira/browse/PHOENIX-5217> Incorrect result for COUNT DISTINCT limit PHOENIX-5184 <https://issues.apache.org/jira/browse/PHOENIX-5184> HBase and Phoenix connection leaks in Indexing code path, OrphanViewTool and PhoenixConfigurationUtil PHOENIX-5207 <https://issues.apache.org/jira/browse/PHOENIX-5207> Create index if not exists fails incorrectly if table has 'maxIndexesPerTable' indexes already PHOENIX-5126 <https://issues.apache.org/jira/browse/PHOENIX-5126> RegionScanner leak leading to store files not getting cleared PHOENIX-5122 <https://issues.apache.org/jira/browse/PHOENIX-5122> PHOENIX-4322 breaks client backward compatibility PHOENIX-5101 <https://issues.apache.org/jira/browse/PHOENIX-5101> ScanningResultIterator getScanMetrics throws NPE *Improvement* PHOENIX-5213 <https://issues.apache.org/jira/browse/PHOENIX-5213> Phoenix-client improvements: add more relocations, exclude log binding, add source jar PHOENIX-5048 <https://issues.apache.org/jira/browse/PHOENIX-5048> Index Rebuilder does not handle INDEX_STATE timestamp check for all index PHOENIX-4907 <https://issues.apache.org/jira/browse/PHOENIX-4907> IndexScrutinyTool should use empty catalog instead of null PHOENIX-5131 <https://issues.apache.org/jira/browse/PHOENIX-5131> Make spilling to disk for order/group by configurable PHOENIX-5069 <https://issues.apache.org/jira/browse/PHOENIX-5069> Use asynchronous refresh to provide non-blocking Phoenix Stats Client Cache PHOENIX-4900 <https://issues.apache.org/jira/browse/PHOENIX-4900> Modify MAX_MUTATION_SIZE_EXCEEDED and MAX_MUTATION_SIZE_BYTES_EXCEEDED exception message to recommend turning autocommit on for deletes [1] https://lists.apache.org/thread.html/99fcc737d7a8f82ddffb1b34a64f7099f7909900b8bea36dd6afca16@%3Cdev.phoenix.apache.org%3E [2] https://lists.apache.org/thread.html/f9d9965b76335f64695ac403e84dda01a2b8425a8eedc30e4a805d54@%3Cdev.phoenix.apache.org%3E Jaanai Zhang Best regards!
Re: [DISCUSS] Next Phoenix 5.x release (was "Board report due in ~1 week")
+1 Jaanai Zhang Best regards! Thomas D'Silva 于2019年5月10日周五 下午1:25写道： > +1 to this approach. > > On Thu, May 9, 2019 at 9:22 AM Josh Elser wrote: > > > After working on trying to make Phoenix compatible with >=HBase 2.0.4, > > I'm wondering if it would just be good to get 5.0.1 out the door and try > > to fix HBase compat in a 5.1.0, acknowledging that we don't work with > > the newer 2.0.x HBase versions (really, anything that contains > > HBASE-21401[1]). > > > > I feel like it's much less risky to just acknowledge that we're limited > > in target HBase version for a bug-fix release. > > > > What do folks think? That would lessen the burden on you, Jaanai. > > > > [1] https://issues.apache.org/jira/browse/HBASE-21401 > > > > On 5/1/19 5:35 PM, Josh Elser wrote: > > > I think it would be better to figure out if there is anything currently > > > on master that _shouldn't_ be included in a 5.0.1. My guess would be > > > "no". It feels like branching for the sake of branching to keep 5.0.1 > > > and 5.1.0 distinct. > > > > > > On 5/1/19 12:38 AM, Thomas D'Silva wrote:> Should we use 2.0.5 ( the > > > latest released HBase version )? If PHOENIX-5250 > > > > <https://issues.apache.org/jira/browse/PHOENIX-5250> is a blocker > > we > > > will > > > > need to fix it before we can release 5.0.1 (or 5.1). > > > > > > > > These are the list of bugs that have a fix version of 5.1 : > > > > > > > > > > https://issues.apache.org/jira/issues/?jql=project%20%3D%20PHOENIX%20AND%20fixVersion%20%3D%205.1.0%20AND%20issuetype%20%20%3D%20Bug > > > > > > > We should figure out which of these we want to cherrypick for the > > 5.0.1 > > > > release. > > > > > > On 4/30/19 10:39 AM, Josh Elser wrote: > > >> Let's leave the other thread for the board report, please. I've > > >> changed the subject as such. > > >> > > >> Thanks for volunteering to be RM. > > >> > > >> I'm of the opinion that we should just update to the latest HBase > > >> 2.0.x line. The compatibility assertions from HBase should make this a > > >> no-op for us to change versions. There are arguments, however, in both > > >> ways that we should use the earliest, non-breaking version of HBase. > > >> > > >> As the RM, it is your prerogative to tell everyone else how you are > > >> tracking it :). Figure out what fixVersion you're using on Jira, and > > >> then either manage the list of open issues in there yourself, or push > > >> out issues and have folks put issues back in which they feel must be > > >> included. > > >> > > >> Since this is your first time, I would prioritize an rc0 ASAP so that > > >> you can get comfortable with the process (even if we know that there > > >> are other fixes which must be made before the final release). > > >> > > >> On 4/30/19 2:34 AM, Jaanai Zhang wrote: > > >>> I will try doing release 5.0.1. Tow things need to confirm: > > >>> > > >>> 1. According to the thread[1], a new Phoenix 5.0.1 will support > HBase > > >>> 2.0.2, right? As far as I know, some improvements of HBase 2.0.2 will > > >>> cause > > >>> some critical issues, for example, > > >>> https://issues.apache.org/jira/browse/PHOENIX-5250 (This issue from > > our > > >>> production environments, we had used HBase 2.0.2 in Phoenix 5.0). > > >>> > > >>> 2. We should have a clear JIRA list for a 5.0.1, I am not sure what > > >>> JIRAs > > >>> should go into it, only critical and blocked JIRAs apply for a 5.0.1? > > >>> If I > > >>> know what priority need to pick, I will collect them. > > >>> > > >>> > > >>> > > >>> Jaanai Zhang > > >>> Best regards! > > >>> > > >>> > > >>> > > >>> Thomas D'Silva 于2019年4月30日周二 > > >>> 上 午10:06写道： > > >>> > > >>>> Jaanai, > > >>>> > > >>>> We are waiting for a few omid bug fixes to do the 4.15/5.1 release > > that > > >>>> will have splittable system catalog and the omid integration. > > &g
Re: [ANNOUNCE] New Phoenix committer: Mihir Monani
congrats! Mihir. Jaanai Zhang Best regards! Mihir Monani 于2019年4月30日周二 下午1:13写道： > Thanks Thomas and Apache Phoenix Community. :) > > On Sun, Apr 28, 2019 at 6:12 AM Thomas D'Silva wrote: > > > On behalf of the Apache Phoenix PMC, I am pleased to announce that > > Mihir Monani has accepted our invitation to become a committer. > > Mihir has done some nice work fixing several bugs related to indexing[1]. > > > > Please welcome him to the Apache Phoenix team. > > > > Thanks, > > Thomas > > > > [1] > > > > > https://issues.apache.org/jira/browse/PHOENIX-5199?jql=project%20%3D%20PHOENIX%20AND%20assignee%3D%22mihir6692%22%20AND%20status%3DResolved > > > > > -- > Mihir Monani > (+91)-9429473434 >
Re: Board report due in ~1 week
I will try doing release 5.0.1. Tow things need to confirm: 1. According to the thread[1], a new Phoenix 5.0.1 will support HBase 2.0.2, right? As far as I know, some improvements of HBase 2.0.2 will cause some critical issues, for example, https://issues.apache.org/jira/browse/PHOENIX-5250 (This issue from our production environments, we had used HBase 2.0.2 in Phoenix 5.0). 2. We should have a clear JIRA list for a 5.0.1, I am not sure what JIRAs should go into it, only critical and blocked JIRAs apply for a 5.0.1? If I know what priority need to pick, I will collect them. Jaanai Zhang Best regards! Thomas D'Silva 于2019年4月30日周二 上午10:06写道： > Jaanai, > > We are waiting for a few omid bug fixes to do the 4.15/5.1 release that > will have splittable system catalog and the omid integration. > Are you interested in doing a 5.0.1 release that has the HBase 2.0.x > compatibility fixes that were discussed in a previous thread[1]? > > The steps to create a RC are straightforward and documented here: > https://phoenix.apache.org/release.html. > The main thing you need to do is to add your code signing key to > https://dist.apache.org/repos/dist/dev/phoenix/KEYS (follow the steps at > the start of that file) > and then commit using svn. Then you can follow the rest of the steps listed > in "How to do a release" > > Thanks, > Thomas > > [1] > > https://lists.apache.org/thread.html/99fcc737d7a8f82ddffb1b34a64f7099f7909900b8bea36dd6afca16@%3Cdev.phoenix.apache.org%3E > > On Mon, Apr 29, 2019 at 6:33 PM Jaanai Zhang > wrote: > > > I would like to volunteer for a new 5.x release if someone can guide me > > release process. Thanks. > > > > > >Jaanai Zhang > >Best regards! > > > > > > > > Josh Elser 于2019年4月30日周二 上午12:39写道： > > > > > Hiya folks, > > > > > > It's about that time for another board report. Please reply here with > > > anything of merit that you think the board might find > > > interesting/useful. As a reminder, they board is typically more > > > concerned with high-level project/community details than the > > > nuts-and-bolts of the code changes for the project. > > > > > > On my radar already is... > > > > > > * Multiple new committers and PMC'ers (thanks so much to the folks who > > > have been driving votes!) > > > * NoSQL day in May > > > * 4.14.2 in vote > > > * Need for a new 5.x.y release (if there are no volunteers, I may have > > > to find the time to make this happen. It's been too long) > > > > > > Thanks! > > > > > > - Josh > > > > > >
Re: Board report due in ~1 week
I would like to volunteer for a new 5.x release if someone can guide me release process. Thanks. Jaanai Zhang Best regards! Josh Elser 于2019年4月30日周二 上午12:39写道： > Hiya folks, > > It's about that time for another board report. Please reply here with > anything of merit that you think the board might find > interesting/useful. As a reminder, they board is typically more > concerned with high-level project/community details than the > nuts-and-bolts of the code changes for the project. > > On my radar already is... > > * Multiple new committers and PMC'ers (thanks so much to the folks who > have been driving votes!) > * NoSQL day in May > * 4.14.2 in vote > * Need for a new 5.x.y release (if there are no volunteers, I may have > to find the time to make this happen. It's been too long) > > Thanks! > > - Josh >
Re: [ANNOUNCE] New Phoenix PMC member: Geoffrey Jacoby
Congratulations Geoffrey! Jaanai Zhang Best regards! Abhishek Singh Chouhan 于2019年4月10日周三 上午4:50写道： > Congrats Geoffrey!! > > On Tue, Apr 9, 2019 at 12:00 PM Chinmay Kulkarni < > chinmayskulka...@gmail.com> > wrote: > > > Congratulations Geoffrey! > > > > On Tue, Apr 9, 2019 at 11:51 AM Vincent Poon > > wrote: > > > > > Congrats Geoffrey! > > > > > > On Tue, Apr 9, 2019 at 11:42 AM Thomas D'Silva > > wrote: > > > > > > > On behalf of the Apache Phoenix PMC, I'm pleased to announce that > > > Geoffrey > > > > Jacoby has accepted our invitation to join the PMC. > > > > > > > > Please join me in congratulating Geoffrey. > > > > > > > > Thanks, > > > > Thomas > > > > > > > > > > > > > -- > > Chinmay Kulkarni > > M.S. Computer Science, > > University of Illinois at Urbana-Champaign. > > B. Tech Computer Engineering, > > College of Engineering, Pune. > > >
Re: [ANNOUNCE] New Phoenix PMC member: Cheng Lei
Congratulations Cheng! Jaanai Zhang Best regards! Geoffrey Jacoby 于2019年4月10日周三 上午5:03写道： > Congratulations, Cheng! > > On Tue, Apr 9, 2019 at 1:50 PM Abhishek Singh Chouhan < > abhishekchouhan...@gmail.com> wrote: > > > Congrats Cheng! > > > > On Tue, Apr 9, 2019 at 12:00 PM Chinmay Kulkarni < > > chinmayskulka...@gmail.com> > > wrote: > > > > > Congratulations Cheng! > > > > > > On Tue, Apr 9, 2019 at 11:51 AM Vincent Poon > > > wrote: > > > > > > > Congrats Cheng! > > > > > > > > On Tue, Apr 9, 2019 at 11:42 AM Thomas D'Silva > > > wrote: > > > > > > > > > On behalf of the Apache Phoenix PMC, I'm pleased to announce that > > Cheng > > > > > Lei has accepted our invitation to join the PMC. > > > > > > > > > > Please join me in congratulating Cheng. > > > > > > > > > > Thanks, > > > > > Thomas > > > > > > > > > > > > > > > > > > -- > > > Chinmay Kulkarni > > > M.S. Computer Science, > > > University of Illinois at Urbana-Champaign. > > > B. Tech Computer Engineering, > > > College of Engineering, Pune. > > > > > >
Re: [DISCUSS] Drop support for java 1.7 on the 1.2, 1.3 and 1.4 branches
I'd vote for keep using java7 on 4.x branches. if upgrades to java8, it will impact users who want to upgrade the latest 4.x branches. they must consider using java8 in their running environments, maybe their libraries do not support java8, then they have to give up to upgrade. So I think that drops support java7 is not friendly for some users. Jaanai Zhang Best regards! Pedro Boado 于2018年11月30日周五 上午6:13写道： > I'd vote for keep compiling 4.x branches in java7. It makes sense as it's > just a new minor release. > > It's pretty easy reverting back to spark 1.6 and also avatica dependency > could be reverted to the previous version. > > On 29 Nov 2018 21:41, "Thomas D'Silva" wrote: > > We have traditionally followed HBase's java support (see > https://hbase.apache.org/book.html#basic.prerequisites). The > phoenix-queryserver module has a dependency on Avatica which does not > support Java 1.7. The phoenix-spark module depends on spark 2.3.2 which > also does not support Java 1.7. Do folks feel we should continue to provide > support Java 1.7 on the 1.x branches? >
Re: System.Catalog Table
Could you reproduce this problem? What is your Pheonix's version number? Jaanai Zhang Best regards! Ayola Jayamaha 于2018年11月28日周三 下午4:53写道： > Hi, > I have a question regarding system.catelog table > How is this table is updated when we clone hbase table and apply ddl in > pheonix client? > We see a problem when we clone the table. For example a table has 15 rows > in system.catalog we cloned the hbase snapshot and recreated the same > table > when we check the info in system.catalog about this table we see only 14 > rows > because of this few columns showing null values instead of original values. > > Thank you > > > -- > Best Regards, > Ayola Jayamaha > http://ayolajayamaha.blogspot.com/ >
Re: When is best moment to release Phoenix 5.1
I mean, do we have any plan to release? @Thomas @Josh :) Jaanai Zhang Best regards! Jaanai 于2018年11月21日周三 下午4:38写道： > I wonder if we had planned to release Phoenix 5.1. as far as I am > concerned Pheonix 5.1 is a stable version against 5.0, so I and my > co-workers decide to use this version for HBase 2.x on public cloud service. > > For you provide any information, I'd appreciate it. > > Thanks! >
Re: Phoenix developer Meetup
How to connect video conference？ Jaanai Zhang Best regards! la...@apache.org 于2018年11月10日周六 上午6:48写道： > To confirm: > Phoenix DEV Meetup. > Wednesday, November 14th, 4pm, Salesforce Tower (415 Mission St.) (17th > floor, sorry not the top floor). We'll meet in the lobby to get visitor > badges.Please try to be on time, or let me know when you'll be later > (someone will have to come down to let you up) > Thanks. > -- Lars > On Friday, November 9, 2018, 10:30:09 AM PST, la...@apache.org < > la...@apache.org> wrote: > > Great. > And sorry for the folks in other TZs, it's impossible to find a time for > everyone.I'll try to record the session via hangouts and post the recording > here, and I will post the notes. > Here's an initial agenda, distilled and grouped from all your suggested > topics:(I plan to keep it free-form, so we can get some good discussions, > but if you want prepare _short_ slides/docs or proposals for the topics you > care about that is of course very welcome!) > > Intro > > - Open Source at Salesforce (Chris Kelly) > - Phoenix usage at Salesforce (Lars Hofhansl) > > Round-table > > - Introductions > - Current thoughts and pain points > > Deep Dives > > (topics derived from requests from the community) > > Direction and Future > > - Status of 4.x and master branches > - Current challenges (public cloud?, performance?, community?, SQL > coverage?, scale?) > - Secondary Indexing (Lars Hofhansl) > - Future direction. Where do we want Phoenix to be in 1 years, 2 years, > 5 years? > - Feature gaps in multi-tenancy. Fat client vs thin > - Feature resiliency / hardening (general) > - integration with Data Analytics tool like spark. > > Project Management > > - Release cadence (need RMs that spend time on this) > - Improve mailing list support > - PR review rotation > - Nominate new committers > - Branch cleanup > - checkin criteria and testing (IT vs. unit tests) > > Project Cleanliness > > - Fix test flappers and overall improvements overall test infra > - Refactoring, correctness, code extensibility > - Potential refactoring work > - Perf tool for Phoenix Query Server > - Thoughts on test infra > > > > > > On Wednesday, November 7, 2018, 3:45:44 PM PST, Josh Elser < > els...@apache.org> wrote: > > My schedule may be getting switched around. Might be able to make it > physically! > > Marked myself as a "M" for maybe on the spreadsheet :) > > On 11/6/18 7:07 PM, la...@apache.org wrote: > > Ok. The room is booked for Wednesday November 14th from 4-7pm, in the > Salesforce Tower (but not the top floor :( ) > > If you can confirm your attendance here (see the extra column on the > right): > https://docs.google.com/spreadsheets/d/1j4QSk53B0ZIl_qq1XX3oB2f-Tyqp93ilJYZKG84_Amg/edit#gid=0 > > > > That would be great for planning food, etc. I will send out an agenda. > > Thanks. > > -- Lars > > On Tuesday, October 23, 2018, 4:01:33 PM PDT, la...@apache.org < > la...@apache.org> wrote: > > > >This is still on. > > I'm trying to get us a spot in the Salesforce tower top floor. As you > can imagine it's a coveted spot.If I can't get a time slot there in the > next week I'll book a "usual" conference room. > > Stay tuned. > > Thanks. > > -- Lars > > > > > > On Friday, October 5, 2018, 1:01:06 PM PDT, la...@apache.org < > la...@apache.org> wrote: > > > >Last call :) > > On Monday, October 1, 2018, 10:15:07 AM PDT, la...@apache.org < > la...@apache.org> wrote: > > > >10 people signed up so far.This is a good chance to make your voice > heard, give input, and help point the project in the right direction going > forward. > > -- Lars > > > > On Friday, September 28, 2018, 10:39:41 AM PDT, la...@apache.org < > la...@apache.org> wrote: > > > > Hi all, > > I'm planning to put together a Phoenix developer meetup at the > Salesforce office (with video conference for those who cannot attend in > person) in the next few weeks. > > If you're interested please put your name in this spreadsheet: > https://docs.google.com/spreadsheets/d/1j4QSk53B0ZIl_qq1XX3oB2f-Tyqp93ilJYZKG84_Amg/edit?usp=sharing > > > > This is a chance to get all those who contribute to Phoenix together. > There will also be food. :)I will leave the spreadsheet up for one week - > until Friday October 5th. > > Possible agenda:- Round-table- Status of 4.x and master branches- > Current challenges (public cloud?, performance?, community?, SQL coverage?, > scale?)- Future direction. Where do we want Phoenix to be in 1 years, 2 > years, 5 years?- more... > > Thanks. > > -- Lars > > > > >
Re: [DISCUSS] Suggestions for Phoenix from HBaseCon Asia notes
> > How about submitting patch to HBase to modify > https://hbase.apache.org/poweredbyhbase.html ? :) It will be hard to find by folks if we add Phoneix's link to this page. May the home page of HBase is a good place... but which needs the approval of HBase community. ---- Jaanai Zhang Best regards! Jaanai Zhang 于2018年9月19日周三 上午12:08写道： > I don't understand what performance issues you think exist based solely on >> the above. Those numbers appear to be precisely in line with my >> expectations. Can you please describe what issues you think exist? >> > > 1. Performance of the thick client has almost 1~4 time higher than the > thin client, the performance of the thin client will be decreased when the > number of concurrencies is increased. For some applications of the web > server, this is not enough. > 2. An HA thin client. > 3. SQL audit function > > A lot of developer like using the thin client, which has a lower > maintenance cost on the client.Sorry, that's all that comes to me. :) > > Please be more specific. Asking for "more documentation" doesn't help us >> actually turn this around into more documentation. What are the specific >> pain points you have experienced? What topics do you want to know more >> about? Be as specific as possible. >> > > About documents: > 1. I think that we cloud add documents about migrate tools and migrate > cases since many users migrate from RDBMS(MYSQL/PG/SQL SERVER) to Phoenix > for some applications of non-transaction. > 2. How to design PK or indexes. > > About pain points: > The stability is a big problem. Most of the people use Phoenix as a common > RDBMS, they are informal to execute a query, even if they don't know why > server crash when a scan full table was executed, so define use boundary of > Phoenix is important that rejects some query and reports it user's client. > > Are you referring to the hbase-spark (and thus, Spark SQL) integration? Or >> something that some company is building? >> > > Some companies are building with SPARK SQL to access Phoenix to support > OLAP and OLTP requirements. it will produce heavily load for HBase cluster > when Spark reads Phoenix tables, my co-workers want to directly read > HFiles of Phoenix tables for some offline business, but that depends on > more flexible Phoenix API. > > Uh, I also got some feedback that some features import for users, For > example, "alter table modify column" can avoid reloaded data again which is > expensive operate for the massive data table. I had upload patches to JIRA( > PHOENIX-4815 <https://issues.apache.org/jira/browse/PHOENIX-4815>), but > nobody responds to me :(. > > Now, i devote to develop chaos test and PQS stability(it was developed on > the branch of my company, these patches will contribute to the community > after stable running ), if you have any suggests, please tell to me what > you thinking. I would appreciate your reply. > > > >Jaanai Zhang >Best regards! > > > > Josh Elser 于2018年9月18日周二 上午12:03写道： > >> >> >> On Mon, Sep 17, 2018 at 9:36 AM zhang yun wrote: >> >>> Sorry for replying late. I attended HBaesCon Asia as a speaker and got >>> some some notes. I think Phoenix’ pains as following: >>> >>> 1. Thick client isn’t as more popular as thin client. For some we >>> applications: 1. Users need to spend a lot of time to solve the >>> dependencies, 2. Users worry about the stability which some calculation >>> operates are processed within thick client . 3. Some people hope use multi >>> program language client, such as Go, .Net and Python etc… Other benefits: >>> 1 Easy to add SQL audit function. 2. Recognise invalid SQL and report to >>> user...As you said this definitely a big issue which is worth paying >>> more attention. However thick client exists some problems, it is recently >>> test data about performance: >>> >>> >> I don't understand what performance issues you think exist based solely >> on the above. Those numbers appear to be precisely in line with my >> expectations. Can you please describe what issues you think exist? >> >> >>> 2. Actually, Phoenix has a high barrier for beginner than common RDBMS, >>> users need to learn HBase before using Phoenix, Most of people don’t know >>> how to reasonable to use, so we need more detail documents make Phoenix >>> use easier. >>> >> >> Please be more specific. Asking for "more documentation" doesn't help u
Re: [DISCUSS] Suggestions for Phoenix from HBaseCon Asia notes
> > I don't understand what performance issues you think exist based solely on > the above. Those numbers appear to be precisely in line with my > expectations. Can you please describe what issues you think exist? > 1. Performance of the thick client has almost 1~4 time higher than the thin client, the performance of the thin client will be decreased when the number of concurrencies is increased. For some applications of the web server, this is not enough. 2. An HA thin client. 3. SQL audit function A lot of developer like using the thin client, which has a lower maintenance cost on the client.Sorry, that's all that comes to me. :) Please be more specific. Asking for "more documentation" doesn't help us > actually turn this around into more documentation. What are the specific > pain points you have experienced? What topics do you want to know more > about? Be as specific as possible. > About documents: 1. I think that we cloud add documents about migrate tools and migrate cases since many users migrate from RDBMS(MYSQL/PG/SQL SERVER) to Phoenix for some applications of non-transaction. 2. How to design PK or indexes. About pain points: The stability is a big problem. Most of the people use Phoenix as a common RDBMS, they are informal to execute a query, even if they don't know why server crash when a scan full table was executed, so define use boundary of Phoenix is important that rejects some query and reports it user's client. Are you referring to the hbase-spark (and thus, Spark SQL) integration? Or > something that some company is building? > Some companies are building with SPARK SQL to access Phoenix to support OLAP and OLTP requirements. it will produce heavily load for HBase cluster when Spark reads Phoenix tables, my co-workers want to directly read HFiles of Phoenix tables for some offline business, but that depends on more flexible Phoenix API. Uh, I also got some feedback that some features import for users, For example, "alter table modify column" can avoid reloaded data again which is expensive operate for the massive data table. I had upload patches to JIRA( PHOENIX-4815 <https://issues.apache.org/jira/browse/PHOENIX-4815>), but nobody responds to me :(. Now, i devote to develop chaos test and PQS stability(it was developed on the branch of my company, these patches will contribute to the community after stable running ), if you have any suggests, please tell to me what you thinking. I would appreciate your reply. Jaanai Zhang Best regards! Josh Elser 于2018年9月18日周二 上午12:03写道： > > > On Mon, Sep 17, 2018 at 9:36 AM zhang yun wrote: > >> Sorry for replying late. I attended HBaesCon Asia as a speaker and got >> some some notes. I think Phoenix’ pains as following: >> >> 1. Thick client isn’t as more popular as thin client. For some we >> applications: 1. Users need to spend a lot of time to solve the >> dependencies, 2. Users worry about the stability which some calculation >> operates are processed within thick client . 3. Some people hope use multi >> program language client, such as Go, .Net and Python etc… Other benefits: >> 1 Easy to add SQL audit function. 2. Recognise invalid SQL and report to >> user...As you said this definitely a big issue which is worth paying >> more attention. However thick client exists some problems, it is recently >> test data about performance: >> >> > I don't understand what performance issues you think exist based solely on > the above. Those numbers appear to be precisely in line with my > expectations. Can you please describe what issues you think exist? > > >> 2. Actually, Phoenix has a high barrier for beginner than common RDBMS, >> users need to learn HBase before using Phoenix, Most of people don’t know >> how to reasonable to use, so we need more detail documents make Phoenix >> use easier. >> > > Please be more specific. Asking for "more documentation" doesn't help us > actually turn this around into more documentation. What are the specific > pain points you have experienced? What topics do you want to know more > about? Be as specific as possible. > > >> 3. HBase 3.0 has a plan about native SQL, does Phoenix has a plan? Even >> if many peoples don’t know HBase has a SQL layer which is called Phoenix, >> so can we put the link on HBase website? >> > > Uh, I have no idea what you're referring to here about "native SQL". I am > not aware of any such effort that does this solely inside of HBase, nor > does it seem inline with HBase's "do one thing well" mantra. > > Are you referring to the hbase-spark (and thus, Spark SQL) integration? Or > something that some compan
[jira] [Assigned] (PHOENIX-4093) org.apache.phoenix.exception.PhoenixIOException: java.net.SocketTimeoutException: callTimeout=60000, callDuration=60304:
[ https://issues.apache.org/jira/browse/PHOENIX-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang reassigned PHOENIX-4093: - Assignee: Jaanai Zhang > org.apache.phoenix.exception.PhoenixIOException: > java.net.SocketTimeoutException: callTimeout=6, callDuration=60304: > > > Key: PHOENIX-4093 > URL: https://issues.apache.org/jira/browse/PHOENIX-4093 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.10.0 > Environment: Phoenix4.10 > HBase 1.2 CDH5.12 >Reporter: Jepson >Assignee: Jaanai Zhang >Priority: Major > Labels: performance > > SQL Error [101] [08000]: org.apache.phoenix.exception.PhoenixIOException: > Failed after attempts=36, exceptions: > Thu Aug 17 10:51:48 UTC 2017, null, *java.net.SocketTimeoutException: > callTimeout=6, callDuration=60304*: row '' on table 'DW:OMS_TIO_IDX' at > region=DW:OMS_TIO_IDX,,1502808904791.06aa2e941810212e9c8733e5f6bdb9ec., > hostname=hadoop44,60020,1502954074181, seqNum=8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4847) Index tables will produce dirty data when uses BukloadTool
[
https://issues.apache.org/jira/browse/PHOENIX-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai Zhang updated PHOENIX-4847:
--
Summary: Index tables will produce dirty data when uses BukloadTool (was:
Index tables will produce dirty data when use BukloadTool )
> Index tables will produce dirty data when uses BukloadTool
> ---
>
> Key: PHOENIX-4847
> URL: https://issues.apache.org/jira/browse/PHOENIX-4847
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0
> Reporter: Jaanai Zhang
>Priority: Critical
>
> Index tables are inconsistent with data tables when occurs update primary key
> of data tables with CSVBulkload tool.
> CSV data:
> {code:sql}
> k1,v1_1,1
> k2,v2_2,2
> k1,v1_1,3
> {code}
> Imported table
> {code:sql}
> DROP TABLE IF EXISTS TABLE1;
> CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
> SALT_BUCKETS = 8,
> UPDATE_CACHE_FREQUENCY = 12;
> CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
> CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
> {code}
> The following is query results after executing `CsvBulkLoadTool`
> {code:sql}
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
> +-+---+-+
> | ID | V1 | V2 |
> +-+---+-+
> | k2 | v2_2 | 2 |
> | k1 | v1_1 | 3 |
> +-+---+-+
> 2 rows selected (0.066 seconds)
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
> +---+--+---+
> | 0:V1 | :ID | 0:V2 |
> +---+--+---+
> | v1_1 | k1 | 3 |
> | v2_2 | k2 | 2 |
> +---+--+---+
> 2 rows selected (0.074 seconds)
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V2_IDX;
> +---+--+---+
> | 0:V2 | :ID | 0:V1 |
> +---+--+---+
> | 1 | k1 | v1_1 |
> | 3 | k1 | v1_1 |
> | 2 | k2 | v2_2 |
> +---+--+---+
> 3 rows selected (0.062 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4847) Index tables will produce dirty data when use BukloadTool
[
https://issues.apache.org/jira/browse/PHOENIX-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai Zhang updated PHOENIX-4847:
--
Description:
Index tables are inconsistent with data tables when occurs update primary key
of data tables with CSVBulkload tool.
CSV data:
{code:sql}
k1,v1_1,1
k2,v2_2,2
k1,v1_1,3
{code}
Imported table
{code:sql}
DROP TABLE IF EXISTS TABLE1;
CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
SALT_BUCKETS = 8,
UPDATE_CACHE_FREQUENCY = 12;
CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
{code}
The following is query results after executing `CsvBulkLoadTool`
{code:sql}
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
+-+---+-+
| ID | V1 | V2 |
+-+---+-+
| k2 | v2_2 | 2 |
| k1 | v1_1 | 3 |
+-+---+-+
2 rows selected (0.066 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
+---+--+---+
| 0:V1 | :ID | 0:V2 |
+---+--+---+
| v1_1 | k1 | 3 |
| v2_2 | k2 | 2 |
+---+--+---+
2 rows selected (0.074 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V2_IDX;
+---+--+---+
| 0:V2 | :ID | 0:V1 |
+---+--+---+
| 1 | k1 | v1_1 |
| 3 | k1 | v1_1 |
| 2 | k2 | v2_2 |
+---+--+---+
3 rows selected (0.062 seconds)
{code}
was:
Index tables are inconsistent with data tables when occurs update primary key
of data tables with CSVBulkload tool.
CSV data:
{code:sql}
k1,v1_1,1
k2,v2_2,2
k1,v1_1,3
{code}
Imported table
{code:sql}
DROP TABLE IF EXISTS TABLE1;
CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
SALT_BUCKETS = 8,
UPDATE_CACHE_FREQUENCY = 12;
CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
upsert into TABLE1 values('k1','v1_1',1);
upsert into TABLE1 values('k2','v2_2',2);
upsert into TABLE1 values('k1','v1_1',3);
{code}
The following is query results after executing `CsvBulkLoadTool`
{code:sql}
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
+-+---+-+
| ID | V1 | V2 |
+-+---+-+
| k2 | v2_2 | 2 |
| k1 | v1_1 | 3 |
+-+---+-+
2 rows selected (0.066 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
+---+--+---+
| 0:V1 | :ID | 0:V2 |
+---+--+---+
| v1_1 | k1 | 3 |
| v2_2 | k2 | 2 |
+---+--+---+
2 rows selected (0.074 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V2_IDX;
+---+--+---+
| 0:V2 | :ID | 0:V1 |
+---+--+---+
| 1 | k1 | v1_1 |
| 3 | k1 | v1_1 |
| 2 | k2 | v2_2 |
+---+--+---+
3 rows selected (0.062 seconds)
{code}
> Index tables will produce dirty data when use BukloadTool
> --
>
> Key: PHOENIX-4847
> URL: https://issues.apache.org/jira/browse/PHOENIX-4847
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0
>Reporter: Jaanai Zhang
>Priority: Critical
>
> Index tables are inconsistent with data tables when occurs update primary key
> of data tables with CSVBulkload tool.
> CSV data:
> {code:sql}
> k1,v1_1,1
> k2,v2_2,2
> k1,v1_1,3
> {code}
> Imported table
> {code:sql}
> DROP TABLE IF EXISTS TABLE1;
> CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
> SALT_BUCKETS = 8,
> UPDATE_CACHE_FREQUENCY = 12;
> CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
> CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
> {code}
> The following is query results after executing `CsvBulkLoadTool`
> {code:sql}
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
> +-+---+-+
> | ID | V1 | V2 |
> +-+---+-+
> | k2 | v2_2 | 2 |
> | k1 | v1_1 | 3 |
> +-+---+-+
> 2 rows selected (0.066 seconds)
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
> +---+--+---+
> | 0:V1 | :ID | 0:V2 |
> +---+--+---+
> | v1_1 | k1 | 3 |
> | v2_2 | k2 | 2 |
> +---+--+---+
> 2 rows selected (0.074 seconds)
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V2_IDX;
> +---+--+---+
> | 0:V2 | :ID | 0:V1 |
> +---+--+---+
> | 1 | k1 | v1_1 |
> | 3 | k1 | v1_1 |
> | 2 | k2 | v2_2 |
> +---+--+---+
> 3 rows selected (0.062 seconds)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4847) Index tables will produce dirty data when use BukloadTool
[
https://issues.apache.org/jira/browse/PHOENIX-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai Zhang updated PHOENIX-4847:
--
Description:
Index tables are inconsistent with data tables when occurs update primary key
of data tables with CSVBulkload tool.
CSV data:
{code:sql}
k1,v1_1,1
k2,v2_2,2
k1,v1_1,3
{code}
Imported table
{code:sql}
DROP TABLE IF EXISTS TABLE1;
CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
SALT_BUCKETS = 8,
UPDATE_CACHE_FREQUENCY = 12;
CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
upsert into TABLE1 values('k1','v1_1',1);
upsert into TABLE1 values('k2','v2_2',2);
upsert into TABLE1 values('k1','v1_1',3);
{code}
The following is query results after executing `CsvBulkLoadTool`
{code:sql}
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
+-+---+-+
| ID | V1 | V2 |
+-+---+-+
| k2 | v2_2 | 2 |
| k1 | v1_1 | 3 |
+-+---+-+
2 rows selected (0.066 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
+---+--+---+
| 0:V1 | :ID | 0:V2 |
+---+--+---+
| v1_1 | k1 | 3 |
| v2_2 | k2 | 2 |
+---+--+---+
2 rows selected (0.074 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V2_IDX;
+---+--+---+
| 0:V2 | :ID | 0:V1 |
+---+--+---+
| 1 | k1 | v1_1 |
| 3 | k1 | v1_1 |
| 2 | k2 | v2_2 |
+---+--+---+
3 rows selected (0.062 seconds)
{code}
was:
Index tables are inconsistent with data tables when occurs update primary key
of data tables with CSVBulkload tool.
CSV data:
{code:csv}
k1,v1_1,1
k2,v2_2,2
k1,v1_1,3
{code}
Imported table
{code:sql}
DROP TABLE IF EXISTS TABLE1;
CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
SALT_BUCKETS = 8,
UPDATE_CACHE_FREQUENCY = 12;
CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
upsert into TABLE1 values('k1','v1_1',1);
upsert into TABLE1 values('k2','v2_2',2);
upsert into TABLE1 values('k1','v1_1',3);
{code}
The following is query results after executing `CsvBulkLoadTool`
{code:sql}
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
+-+---+-+
| ID | V1 | V2 |
+-+---+-+
| k2 | v2_2 | 2 |
| k1 | v1_1 | 3 |
+-+---+-+
2 rows selected (0.066 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
+---+--+---+
| 0:V1 | :ID | 0:V2 |
+---+--+---+
| v1_1 | k1 | 3 |
| v2_2 | k2 | 2 |
+---+--+---+
2 rows selected (0.074 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V2_IDX;
+---+--+---+
| 0:V2 | :ID | 0:V1 |
+---+--+---+
| 1 | k1 | v1_1 |
| 3 | k1 | v1_1 |
| 2 | k2 | v2_2 |
+---+--+---+
3 rows selected (0.062 seconds)
{code}
> Index tables will produce dirty data when use BukloadTool
> --
>
> Key: PHOENIX-4847
> URL: https://issues.apache.org/jira/browse/PHOENIX-4847
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0
>Reporter: Jaanai Zhang
>Priority: Critical
>
> Index tables are inconsistent with data tables when occurs update primary key
> of data tables with CSVBulkload tool.
> CSV data:
> {code:sql}
> k1,v1_1,1
> k2,v2_2,2
> k1,v1_1,3
> {code}
> Imported table
> {code:sql}
> DROP TABLE IF EXISTS TABLE1;
> CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
> SALT_BUCKETS = 8,
> UPDATE_CACHE_FREQUENCY = 12;
> CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
> CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
> upsert into TABLE1 values('k1','v1_1',1);
> upsert into TABLE1 values('k2','v2_2',2);
> upsert into TABLE1 values('k1','v1_1',3);
> {code}
> The following is query results after executing `CsvBulkLoadTool`
> {code:sql}
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
> +-+---+-+
> | ID | V1 | V2 |
> +-+---+-+
> | k2 | v2_2 | 2 |
> | k1 | v1_1 | 3 |
> +-+---+-+
> 2 rows selected (0.066 seconds)
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
> +---+--+---+
> | 0:V1 | :ID | 0:V2 |
> +---+--+---+
> | v1_1 | k1 | 3 |
> | v2_2 | k2 | 2 |
> +---+--+---+
> 2 rows selected (0.074 seconds)
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> sel
[jira] [Updated] (PHOENIX-4847) Index tables will produce dirty data when use BukloadTool
[
https://issues.apache.org/jira/browse/PHOENIX-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai Zhang updated PHOENIX-4847:
--
Description:
Index tables are inconsistent with data tables when occurs update primary key
of data tables with CSVBulkload tool.
CSV data:
{code:csv}
k1,v1_1,1
k2,v2_2,2
k1,v1_1,3
{code}
Imported table
{code:sql}
DROP TABLE IF EXISTS TABLE1;
CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
SALT_BUCKETS = 8,
UPDATE_CACHE_FREQUENCY = 12;
CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
upsert into TABLE1 values('k1','v1_1',1);
upsert into TABLE1 values('k2','v2_2',2);
upsert into TABLE1 values('k1','v1_1',3);
{code}
The following is query results after executing `CsvBulkLoadTool`
{code:sql}
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
+-+---+-+
| ID | V1 | V2 |
+-+---+-+
| k2 | v2_2 | 2 |
| k1 | v1_1 | 3 |
+-+---+-+
2 rows selected (0.066 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
+---+--+---+
| 0:V1 | :ID | 0:V2 |
+---+--+---+
| v1_1 | k1 | 3 |
| v2_2 | k2 | 2 |
+---+--+---+
2 rows selected (0.074 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V2_IDX;
+---+--+---+
| 0:V2 | :ID | 0:V1 |
+---+--+---+
| 1 | k1 | v1_1 |
| 3 | k1 | v1_1 |
| 2 | k2 | v2_2 |
+---+--+---+
3 rows selected (0.062 seconds)
{code}
was:
Index tables are inconsistent with data tables when occurs update primary key
of data tables with CSVBulkload tool.
CSV data:
{code:csv}
k1,v1_1,1
k2,v2_2,2
k1,v1_1,3
{code}
Imported table
{code:sql}
DROP TABLE IF EXISTS TABLE1;
CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
SALT_BUCKETS = 8,
UPDATE_CACHE_FREQUENCY = 12;
CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
upsert into TABLE1 values('k1','v1_1',1);
upsert into TABLE1 values('k2','v2_2',2);
upsert into TABLE1 values('k1','v1_1',3);
{code}
The following is query results after executing `CsvBulkLoadTool`
{code:sql}
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
+-+---+-+
| ID | V1 | V2 |
+-+---+-+
| k2 | v2_2 | 2 |
| k1 | v1_1 | 3 |
+-+---+-+
2 rows selected (0.066 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
+---+--+---+
| 0:V1 | :ID | 0:V2 |
+---+--+---+
| v1_1 | k1 | 3 |
| v2_2 | k2 | 2 |
+---+--+---+
2 rows selected (0.074 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V2_IDX;
+---+--+---+
| 0:V2 | :ID | 0:V1 |
+---+--+---+
| 1 | k1 | v1_1 |
| 3 | k1 | v1_1 |
| 2 | k2 | v2_2 |
+---+--+---+
3 rows selected (0.062 seconds)
{code}
> Index tables will produce dirty data when use BukloadTool
> --
>
> Key: PHOENIX-4847
> URL: https://issues.apache.org/jira/browse/PHOENIX-4847
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0
>Reporter: Jaanai Zhang
>Priority: Critical
>
> Index tables are inconsistent with data tables when occurs update primary key
> of data tables with CSVBulkload tool.
> CSV data:
> {code:csv}
> k1,v1_1,1
> k2,v2_2,2
> k1,v1_1,3
> {code}
> Imported table
> {code:sql}
> DROP TABLE IF EXISTS TABLE1;
> CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
> SALT_BUCKETS = 8,
> UPDATE_CACHE_FREQUENCY = 12;
> CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
> CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
> upsert into TABLE1 values('k1','v1_1',1);
> upsert into TABLE1 values('k2','v2_2',2);
> upsert into TABLE1 values('k1','v1_1',3);
> {code}
> The following is query results after executing `CsvBulkLoadTool`
> {code:sql}
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
> +-+---+-+
> | ID | V1 | V2 |
> +-+---+-+
> | k2 | v2_2 | 2 |
> | k1 | v1_1 | 3 |
> +-+---+-+
> 2 rows selected (0.066 seconds)
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
> +---+--+---+
> | 0:V1 | :ID | 0:V2 |
> +---+--+---+
> | v1_1 | k1 | 3 |
> | v2_2 | k2 | 2 |
> +---+--+---+
> 2 rows selected (0.074 seconds)
> 0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> sel
[jira] [Created] (PHOENIX-4847) Index tables will produce dirty data when use BukloadTool
Jaanai Zhang created PHOENIX-4847:
-
Summary: Index tables will produce dirty data when use BukloadTool
Key: PHOENIX-4847
URL: https://issues.apache.org/jira/browse/PHOENIX-4847
Project: Phoenix
Issue Type: Bug
Affects Versions: 5.0.0, 4.14.0, 4.13.0, 4.12.0
Reporter: Jaanai Zhang
Index tables are inconsistent with data tables when occurs update primary key
of data tables with CSVBulkload tool.
CSV data:
{code:csv}
k1,v1_1,1
k2,v2_2,2
k1,v1_1,3
{code}
Imported table
{code:sql}
DROP TABLE IF EXISTS TABLE1;
CREATE TABLE TABLE1 (ID VARCHAR NOT NULL PRIMARY KEY, V1 VARCHAR, V2 BIGINT)
SALT_BUCKETS = 8,
UPDATE_CACHE_FREQUENCY = 12;
CREATE INDEX V1_IDX on TABLE1(V1) include(v2);
CREATE INDEX V2_IDX on TABLE1(V2) include(v1);
upsert into TABLE1 values('k1','v1_1',1);
upsert into TABLE1 values('k2','v2_2',2);
upsert into TABLE1 values('k1','v1_1',3);
{code}
The following is query results after executing `CsvBulkLoadTool`
{code:sql}
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from table1;
+-+---+-+
| ID | V1 | V2 |
+-+---+-+
| k2 | v2_2 | 2 |
| k1 | v1_1 | 3 |
+-+---+-+
2 rows selected (0.066 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V1_IDX;
+---+--+---+
| 0:V1 | :ID | 0:V2 |
+---+--+---+
| v1_1 | k1 | 3 |
| v2_2 | k2 | 2 |
+---+--+---+
2 rows selected (0.074 seconds)
0: jdbc:phoenix:hb-bp18j460748jq41v0-002.hbas> select * from V2_IDX;
+---+--+---+
| 0:V2 | :ID | 0:V1 |
+---+--+---+
| 1 | k1 | v1_1 |
| 3 | k1 | v1_1 |
| 2 | k2 | v2_2 |
+---+--+---+
3 rows selected (0.062 seconds)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: PHOENIX-4822_master.patch > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0 >Reporter: Jaanai Zhang >Assignee: Jaanai Zhang >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4822.patch, PHOENIX-4822_4.14.0-HBase-1.4.patch, > PHOENIX-4822_5.x-HBase-2.0.patch, PHOENIX-4822_master.patch, > PHOENIX-4822_v2.patch, PHOENIX-4822_v3.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: (was: PHOENIX-4822_master.patch) > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0 >Reporter: Jaanai Zhang >Assignee: Jaanai Zhang >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4822.patch, PHOENIX-4822_4.14.0-HBase-1.4.patch, > PHOENIX-4822_5.x-HBase-2.0.patch, PHOENIX-4822_v2.patch, PHOENIX-4822_v3.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: PHOENIX-4822_5.x-HBase-2.0.patch > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0 >Reporter: Jaanai Zhang >Assignee: Jaanai Zhang >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4822.patch, PHOENIX-4822_4.14.0-HBase-1.4.patch, > PHOENIX-4822_5.x-HBase-2.0.patch, PHOENIX-4822_master.patch, > PHOENIX-4822_v2.patch, PHOENIX-4822_v3.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: PHOENIX-4822_master.patch PHOENIX-4822_4.14.0-HBase-1.4.patch > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0 >Reporter: Jaanai Zhang >Assignee: Jaanai Zhang >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4822.patch, PHOENIX-4822_4.14.0-HBase-1.4.patch, > PHOENIX-4822_master.patch, PHOENIX-4822_v2.patch, PHOENIX-4822_v3.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (PHOENIX-4815) support alter table modify column
[
https://issues.apache.org/jira/browse/PHOENIX-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai Zhang reassigned PHOENIX-4815:
-
Assignee: Jaanai Zhang
> support alter table modify column
> --
>
> Key: PHOENIX-4815
> URL: https://issues.apache.org/jira/browse/PHOENIX-4815
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.12.0
> Reporter: Jaanai Zhang
>Assignee: Jaanai Zhang
>Priority: Major
> Attachments: PHOENIX-4815.patch
>
>
> if we want to change max length or scale of fields of variable length type(
> example for :varchar, char and decimal type etc), we can not drop column to
> recreate new column when the table has massive data, which may affects
> online service，meanwhile, it is also very expensive. so sometimes this
> function is very useful.
> Taking ORACLE dialect as an reference
> {code:java}
> alter table
>table_name
> modify
>column_name datatype;
> {code}
> reference link:
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_3001.htm#i2103956
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: PHOENIX-4822_v3.patch > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0 >Reporter: Jaanai Zhang >Assignee: Jaanai Zhang >Priority: Major > Fix For: 4.15.0, 5.1.0 > > Attachments: PHOENIX-4822.patch, PHOENIX-4822_v2.patch, > PHOENIX-4822_v3.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4815) support alter table modify column
[
https://issues.apache.org/jira/browse/PHOENIX-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai Zhang updated PHOENIX-4815:
--
Affects Version/s: 4.12.0
> support alter table modify column
> --
>
> Key: PHOENIX-4815
> URL: https://issues.apache.org/jira/browse/PHOENIX-4815
> Project: Phoenix
> Issue Type: Improvement
>Affects Versions: 4.12.0
> Reporter: Jaanai Zhang
>Priority: Major
> Attachments: PHOENIX-4815.patch
>
>
> if we want to change max length or scale of fields of variable length type(
> example for :varchar, char and decimal type etc), we can not drop column to
> recreate new column when the table has massive data, which may affects
> online service，meanwhile, it is also very expensive. so sometimes this
> function is very useful.
> Taking ORACLE dialect as an reference
> {code:java}
> alter table
>table_name
> modify
>column_name datatype;
> {code}
> reference link:
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_3001.htm#i2103956
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Affects Version/s: (was: 4.11.0) > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0 >Reporter: Jaanai Zhang >Priority: Major > Attachments: PHOENIX-4822.patch, PHOENIX-4822_v2.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Affects Version/s: 4.13.0 > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.12.0, 4.13.0, 4.14.0, 5.0.0 >Reporter: Jaanai Zhang >Priority: Major > Attachments: PHOENIX-4822.patch, PHOENIX-4822_v2.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: PHOENIX-4822_v2.patch > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0, 4.12.0, 4.14.0, 5.0.0 >Reporter: Jaanai Zhang >Priority: Major > Attachments: PHOENIX-4822.patch, PHOENIX-4822_v2.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Affects Version/s: 4.14.0 5.0.0 > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0, 4.12.0, 4.14.0, 5.0.0 >Reporter: Jaanai Zhang >Priority: Major > Attachments: PHOENIX-4822.patch, PHOENIX-4822_v2.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: (was: PHOENIX-4822.patch_v2) > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0, 4.12.0 >Reporter: Jaanai Zhang >Priority: Major > Attachments: PHOENIX-4822.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: (was: PHOENIX-4822.patch_v2) > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0, 4.12.0 >Reporter: Jaanai Zhang >Priority: Major > Attachments: PHOENIX-4822.patch, PHOENIX-4822.patch_v2 > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: PHOENIX-4822.patch_v2 > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0, 4.12.0 >Reporter: Jaanai Zhang >Priority: Major > Attachments: PHOENIX-4822.patch, PHOENIX-4822.patch_v2 > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: PHOENIX-4822.patch_v2 > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0, 4.12.0 >Reporter: Jaanai Zhang >Priority: Major > Attachments: PHOENIX-4822.patch, PHOENIX-4822.patch_v2 > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
[ https://issues.apache.org/jira/browse/PHOENIX-4822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jaanai Zhang updated PHOENIX-4822: -- Attachment: PHOENIX-4822.patch > The configuration "phoenix.query.dateFormatTimeZone" does't work on the client > -- > > Key: PHOENIX-4822 > URL: https://issues.apache.org/jira/browse/PHOENIX-4822 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.11.0, 4.12.0 >Reporter: Jaanai Zhang >Priority: Major > Attachments: PHOENIX-4822.patch > > > when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml > or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (PHOENIX-4822) The configuration "phoenix.query.dateFormatTimeZone" does't work on the client
Jaanai Zhang created PHOENIX-4822: - Summary: The configuration "phoenix.query.dateFormatTimeZone" does't work on the client Key: PHOENIX-4822 URL: https://issues.apache.org/jira/browse/PHOENIX-4822 Project: Phoenix Issue Type: Bug Affects Versions: 4.11.0, 4.12.0 Reporter: Jaanai Zhang when add configuration "phoenix.query.dateFormatTimeZone" into hbase-site.xml or Properites of Connection, it can not work still uses time zone with GTM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (PHOENIX-4815) support alter table modify column
[
https://issues.apache.org/jira/browse/PHOENIX-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16553914#comment-16553914
]
Jaanai Zhang commented on PHOENIX-4815:
---
[~jamestaylor] Can u please review? thx
> support alter table modify column
> --
>
> Key: PHOENIX-4815
> URL: https://issues.apache.org/jira/browse/PHOENIX-4815
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Jaanai Zhang
>Priority: Major
> Attachments: PHOENIX-4815.patch
>
>
> if we want to change max length or scale of fields of variable length type(
> example for :varchar, char and decimal type etc), we can not drop column to
> recreate new column when the table has massive data, which may affects
> online service，meanwhile, it is also very expensive. so sometimes this
> function is very useful.
> Taking ORACLE dialect as an reference
> {code:java}
> alter table
>table_name
> modify
>column_name datatype;
> {code}
> reference link:
> https://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_3001.htm#i2103956
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4815) support alter table modify column
[
https://issues.apache.org/jira/browse/PHOENIX-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai Zhang updated PHOENIX-4815:
--
Attachment: PHOENIX-4815.patch
> support alter table modify column
> --
>
> Key: PHOENIX-4815
> URL: https://issues.apache.org/jira/browse/PHOENIX-4815
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Jaanai Zhang
>Priority: Major
> Attachments: PHOENIX-4815.patch
>
>
> if we want to change max length or scale of fields of variable length type(
> example for :varchar, char and decimal type etc), we can not drop column to
> recreate new column when the table has massive data, which may affects
> online service，meanwhile, it is also very expensive. so sometimes this
> function is very useful.
> Taking ORACLE dialect as an reference
> {code:java}
> alter table
>table_name
> modify
>column_name datatype;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-4815) support alter table modify column
[
https://issues.apache.org/jira/browse/PHOENIX-4815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaanai Zhang updated PHOENIX-4815:
--
Description:
if we want to change max length or scale of fields of variable length type(
example for :varchar, char and decimal type etc), we can not drop column to
recreate new column when the table has massive data, which may affects online
service，meanwhile, it is also very expensive. so sometimes this function is
very useful.
Taking ORACLE dialect as an reference
{code:java}
alter table
table_name
modify
column_name datatype;
{code}
was:
if we want to change max length or scale of fields of variable length type(
example for :varchar, char and decimal type etc), we can not drop column to
recreate new column when the table has massive data, which may affects online
service，meanwhile, it is also very expensive. so sometimes this function is
very useful.
Taking ORACLE dialect as reference
{code:java}
alter table
table_name
modify
column_name datatype;
{code}
> support alter table modify column
> --
>
> Key: PHOENIX-4815
> URL: https://issues.apache.org/jira/browse/PHOENIX-4815
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Jaanai Zhang
>Priority: Major
>
> if we want to change max length or scale of fields of variable length type(
> example for :varchar, char and decimal type etc), we can not drop column to
> recreate new column when the table has massive data, which may affects
> online service，meanwhile, it is also very expensive. so sometimes this
> function is very useful.
> Taking ORACLE dialect as an reference
> {code:java}
> alter table
>table_name
> modify
>column_name datatype;
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (PHOENIX-4815) support alter table modify column
Jaanai Zhang created PHOENIX-4815:
-
Summary: support alter table modify column
Key: PHOENIX-4815
URL: https://issues.apache.org/jira/browse/PHOENIX-4815
Project: Phoenix
Issue Type: Improvement
Reporter: Jaanai Zhang
if we want to change max length or scale of fields of variable length type(
example for :varchar, char and decimal type etc), we can not drop column to
recreate new column when the table has massive data, which may affects online
service，meanwhile, it is also very expensive. so sometimes this function is
very useful.
Taking ORACLE dialect as reference
{code:java}
alter table
table_name
modify
column_name datatype;
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (PHOENIX-4748) Upsert values don't correspond with order of fields
Jaanai Zhang created PHOENIX-4748: - Summary: Upsert values don't correspond with order of fields Key: PHOENIX-4748 URL: https://issues.apache.org/jira/browse/PHOENIX-4748 Project: Phoenix Issue Type: Bug Affects Versions: 4.11.0 Environment: jdk 1.8 hbase 1.1 Reporter: Jaanai Zhang Attachments: Screen Shot 2018-05-22 at 11.10.05.png, create_table.sql When UPSERT was executed, i found the some values are not wrote into appointed position of fields。 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
