[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238410#comment-15238410 ] churro morales commented on PHOENIX-2833: - unfortunately TableName is final > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PHOENIX-2156) Support drop of column from table with views
[ https://issues.apache.org/jira/browse/PHOENIX-2156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva resolved PHOENIX-2156. - Resolution: Fixed > Support drop of column from table with views > > > Key: PHOENIX-2156 > URL: https://issues.apache.org/jira/browse/PHOENIX-2156 > Project: Phoenix > Issue Type: Sub-task >Reporter: James Taylor >Assignee: Thomas D'Silva > Fix For: 4.8.0 > > Attachments: PHOENIX-2156-v2.patch, PHOENIX-2156-v3.patch, > PHOENIX-2156-v4.patch, PHOENIX-2156.patch > > > Much like PHOENIX-1504 allows a column to be added to a base view, we should > support dropping a column from a table that has views as well. These seems > like a simpler problem: you just need to query for all views with a > BASE_COLUMN_COUNT < dropped_column_ordinal_pos, decrement the ordinal > positions of columns after that, and drop indexes that reference the column > being dropped. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238382#comment-15238382 ] Thomas D'Silva commented on PHOENIX-2833: - It should work if you can override the TableName for index and phoenix system tables. Is there a way to override the TableName? > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238368#comment-15238368 ] ASF GitHub Bot commented on PHOENIX-1311: - Github user JamesRTaylor commented on the pull request: https://github.com/apache/phoenix/pull/153#issuecomment-209173008 There are likely lots of issues if isNamespaceMapping config property changes from true to false, no? Seems like it's meant to enable/disable the feature. Wouldn't existing namespace mapped tables not be found if it was changed from true to false after tables had been created? What would be the purpose of allowing a schema (namespace) to be created if the feature is off? If none, then it's probably best to give an error message if isNamespaceMapping is off and CREATE SCHEMA is used. > HBase namespaces surfaced in phoenix > > > Key: PHOENIX-1311 > URL: https://issues.apache.org/jira/browse/PHOENIX-1311 > Project: Phoenix > Issue Type: New Feature >Reporter: nicolas maillard >Assignee: Ankit Singhal >Priority: Minor > Fix For: 4.8.0 > > Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, > PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch > > > Hbase (HBASE-8015) has the concept of namespaces in the form of > myNamespace:MyTable it would be great if Phoenix leveraged this feature to > give a database like feature on top of the table. > Maybe to stay close to Hbase it could also be a create DB:Table... > or DB.Table which is a more standard annotation? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...
Github user JamesRTaylor commented on the pull request: https://github.com/apache/phoenix/pull/153#issuecomment-209173008 There are likely lots of issues if isNamespaceMapping config property changes from true to false, no? Seems like it's meant to enable/disable the feature. Wouldn't existing namespace mapped tables not be found if it was changed from true to false after tables had been created? What would be the purpose of allowing a schema (namespace) to be created if the feature is off? If none, then it's probably best to give an error message if isNamespaceMapping is off and CREATE SCHEMA is used. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...
Github user samarthjain commented on the pull request: https://github.com/apache/phoenix/pull/153#issuecomment-209165158 Also, how about if we do a CREATE TABLE SCHEMA.TABLENAME with the feature on. Does it end up creating the namespace named SCHEMA first and then maps the table to that namespace. What about if the feature is off. Would be nice to have tests around this or if you already have them can you point me out which ones are testing these? Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238324#comment-15238324 ] ASF GitHub Bot commented on PHOENIX-1311: - Github user samarthjain commented on the pull request: https://github.com/apache/phoenix/pull/153#issuecomment-209165158 Also, how about if we do a CREATE TABLE SCHEMA.TABLENAME with the feature on. Does it end up creating the namespace named SCHEMA first and then maps the table to that namespace. What about if the feature is off. Would be nice to have tests around this or if you already have them can you point me out which ones are testing these? Thanks! > HBase namespaces surfaced in phoenix > > > Key: PHOENIX-1311 > URL: https://issues.apache.org/jira/browse/PHOENIX-1311 > Project: Phoenix > Issue Type: New Feature >Reporter: nicolas maillard >Assignee: Ankit Singhal >Priority: Minor > Fix For: 4.8.0 > > Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, > PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch > > > Hbase (HBASE-8015) has the concept of namespaces in the form of > myNamespace:MyTable it would be great if Phoenix leveraged this feature to > give a database like feature on top of the table. > Maybe to stay close to Hbase it could also be a create DB:Table... > or DB.Table which is a more standard annotation? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15238308#comment-15238308 ] ASF GitHub Bot commented on PHOENIX-1311: - Github user samarthjain commented on the pull request: https://github.com/apache/phoenix/pull/153#issuecomment-209161997 Thanks for the updated request, @ankitsinghal. Almost there! Can you tell me more about what would happen in the following scenario if the name space feature is disabled in config: CREATE SCHEMA S; USE SCHEMA S; CREATE TABLE T; Will the table T be created in the namespace S? If the feature is disabled, it shouldn't be. Would you mind adding a test for this if it hasn't been already? > HBase namespaces surfaced in phoenix > > > Key: PHOENIX-1311 > URL: https://issues.apache.org/jira/browse/PHOENIX-1311 > Project: Phoenix > Issue Type: New Feature >Reporter: nicolas maillard >Assignee: Ankit Singhal >Priority: Minor > Fix For: 4.8.0 > > Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, > PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch > > > Hbase (HBASE-8015) has the concept of namespaces in the form of > myNamespace:MyTable it would be great if Phoenix leveraged this feature to > give a database like feature on top of the table. > Maybe to stay close to Hbase it could also be a create DB:Table... > or DB.Table which is a more standard annotation? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...
Github user samarthjain commented on the pull request: https://github.com/apache/phoenix/pull/153#issuecomment-209161997 Thanks for the updated request, @ankitsinghal. Almost there! Can you tell me more about what would happen in the following scenario if the name space feature is disabled in config: CREATE SCHEMA S; USE SCHEMA S; CREATE TABLE T; Will the table T be created in the namespace S? If the feature is disabled, it shouldn't be. Would you mind adding a test for this if it hasn't been already? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237975#comment-15237975 ] James Taylor commented on PHOENIX-2833: --- Sounds promising, and no, we just need one higher level of priority above normal. Not positive we have the ability to override TableName when we need to. Want to try a patch? [~tdsilva] - do you think this will work? > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237898#comment-15237898 ] churro morales commented on PHOENIX-2833: - Forgive me for being crazy but the RpcControllerFactory is private and what we are doing is prioritizing calls to the index tables and phoenix system tables. It looks like the HIGH_QOS priority is only used for the meta table and other important regionserver related operations (like close region, open region, flush, etc...) which is fine. Because these are table specific operations for those index and phoenix system tables; We could simply extend TableName and override tableName.getSystemTable() to return true which would give a HIGH_QOS priority. I don't think we need something higher priority than META operations because if you can't access META that affects all clients and the cluster is in trouble anyways so given equivalent priority is sufficient. That way we could get rid of quite a bit of HBase code that depends on private hbase API's [~jamestaylor] am I correct in assuming that we don't need a higher priority than HConstants.HIGH_QOS for an RPC call? > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow
[ https://issues.apache.org/jira/browse/PHOENIX-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237896#comment-15237896 ] Hudson commented on PHOENIX-2822: - SUCCESS: Integrated in Phoenix-master #1192 (See [https://builds.apache.org/job/Phoenix-master/1192/]) PHOENIX-2822 Addendum to fix failing tests (Rahul Gidwani) (samarth: rev 0490484b022fd8218e52d6d72858192ef3c59441) * phoenix-core/src/it/java/org/apache/phoenix/end2end/HBaseManagedTimeTableReuseTest.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/LikeExpressionIT.java * phoenix-core/src/it/java/org/apache/phoenix/end2end/BaseHBaseManagedTimeTableReuseIT.java * pom.xml * phoenix-core/src/it/java/org/apache/phoenix/end2end/HBaseManagedTimeTest.java > Tests that extend BaseHBaseManagedTimeIT are very slow > -- > > Key: PHOENIX-2822 > URL: https://issues.apache.org/jira/browse/PHOENIX-2822 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2822-98.patch, PHOENIX-2822.addendum, > PHOENIX-2822.addendum-v1.patch, PHOENIX-2822.patch > > > Since I am trying to refactor out all the hbase private dependencies, I have > to constantly run tests to make sure I didn't break anything. The tests that > extend BaseHBaseManagedTimeIT are very slow as they have to delete all > non-system tables after every test case. This takes around 5-10 seconds to > accomplish. This adds significant time to the test suite. > I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates > a random table name such that we dont have collisions for tests. It also > doesn't do any cleanup after each test case or class because these table > names should be unique. I moved about 30-35 tests out from > BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it > significantly improved the overall time it takes to run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[
https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237812#comment-15237812
]
churro morales commented on PHOENIX-2833:
-
Okay this might be a bigger discussion:
As stated in: https://hbase.apache.org/book.html#hbase.versioning
{quote} LimitedPrivate annotation comes with a set of target consumers for the
interfaces. Those consumers are coprocessors, phoenix, replication endpoint
implementations or similar. At this point, HBase only guarantees source and
binary compatibility for these interfaces between patch versions. {quote}
> Upgrade HBase dependency to version 1.2.0
> -
>
> Key: PHOENIX-2833
> URL: https://issues.apache.org/jira/browse/PHOENIX-2833
> Project: Phoenix
> Issue Type: Task
>Affects Versions: 4.8.0
>Reporter: Rob Leidle
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: upgrade-to-hbase-1.2.0.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The
> Phoenix version is changed to reflect the HBase change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (PHOENIX-2822) Tests that extend BaseHBaseManagedTimeIT are very slow
[ https://issues.apache.org/jira/browse/PHOENIX-2822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] churro morales updated PHOENIX-2822: Attachment: PHOENIX-2822.addendum-v1.patch [~samarth.j...@gmail.com] Put the tests that generate random tables in their own category and all tests now pass. Note this patch is based off 4.x-HBase-0.98 but should apply across all branches. > Tests that extend BaseHBaseManagedTimeIT are very slow > -- > > Key: PHOENIX-2822 > URL: https://issues.apache.org/jira/browse/PHOENIX-2822 > Project: Phoenix > Issue Type: Improvement >Affects Versions: 4.8.0 >Reporter: churro morales >Assignee: churro morales > Labels: HBASEDEPENDENCIES > Attachments: PHOENIX-2822-98.patch, PHOENIX-2822.addendum, > PHOENIX-2822.addendum-v1.patch, PHOENIX-2822.patch > > > Since I am trying to refactor out all the hbase private dependencies, I have > to constantly run tests to make sure I didn't break anything. The tests that > extend BaseHBaseManagedTimeIT are very slow as they have to delete all > non-system tables after every test case. This takes around 5-10 seconds to > accomplish. This adds significant time to the test suite. > I created a new class named: BaseHBaseManagedTimeTableReuseIT and it creates > a random table name such that we dont have collisions for tests. It also > doesn't do any cleanup after each test case or class because these table > names should be unique. I moved about 30-35 tests out from > BaseHBaseManagedTimeIT to BaseHBaseManagedTimeTableReuseIT and it > significantly improved the overall time it takes to run tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[
https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237776#comment-15237776
]
Hadoop QA commented on PHOENIX-2833:
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12798320/upgrade-to-hbase-1.2.0.patch
against master branch at commit bbcdd2a3418216c4da0b39af74e833f5cc60fc4d.
ATTACHMENT ID: 12798320
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
25 warning messages.
{color:red}-1 release audit{color}. The applied patch generated 1 release
audit warnings (more than the master's current 0 warnings).
{color:green}+1 lineLengths{color}. The patch does not introduce lines
longer than 100
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.PhoenixRuntimeIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.hadoop.hbase.regionserver.wal.WALReplayWithIndexWritesAndCompressedWALIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.PointInTimeQueryIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.DropMetadataIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.SkipScanAfterManualSplitIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.iterate.RoundRobinResultIteratorIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.rpc.UpdateCacheIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.hadoop.hbase.regionserver.wal.WALReplayWithIndexWritesAndUncompressedWALInHBase_094_9_IT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.LikeExpressionIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/298//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/298//artifact/patchprocess/patchReleaseAuditWarnings.txt
Javadoc warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/298//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/298//console
This message is automatically generated.
> Upgrade HBase dependency to version 1.2.0
> -
>
> Key: PHOENIX-2833
> URL: https://issues.apache.org/jira/browse/PHOENIX-2833
> Project: Phoenix
> Issue Type: Task
>Affects Versions: 4.8.0
>Reporter: Rob Leidle
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: upgrade-to-hbase-1.2.0.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The
> Phoenix version is changed to reflect the HBase change.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237774#comment-15237774 ] Rob Leidle commented on PHOENIX-2833: - churro morales: I am willing to make changes if necessary. It seems like something as heavy-weight as a "shim" would be less than desirable, but I can take a look at any approach you think might be best. > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237771#comment-15237771 ] churro morales commented on PHOENIX-2833: - [~jamestaylor] RpcScheduler.dispatch() API changed across versions unfortunately. In the PhoenixRpcScheduler we reference RpcExecutors directly which is bad because they are both @Private and @Evolving let me see if there is a way we can make this work. Maybe there is a way we can delegate instead of inherit, but I'm not sure yet. I'll look into this. > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237753#comment-15237753 ] Rob Leidle commented on PHOENIX-2833: - It will break HBase 1.1 due to the interface change in HBase's RpcScheduler (returns boolean instead of void now) > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237748#comment-15237748 ] James Taylor commented on PHOENIX-2833: --- [~churromorales] - WDYT? Will this continue to work with HBase 1.1.x? > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
Rob Leidle created PHOENIX-2833: --- Summary: Upgrade HBase dependency to version 1.2.0 Key: PHOENIX-2833 URL: https://issues.apache.org/jira/browse/PHOENIX-2833 Project: Phoenix Issue Type: Task Affects Versions: 4.8.0 Reporter: Rob Leidle Priority: Minor Fix For: 4.8.0 Attachments: upgrade-to-hbase-1.2.0.patch This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PHOENIX-2833) Upgrade HBase dependency to version 1.2.0
[ https://issues.apache.org/jira/browse/PHOENIX-2833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Leidle updated PHOENIX-2833: Attachment: upgrade-to-hbase-1.2.0.patch > Upgrade HBase dependency to version 1.2.0 > - > > Key: PHOENIX-2833 > URL: https://issues.apache.org/jira/browse/PHOENIX-2833 > Project: Phoenix > Issue Type: Task >Affects Versions: 4.8.0 >Reporter: Rob Leidle >Priority: Minor > Fix For: 4.8.0 > > Attachments: upgrade-to-hbase-1.2.0.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > This patch upgrades Phoenix’s HBase dependency version from 1.1 to 1.2. The > Phoenix version is changed to reflect the HBase change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix
[ https://issues.apache.org/jira/browse/PHOENIX-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237315#comment-15237315 ] ASF GitHub Bot commented on PHOENIX-1311: - Github user ankitsinghal commented on the pull request: https://github.com/apache/phoenix/pull/153#issuecomment-208944403 @samarthjain , thanks for the review. I'm unsure about disabling schema constructs if isNamespaceMapping is not enabled in config. As this property is client side property and even if it is unset , user can still access the table mapped to namespace created by another client which has this property set. This property just ensure schema mapping to namespace during creation of table. I think these constructs still make sense independently. but @JamesRTaylor / @samarthjain , if you guys think of disabling it , I'm ok with that too. > HBase namespaces surfaced in phoenix > > > Key: PHOENIX-1311 > URL: https://issues.apache.org/jira/browse/PHOENIX-1311 > Project: Phoenix > Issue Type: New Feature >Reporter: nicolas maillard >Assignee: Ankit Singhal >Priority: Minor > Fix For: 4.8.0 > > Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch, > PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch > > > Hbase (HBASE-8015) has the concept of namespaces in the form of > myNamespace:MyTable it would be great if Phoenix leveraged this feature to > give a database like feature on top of the table. > Maybe to stay close to Hbase it could also be a create DB:Table... > or DB.Table which is a more standard annotation? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...
Github user ankitsinghal commented on the pull request: https://github.com/apache/phoenix/pull/153#issuecomment-208944403 @samarthjain , thanks for the review. I'm unsure about disabling schema constructs if isNamespaceMapping is not enabled in config. As this property is client side property and even if it is unset , user can still access the table mapped to namespace created by another client which has this property set. This property just ensure schema mapping to namespace during creation of table. I think these constructs still make sense independently. but @JamesRTaylor / @samarthjain , if you guys think of disabling it , I'm ok with that too. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237288#comment-15237288
]
ASF GitHub Bot commented on PHOENIX-1311:
-
Github user ankitsinghal commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/153#discussion_r59387189
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java ---
@@ -1279,4 +1304,129 @@ public static boolean truncateStats(HTableInterface
metaTable, HTableInterface s
}
return false;
}
+
+public static void mapTableToNamespace(HBaseAdmin admin,
HTableInterface metatable, String srcTableName,
+String destTableName, ReadOnlyProps props, Long ts, String
phoenixTableName, PTableType pTableType)
+throws SnapshotCreationException,
IllegalArgumentException, IOException, InterruptedException,
+SQLException {
+srcTableName = SchemaUtil.normalizeIdentifier(srcTableName);
+if (!SchemaUtil.isNamespaceMappingEnabled(
+SchemaUtil.isSystemTable(srcTableName.getBytes()) ?
PTableType.SYSTEM : null,
+props)) { throw new
IllegalArgumentException(SchemaUtil.isSystemTable(srcTableName.getBytes())
+? "For system table " +
QueryServices.IS_SYSTEM_TABLE_MAPPED_TO_NAMESPACE
++ " also needs to be enabled along with "
+ QueryServices.IS_NAMESPACE_MAPPING_ENABLED
+: QueryServices.IS_NAMESPACE_MAPPING_ENABLED + "
is not enabled"); }
+
+if (PTableType.TABLE.equals(pTableType) ||
PTableType.INDEX.equals(pTableType)) {
+admin.snapshot(srcTableName, srcTableName);
+admin.cloneSnapshot(srcTableName.getBytes(),
destTableName.getBytes());
+admin.disableTable(srcTableName);
--- End diff --
ok.. I have added a code to delete the snapshot.
Re-trying from the phoenix snapshot would be risky.. if let's say, upgrade
got failed and user keep on using the un-mapped table for a while and then he
again go for upgrade, the snapshot taken in last upgrade will be obsolete.
> HBase namespaces surfaced in phoenix
>
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
> Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch,
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...
Github user ankitsinghal commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/153#discussion_r59387189
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/util/UpgradeUtil.java ---
@@ -1279,4 +1304,129 @@ public static boolean truncateStats(HTableInterface
metaTable, HTableInterface s
}
return false;
}
+
+public static void mapTableToNamespace(HBaseAdmin admin,
HTableInterface metatable, String srcTableName,
+String destTableName, ReadOnlyProps props, Long ts, String
phoenixTableName, PTableType pTableType)
+throws SnapshotCreationException,
IllegalArgumentException, IOException, InterruptedException,
+SQLException {
+srcTableName = SchemaUtil.normalizeIdentifier(srcTableName);
+if (!SchemaUtil.isNamespaceMappingEnabled(
+SchemaUtil.isSystemTable(srcTableName.getBytes()) ?
PTableType.SYSTEM : null,
+props)) { throw new
IllegalArgumentException(SchemaUtil.isSystemTable(srcTableName.getBytes())
+? "For system table " +
QueryServices.IS_SYSTEM_TABLE_MAPPED_TO_NAMESPACE
++ " also needs to be enabled along with "
+ QueryServices.IS_NAMESPACE_MAPPING_ENABLED
+: QueryServices.IS_NAMESPACE_MAPPING_ENABLED + "
is not enabled"); }
+
+if (PTableType.TABLE.equals(pTableType) ||
PTableType.INDEX.equals(pTableType)) {
+admin.snapshot(srcTableName, srcTableName);
+admin.cloneSnapshot(srcTableName.getBytes(),
destTableName.getBytes());
+admin.disableTable(srcTableName);
--- End diff --
ok.. I have added a code to delete the snapshot.
Re-trying from the phoenix snapshot would be risky.. if let's say, upgrade
got failed and user keep on using the un-mapped table for a while and then he
again go for upgrade, the snapshot taken in last upgrade will be obsolete.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Commented] (PHOENIX-1311) HBase namespaces surfaced in phoenix
[
https://issues.apache.org/jira/browse/PHOENIX-1311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237277#comment-15237277
]
ASF GitHub Bot commented on PHOENIX-1311:
-
Github user ankitsinghal commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/153#discussion_r59386509
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/schema/PTableKey.java ---
@@ -26,7 +28,8 @@
public PTableKey(PName tenantId, String name) {
Preconditions.checkNotNull(name);
this.tenantId = tenantId;
-this.name = name;
+this.name = !name.contains(QueryConstants.NAMESPACE_SEPARATOR) ?
name
--- End diff --
agreed.. removed in latest commit.
> HBase namespaces surfaced in phoenix
>
>
> Key: PHOENIX-1311
> URL: https://issues.apache.org/jira/browse/PHOENIX-1311
> Project: Phoenix
> Issue Type: New Feature
>Reporter: nicolas maillard
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-1311.docx, PHOENIX-1311_v1.patch,
> PHOENIX-1311_v2.patch, PHOENIX-1311_wip.patch, PHOENIX-1311_wip_2.patch
>
>
> Hbase (HBASE-8015) has the concept of namespaces in the form of
> myNamespace:MyTable it would be great if Phoenix leveraged this feature to
> give a database like feature on top of the table.
> Maybe to stay close to Hbase it could also be a create DB:Table...
> or DB.Table which is a more standard annotation?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] phoenix pull request: PHOENIX-1311 HBase namespaces surfaced in ph...
Github user ankitsinghal commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/153#discussion_r59386509
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/schema/PTableKey.java ---
@@ -26,7 +28,8 @@
public PTableKey(PName tenantId, String name) {
Preconditions.checkNotNull(name);
this.tenantId = tenantId;
-this.name = name;
+this.name = !name.contains(QueryConstants.NAMESPACE_SEPARATOR) ?
name
--- End diff --
agreed.. removed in latest commit.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] phoenix pull request: PHOENIX-2722 support mysql limit,offset clau...
Github user ankitsinghal closed the pull request at: https://github.com/apache/phoenix/pull/154 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (PHOENIX-2722) support mysql "limit,offset" clauses
[
https://issues.apache.org/jira/browse/PHOENIX-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237250#comment-15237250
]
ASF GitHub Bot commented on PHOENIX-2722:
-
Github user ankitsinghal closed the pull request at:
https://github.com/apache/phoenix/pull/154
> support mysql "limit,offset" clauses
> -
>
> Key: PHOENIX-2722
> URL: https://issues.apache.org/jira/browse/PHOENIX-2722
> Project: Phoenix
> Issue Type: New Feature
>Reporter: Ankit Singhal
>Assignee: Ankit Singhal
>Priority: Minor
> Fix For: 4.8.0
>
> Attachments: PHOENIX-2722.patch, PHOENIX-2722_formatted.patch,
> PHOENIX-2722_v1_rebased.patch
>
>
> For serial query(query with “serial" hint or “limit" without "order by”), we
> can limit each scan(using page filter) to “limit+offset” instead of limit
> earlier.
> And then, for all queries, we can forward the relevant client iterators to
> the offset provided and then return the result.
> syntax
> {code}
> [ LIMIT { count } ]
> [ OFFSET start [ ROW | ROWS ] ]
> [ FETCH { FIRST | NEXT } [ count ] { ROW | ROWS } ONLY ]
> {code}
> Some new keywords(OFFSET,FETCH,ROW, ROWS,ONLY) are getting introduced so
> users might need to see that they are not using them as column name or
> something.
> WDYT, [~jamestaylor]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)
[ https://issues.apache.org/jira/browse/PHOENIX-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237099#comment-15237099 ] Enis Soztutar commented on PHOENIX-2535: bq. FYI, although we specify Guava 13 in our pom, Tephra works with Guava 12 too, a requirement we had since HBase uses an older version. Guava is one of the worst offenders in terms of breaking binary compatibility, and is generally the reason (among jackson, PB and a few others) that the clients require shading. Not having guava shading will be a half-solution I think. > Create shaded clients (thin + thick) > - > > Key: PHOENIX-2535 > URL: https://issues.apache.org/jira/browse/PHOENIX-2535 > Project: Phoenix > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Sergey Soldatov > Fix For: 4.8.0 > > Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, > PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch > > > Having shaded client artifacts helps greatly in minimizing the dependency > conflicts at the run time. We are seeing more of Phoenix JDBC client being > used in Storm topologies and other settings where guava versions become a > problem. > I think we can do a parallel artifact for the thick client with shaded > dependencies and also using shaded hbase. For thin client, maybe shading > should be the default since it is new? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PHOENIX-2535) Create shaded clients (thin + thick)
[ https://issues.apache.org/jira/browse/PHOENIX-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15237095#comment-15237095 ] Enis Soztutar commented on PHOENIX-2535: bq. I know some of these Enis Soztutar already pointed out (mortbay, specifically), but com.google.common, pig/flume/hadoop/hbase, asm, and jersey worry me Not sure about the HBase dependency, but we can assume that if a client wants to depend on Phoenix, they will also want to depend on HBase. Since Phoenix version and HBase version HAS TO go together, I think the HBase non-shaded dependency is fine. Flume, Pig and (upcoming Hive) should not be shaded, otherwise the integration will not work. For example, phoenix-flume implements Sources and Sinks which are flume classes. Good thing is that these are already different modules, so that regular clients do not have to depend on these modules. > Create shaded clients (thin + thick) > - > > Key: PHOENIX-2535 > URL: https://issues.apache.org/jira/browse/PHOENIX-2535 > Project: Phoenix > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Sergey Soldatov > Fix For: 4.8.0 > > Attachments: PHOENIX-2535-1.patch, PHOENIX-2535-2.patch, > PHOENIX-2535-3.patch, PHOENIX-2535-4.patch, PHOENIX-2535-5.patch > > > Having shaded client artifacts helps greatly in minimizing the dependency > conflicts at the run time. We are seeing more of Phoenix JDBC client being > used in Storm topologies and other settings where guava versions become a > problem. > I think we can do a parallel artifact for the thick client with shaded > dependencies and also using shaded hbase. For thin client, maybe shading > should be the default since it is new? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
