[jira] [Created] (PHOENIX-5167) Fix LGTM alerts
Malcolm Taylor created PHOENIX-5167: --- Summary: Fix LGTM alerts Key: PHOENIX-5167 URL: https://issues.apache.org/jira/browse/PHOENIX-5167 Project: Phoenix Issue Type: Improvement Reporter: Malcolm Taylor I work for Semmle, the company behind LGTM. During our analysis of apache/phoenix, LGTM raised some alerts ([https://lgtm.com/projects/g/apache/phoenix/alerts/?mode=tree).] This issue is to fix some of the more straightforward ones. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (PHOENIX-2265) Disallow creation of view over HBase table if PK not specified
[
https://issues.apache.org/jira/browse/PHOENIX-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xinyi Yan updated PHOENIX-2265:
---
Attachment: PHOENIX-2265-master-2.patch
> Disallow creation of view over HBase table if PK not specified
> --
>
> Key: PHOENIX-2265
> URL: https://issues.apache.org/jira/browse/PHOENIX-2265
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Xinyi Yan
>Priority: Major
> Labels: newbie
> Attachments: PHOENIX-2265-master-2.patch, PHOENIX-2265-master.patch,
> PHOENIX-2265.patch, PHOENIX-2265.patch
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We currently allow a Phoenix view to be defined over an HBase table without
> specifying a primary key.
> To repro, create an HBase table in the HBase shell:
> {code}
> create 'hb1', 'f1'
> {code}
> Then create a view in Phoenix:
> {code}
> create view "hb1"("f1".a varchar);
> {code}
> This should yield an error, as we haven't specified a primary key.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-2265) Disallow creation of view over HBase table if PK not specified
[
https://issues.apache.org/jira/browse/PHOENIX-2265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xinyi Yan updated PHOENIX-2265:
---
Attachment: PHOENIX-2265-master.patch
> Disallow creation of view over HBase table if PK not specified
> --
>
> Key: PHOENIX-2265
> URL: https://issues.apache.org/jira/browse/PHOENIX-2265
> Project: Phoenix
> Issue Type: Bug
>Reporter: James Taylor
>Assignee: Xinyi Yan
>Priority: Major
> Labels: newbie
> Attachments: PHOENIX-2265-master.patch, PHOENIX-2265.patch,
> PHOENIX-2265.patch
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We currently allow a Phoenix view to be defined over an HBase table without
> specifying a primary key.
> To repro, create an HBase table in the HBase shell:
> {code}
> create 'hb1', 'f1'
> {code}
> Then create a view in Phoenix:
> {code}
> create view "hb1"("f1".a varchar);
> {code}
> This should yield an error, as we haven't specified a primary key.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-5137) Index Rebuilder scan increases data table region split time
[
https://issues.apache.org/jira/browse/PHOENIX-5137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kiran Kumar Maturi updated PHOENIX-5137:
Attachment: PHOENIX-5137-master.01.patch
> Index Rebuilder scan increases data table region split time
> ---
>
> Key: PHOENIX-5137
> URL: https://issues.apache.org/jira/browse/PHOENIX-5137
> Project: Phoenix
> Issue Type: Bug
>Affects Versions: 4.14.1
>Reporter: Kiran Kumar Maturi
>Assignee: Kiran Kumar Maturi
>Priority: Major
> Attachments: PHOENIX-5137-4.14-HBase-1.3.02.patch,
> PHOENIX-5137-4.14-Hbase-1.3.01.patch, PHOENIX-5137-4.14-Hbase-1.3.01.patch,
> PHOENIX-5137-4.x-HBase-1.3.01.patch, PHOENIX-5137-master.01.patch
>
>
> [~lhofhansl] [~vincentpoon] [~tdsilva] please review
> In order to differentiate between the index rebuilder retries
> (UngroupedAggregateRegionObserver.rebuildIndices()) and commits that happen
> in the loop of UngroupedAggregateRegionObserver.doPostScannerOpen() as part
> of PHOENIX-4600 blockingMemstoreSize was set to -1 for rebuildIndices;
> {code:java}
> commitBatchWithRetries(region, mutations, -1);{code}
> blocks the region split as the check for region closing does not happen
> blockingMemstoreSize > 0
> {code:java}
> for (int i = 0; blockingMemstoreSize > 0 && region.getMemstoreSize() >
> blockingMemstoreSize && i < 30; i++) {
> try{
>checkForRegionClosing();
>
> {code}
> Plan is to have the check for region closing at least once before committing
> the batch
> {code:java}
> checkForRegionClosing();
> for (int i = 0; blockingMemstoreSize > 0 && region.getMemstoreSize() >
> blockingMemstoreSize && i < 30; i++) {
> try{
>checkForRegionClosing();
>
> {code}
> Steps to reproduce
> 1. Create a table with one index (startime)
> 2. Add 1-2 million rows
> 3. Wait till the index is active
> 4. Disable the index with start time (noted in step 1)
> 5. Once the rebuilder starts split data table region
> Repeat the steps again after applying the patch to check the difference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (PHOENIX-1614) ALTER TABLE ADD IF NOT EXISTS doesn't work as expected
[ https://issues.apache.org/jira/browse/PHOENIX-1614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Toshihiro Suzuki updated PHOENIX-1614: -- Attachment: PHOENIX-1614.patch > ALTER TABLE ADD IF NOT EXISTS doesn't work as expected > -- > > Key: PHOENIX-1614 > URL: https://issues.apache.org/jira/browse/PHOENIX-1614 > Project: Phoenix > Issue Type: Bug >Reporter: Gabriel Reid >Assignee: Toshihiro Suzuki >Priority: Major > Labels: argus > Fix For: 4.15.0 > > Attachments: PHOENIX-1614.patch > > > On an existing table table, executing "ALTER TABLE ADD IF NOT EXISTS > thisColAlreadyExists varchar, thisColDoesNotExist varchar", then > nothing will be changed in the table because thisColAlreadyExists > already exists. > Omitting the already-existing column from the statement, all new columns > do get created. > The general expectation would be that when you use ADD IF NOT EXISTS, all > non-existent columns will be added, and all existing columns in the > statement will just be ignored. There is already an integration test > (AlterTableIT#testAddVarCols) that actually demonstrates the current > behavior, although this is probably not correct. > As pointed out in the related mailing list thread [1], ALTER TABLE DROP > COLUMN likely suffers from the same issue. > 1. http://s.apache.org/LMT -- This message was sent by Atlassian JIRA (v7.6.3#76005)
