[jira] [Resolved] (TEPHRA-305) Support HBase 2.1 and 2.2
[ https://issues.apache.org/jira/browse/TEPHRA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth resolved TEPHRA-305. Fix Version/s: 0.16.0-incubating Resolution: Fixed Reviewed and merged by [~anew]. Thanks! > Support HBase 2.1 and 2.2 > - > > Key: TEPHRA-305 > URL: https://issues.apache.org/jira/browse/TEPHRA-305 > Project: Phoenix Tephra > Issue Type: New Feature >Reporter: Istvan Toth >Assignee: Poorna Chandra >Priority: Blocker > Fix For: 0.16.0-incubating > > Time Spent: 20m > Remaining Estimate: 0h > > Tephra doesn't support anything newer that HBase 2.0. > The current supported HBase 2.x versions are 2.1 and 2.2, 2.0 has been > recently EOMed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5718) GetTable builds a table excluding the given clientTimeStamp
[ https://issues.apache.org/jira/browse/PHOENIX-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sandeep Guggilam updated PHOENIX-5718: -- Attachment: PHOENIX-5718.master.v1.patch > GetTable builds a table excluding the given clientTimeStamp > --- > > Key: PHOENIX-5718 > URL: https://issues.apache.org/jira/browse/PHOENIX-5718 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.16.0 >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Fix For: 4.16.0 > > Attachments: PHOENIX-5718.master.v1.patch > > > Here is the scenario tested: > # Brought up a server with 4.16 where new columns are added but not added as > part of upgrade path > # Connect with 4.14 client > # Connect with a 4.16 client - this will throw an exception as the new > columns added as part of 4.16 were not added as part of upgrade path > # Now the code will force update the cache in > PhoenixStatement#executeQuery() method > # Now the buildTable is removing even the columns added as part of 4.15 , > the reason being we are passing the clientTimeStamp to build table ( say 29 > is the timestamp for column added for 4.15) but the table is scanning rows > EXCLUDING the passed clientTimeSTamp as the Scan#setTimeRange method excludes > the end time stamp > The passing of clientTimeStamp to build table is in > MetaDataEndPointImpl#doGetTable method -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (PHOENIX-5679) Querying a DATE column with 'YYYY-MM-DD HH:MM:SS' format not returning the right data
[
https://issues.apache.org/jira/browse/PHOENIX-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sandeep Guggilam resolved PHOENIX-5679.
---
Resolution: Not A Bug
> Querying a DATE column with '-MM-DD HH:MM:SS' format not returning the
> right data
> -
>
> Key: PHOENIX-5679
> URL: https://issues.apache.org/jira/browse/PHOENIX-5679
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.15.0
>Reporter: Sandeep Guggilam
>Assignee: Sandeep Guggilam
>Priority: Major
>
> When we insert data into a DATE column with TO_DATE('-MM-DD HH:MM:SS')
> format and then query the same, it is returning back the DATE column with
> just ('-MM-DD') format but not returning the time.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5714) Upgrade to 4.16 throwing ColumnNotFoundException
[ https://issues.apache.org/jira/browse/PHOENIX-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-5714: -- Attachment: (was: PHOENIX-5714.master.v2.patch) > Upgrade to 4.16 throwing ColumnNotFoundException > > > Key: PHOENIX-5714 > URL: https://issues.apache.org/jira/browse/PHOENIX-5714 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.16.0 >Reporter: Sandeep Guggilam >Assignee: Sandeep Guggilam >Priority: Major > Fix For: 4.16.0 > > Attachments: PHOENIX-5714.4.x-HBase-1.3.v1.patch, > PHOENIX-5714.4.x-HBase-1.3.v2.patch, PHOENIX-5714.master.v1.patch, > PHOENIX-5714.master.v2.patch > > > Steps to reproduce: > # Bring up a server with 4.16 version ( the current 4.x-HBase-1.3 ) > # Connect the 4.14 client to the server using sqlline.py > # Connect the 4.16 client to the server using sqlline.py which then throws > the following exception > ERROR 504 (42703): Undefined column. > columnName=SYSTEM.CATALOG.VIEW_INDEX_ID_DATA_TYPE (state=42703,code=504) -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [ANNOUNCE] New Phoenix committer Gokcen Iskender
Congrats and welcome, Gokcen! On Thu, Feb 13, 2020 at 9:48 AM Ankit Singhal wrote: > Congratulations Gokcen! > > > On Wed, Feb 12, 2020 at 4:08 PM Josh Elser wrote: > > > Congratulations and welcome, Gokcen! > > > > On 2/10/20 1:55 PM, Geoffrey Jacoby wrote: > > > On behalf of the Apache Phoenix PMC, I'm pleased to announce that > Gokcen > > > Iskender has accepted our invitation to become a committer on the > Phoenix > > > project. Gokcen has contributed many features and bug fixes as part of > > our > > > rewrite of secondary global indexes, and presented on these changes at > > the > > > NoSQL Day of last year's DataWorks Summit. She's also been an active > > > reviewer and tester on other's patches. > > > > > > We appreciate Gokcen's many contributions and look forward to her > > continued > > > involvement. Welcome! > > > > > > Geoffrey Jacoby > > > > > > -- Chinmay Kulkarni
Re: [ANNOUNCE] New Phoenix committer Gokcen Iskender
Congratulations Gokcen! On Wed, Feb 12, 2020 at 4:08 PM Josh Elser wrote: > Congratulations and welcome, Gokcen! > > On 2/10/20 1:55 PM, Geoffrey Jacoby wrote: > > On behalf of the Apache Phoenix PMC, I'm pleased to announce that Gokcen > > Iskender has accepted our invitation to become a committer on the Phoenix > > project. Gokcen has contributed many features and bug fixes as part of > our > > rewrite of secondary global indexes, and presented on these changes at > the > > NoSQL Day of last year's DataWorks Summit. She's also been an active > > reviewer and tester on other's patches. > > > > We appreciate Gokcen's many contributions and look forward to her > continued > > involvement. Welcome! > > > > Geoffrey Jacoby > > >
[jira] [Updated] (PHOENIX-5537) Phoenix-4701 made hard coupling between phoenix.log.level and getting request metrics.
[
https://issues.apache.org/jira/browse/PHOENIX-5537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Antal updated PHOENIX-5537:
---
Attachment: PHOENIX-5537.master.v3.patch
> Phoenix-4701 made hard coupling between phoenix.log.level and getting request
> metrics.
> --
>
> Key: PHOENIX-5537
> URL: https://issues.apache.org/jira/browse/PHOENIX-5537
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 5.0.0, 4.15.0
>Reporter: Daniel Wong
>Assignee: Richard Antal
>Priority: Minor
> Fix For: 5.1.0, 4.15.1, 4.16.0
>
> Attachments: PHOENIX-5537.master.v1.patch,
> PHOENIX-5537.master.v2.patch, PHOENIX-5537.master.v3.patch
>
>
> Phoenix-4701 made hard coupling between phoenix.log.level and getting request
> metrics. For users who do not want to enable system to log this causes a
> regression from earlier behavior where metrics were populated. FYI [~ankit]
> {code:java}
> public OverAllQueryMetrics(boolean isRequestMetricsEnabled, LogLevel
> connectionLogLevel) { public OverAllQueryMetrics(boolean
> isRequestMetricsEnabled, LogLevel connectionLogLevel) { queryWatch = new
> MetricsStopWatch(WALL_CLOCK_TIME_MS.isLoggingEnabled(connectionLogLevel));
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-5709) Simplify index update generation code for consistent global indexes
[ https://issues.apache.org/jira/browse/PHOENIX-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-5709: --- Attachment: PHOENIX-5709.master.011.patch > Simplify index update generation code for consistent global indexes > --- > > Key: PHOENIX-5709 > URL: https://issues.apache.org/jira/browse/PHOENIX-5709 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.14.3 >Reporter: Kadir OZDEMIR >Assignee: Kadir OZDEMIR >Priority: Major > Fix For: 5.0.0, 4.14.3 > > Attachments: PHOENIX-5709.4.x-HBase-1.3.001.patch, > PHOENIX-5709.4.x-HBase-1.3.002.patch, PHOENIX-5709.4.x-HBase-1.3.003.patch, > PHOENIX-5709.4.x-HBase-1.3.004.patch, PHOENIX-5709.4.x-HBase-1.3.005.patch, > PHOENIX-5709.master.001.patch, PHOENIX-5709.master.002.patch, > PHOENIX-5709.master.003.patch, PHOENIX-5709.master.004.patch, > PHOENIX-5709.master.005.patch, PHOENIX-5709.master.006.patch, > PHOENIX-5709.master.007.patch, PHOENIX-5709.master.008.patch, > PHOENIX-5709.master.009.patch, PHOENIX-5709.master.010.patch, > PHOENIX-5709.master.011.patch > > Time Spent: 8h 20m > Remaining Estimate: 0h > > The implementation of the new global index design by PHOENIX-5156 essentially > introduced two coprocessors, IndexRegionObserver and GlobalIndexChecker. > IndexRegionObserver is the counterpart of the existing Indexer coprocessor > that the previous global indexing feature uses. It implements the indexing > write path. GlobalIndexChecker implements the read verification and read > repair that happens on the read path. One of the main objectives of the > design behind new global indexing was to leverage as much existing indexing > code as possible. This objective has been achieved greatly as the entire > index table update generation code implemented by various classes (including > PhoenixIndexBuilder, CachedLocalTable, NonTxIndexBuilder, IndexUpdateManager, > LocalTableState, ScannerBuilder, IndexMemStore and PhoenixIndexCodec) is > leveraged as it is mainly. This objective has served us well to deliver the > new indexing feature quickly. The leveraged code is very complex, over > engineered, and inefficient, and is not bug free. It is very hard to > maintain. It is time to replace the complex set of classes with something > drastically simpler and more efficient for the new design. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5709) Simplify index update generation code for consistent global indexes
[ https://issues.apache.org/jira/browse/PHOENIX-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-5709: --- Attachment: (was: PHOENIX-5709.master.011.patch) > Simplify index update generation code for consistent global indexes > --- > > Key: PHOENIX-5709 > URL: https://issues.apache.org/jira/browse/PHOENIX-5709 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.14.3 >Reporter: Kadir OZDEMIR >Assignee: Kadir OZDEMIR >Priority: Major > Fix For: 5.0.0, 4.14.3 > > Attachments: PHOENIX-5709.4.x-HBase-1.3.001.patch, > PHOENIX-5709.4.x-HBase-1.3.002.patch, PHOENIX-5709.4.x-HBase-1.3.003.patch, > PHOENIX-5709.4.x-HBase-1.3.004.patch, PHOENIX-5709.4.x-HBase-1.3.005.patch, > PHOENIX-5709.master.001.patch, PHOENIX-5709.master.002.patch, > PHOENIX-5709.master.003.patch, PHOENIX-5709.master.004.patch, > PHOENIX-5709.master.005.patch, PHOENIX-5709.master.006.patch, > PHOENIX-5709.master.007.patch, PHOENIX-5709.master.008.patch, > PHOENIX-5709.master.009.patch, PHOENIX-5709.master.010.patch > > Time Spent: 8h 20m > Remaining Estimate: 0h > > The implementation of the new global index design by PHOENIX-5156 essentially > introduced two coprocessors, IndexRegionObserver and GlobalIndexChecker. > IndexRegionObserver is the counterpart of the existing Indexer coprocessor > that the previous global indexing feature uses. It implements the indexing > write path. GlobalIndexChecker implements the read verification and read > repair that happens on the read path. One of the main objectives of the > design behind new global indexing was to leverage as much existing indexing > code as possible. This objective has been achieved greatly as the entire > index table update generation code implemented by various classes (including > PhoenixIndexBuilder, CachedLocalTable, NonTxIndexBuilder, IndexUpdateManager, > LocalTableState, ScannerBuilder, IndexMemStore and PhoenixIndexCodec) is > leveraged as it is mainly. This objective has served us well to deliver the > new indexing feature quickly. The leveraged code is very complex, over > engineered, and inefficient, and is not bug free. It is very hard to > maintain. It is time to replace the complex set of classes with something > drastically simpler and more efficient for the new design. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-5709) Simplify index update generation code for consistent global indexes
[ https://issues.apache.org/jira/browse/PHOENIX-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kadir OZDEMIR updated PHOENIX-5709: --- Attachment: PHOENIX-5709.master.011.patch > Simplify index update generation code for consistent global indexes > --- > > Key: PHOENIX-5709 > URL: https://issues.apache.org/jira/browse/PHOENIX-5709 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 5.0.0, 4.14.3 >Reporter: Kadir OZDEMIR >Assignee: Kadir OZDEMIR >Priority: Major > Fix For: 5.0.0, 4.14.3 > > Attachments: PHOENIX-5709.4.x-HBase-1.3.001.patch, > PHOENIX-5709.4.x-HBase-1.3.002.patch, PHOENIX-5709.4.x-HBase-1.3.003.patch, > PHOENIX-5709.4.x-HBase-1.3.004.patch, PHOENIX-5709.4.x-HBase-1.3.005.patch, > PHOENIX-5709.master.001.patch, PHOENIX-5709.master.002.patch, > PHOENIX-5709.master.003.patch, PHOENIX-5709.master.004.patch, > PHOENIX-5709.master.005.patch, PHOENIX-5709.master.006.patch, > PHOENIX-5709.master.007.patch, PHOENIX-5709.master.008.patch, > PHOENIX-5709.master.009.patch, PHOENIX-5709.master.010.patch, > PHOENIX-5709.master.011.patch > > Time Spent: 8h 20m > Remaining Estimate: 0h > > The implementation of the new global index design by PHOENIX-5156 essentially > introduced two coprocessors, IndexRegionObserver and GlobalIndexChecker. > IndexRegionObserver is the counterpart of the existing Indexer coprocessor > that the previous global indexing feature uses. It implements the indexing > write path. GlobalIndexChecker implements the read verification and read > repair that happens on the read path. One of the main objectives of the > design behind new global indexing was to leverage as much existing indexing > code as possible. This objective has been achieved greatly as the entire > index table update generation code implemented by various classes (including > PhoenixIndexBuilder, CachedLocalTable, NonTxIndexBuilder, IndexUpdateManager, > LocalTableState, ScannerBuilder, IndexMemStore and PhoenixIndexCodec) is > leveraged as it is mainly. This objective has served us well to deliver the > new indexing feature quickly. The leveraged code is very complex, over > engineered, and inefficient, and is not bug free. It is very hard to > maintain. It is time to replace the complex set of classes with something > drastically simpler and more efficient for the new design. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TEPHRA-305) Support HBase 2.1 and 2.2
[ https://issues.apache.org/jira/browse/TEPHRA-305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17036028#comment-17036028 ] Istvan Toth commented on TEPHRA-305: [~anew] [~larsh] [~jamestaylor] [~chandran.poo...@gmail.com] Could I get a review for this ? This is the last known major blocker for an (eventual) Phoenix 5.1 release. > Support HBase 2.1 and 2.2 > - > > Key: TEPHRA-305 > URL: https://issues.apache.org/jira/browse/TEPHRA-305 > Project: Phoenix Tephra > Issue Type: New Feature >Reporter: Istvan Toth >Assignee: Poorna Chandra >Priority: Blocker > Time Spent: 10m > Remaining Estimate: 0h > > Tephra doesn't support anything newer that HBase 2.0. > The current supported HBase 2.x versions are 2.1 and 2.2, 2.0 has been > recently EOMed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-5726) Remove/disable Phoenix_Compile_Compat_wHBase Jenkins job
Istvan Toth created PHOENIX-5726: Summary: Remove/disable Phoenix_Compile_Compat_wHBase Jenkins job Key: PHOENIX-5726 URL: https://issues.apache.org/jira/browse/PHOENIX-5726 Project: Phoenix Issue Type: Task Reporter: Istvan Toth The Jenkins job [https://builds.apache.org/view/M-R/view/Phoenix/job/Phoenix_Compile_Compat_wHBase/] is set to run daily. It seems to have outlived its usefulness by several years, and wile it fails quickly, and does not consume a lot of resources, it should be deactivated or deleted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
