[jira] [Created] (PHOENIX-6098) IndexPredicateAnalyzer wrongly handles pushdown predicates and residual predicates
Toshihiro Suzuki created PHOENIX-6098: - Summary: IndexPredicateAnalyzer wrongly handles pushdown predicates and residual predicates Key: PHOENIX-6098 URL: https://issues.apache.org/jira/browse/PHOENIX-6098 Project: Phoenix Issue Type: Bug Components: hive-connector Reporter: Toshihiro Suzuki Assignee: Toshihiro Suzuki Currently, the following code of IndexPredicateAnalyzer is assuming that GenericUDFOPAnd always has 2 children nodes. I think this is wrong and it leads wrong results: https://github.com/apache/phoenix-connectors/blob/5bd23ae2a0f70c3b3edf92a53780dafa643faf26/phoenix-hive/src/main/java/org/apache/phoenix/hive/ql/index/IndexPredicateAnalyzer.java#L346-L359 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6056) Migrate from builds.apache.org by August 15
[
https://issues.apache.org/jira/browse/PHOENIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-6056:
-
Attachment: PHOENIX-6056.master.v3.patch
> Migrate from builds.apache.org by August 15
> ---
>
> Key: PHOENIX-6056
> URL: https://issues.apache.org/jira/browse/PHOENIX-6056
> Project: Phoenix
> Issue Type: Task
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Blocker
> Attachments: PHOENIX-6056.master.v1.patch,
> PHOENIX-6056.master.v2.patch, PHOENIX-6056.master.v3.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> Hi All,
> This NOTICE is for everyone on builds.apache.org. We are migrating to a new
> Cloudbees based Client Master called https://ci-builds.apache.org. The
> migrations of all jobs needs to be done before the switch off date of 15th
> August 2020, so you have a maximum of 4 weeks.
> There is no tool or automated way of migrating your jobs, the
> differences in the platforms, the plugins and the setup makes it impossible
> to do in a safe way. So, you all need to start creating new jobs on
> ci-infra.a.o and then , when you are happy, turn off your old builds on
> builds.a.o.
> There are currently 4 agents over there ready to take jobs, plus a floating
> agent which is shared amongst many masters (more to come). I will migrate
> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> will keep an eye of load across both and adjust accordingly.
> If needed, create a ticket on INFRA jira for any issues that crop up, or
> email here on builds@a.o. there may be one or two plugins we need to
> install/tweak etc.
> We will be not using 'Views' at the top level, but rather we will take
> advantage of 'Folders Plus' - each project will get its own Folder and have
> authorisation access to create/edit jobs etc within that folder. I will
> create these folders as you ask for them to start with. This setup allows
> for credentials isolation amongst other benefits, including but not limited
> to exclusive agents (Controlled Agents) for your own use , should you have
> any project targeted donations of agents.
> As with other aspects of the ASF, projects can choose to just enable all
> committers access to their folder, just ask.
> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
> be setting up any forwarding rules or anything like that.
> So, please, get started *now *on this so you can be sure we are all
> completed before the final cutoff date of 15th August 2020.
> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> tickets.
> Hadoop and related projects have their own migration path to follow, same
> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
> very well in their new homes.
> Lets get going ...
> --
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (PHOENIX-6056) Migrate from builds.apache.org by August 15
[
https://issues.apache.org/jira/browse/PHOENIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth reopened PHOENIX-6056:
--
Reopening to test changes to Precommit script
> Migrate from builds.apache.org by August 15
> ---
>
> Key: PHOENIX-6056
> URL: https://issues.apache.org/jira/browse/PHOENIX-6056
> Project: Phoenix
> Issue Type: Task
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Blocker
> Attachments: PHOENIX-6056.master.v1.patch,
> PHOENIX-6056.master.v2.patch, PHOENIX-6056.master.v3.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> Hi All,
> This NOTICE is for everyone on builds.apache.org. We are migrating to a new
> Cloudbees based Client Master called https://ci-builds.apache.org. The
> migrations of all jobs needs to be done before the switch off date of 15th
> August 2020, so you have a maximum of 4 weeks.
> There is no tool or automated way of migrating your jobs, the
> differences in the platforms, the plugins and the setup makes it impossible
> to do in a safe way. So, you all need to start creating new jobs on
> ci-infra.a.o and then , when you are happy, turn off your old builds on
> builds.a.o.
> There are currently 4 agents over there ready to take jobs, plus a floating
> agent which is shared amongst many masters (more to come). I will migrate
> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> will keep an eye of load across both and adjust accordingly.
> If needed, create a ticket on INFRA jira for any issues that crop up, or
> email here on builds@a.o. there may be one or two plugins we need to
> install/tweak etc.
> We will be not using 'Views' at the top level, but rather we will take
> advantage of 'Folders Plus' - each project will get its own Folder and have
> authorisation access to create/edit jobs etc within that folder. I will
> create these folders as you ask for them to start with. This setup allows
> for credentials isolation amongst other benefits, including but not limited
> to exclusive agents (Controlled Agents) for your own use , should you have
> any project targeted donations of agents.
> As with other aspects of the ASF, projects can choose to just enable all
> committers access to their folder, just ask.
> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
> be setting up any forwarding rules or anything like that.
> So, please, get started *now *on this so you can be sure we are all
> completed before the final cutoff date of 15th August 2020.
> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> tickets.
> Hadoop and related projects have their own migration path to follow, same
> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
> very well in their new homes.
> Lets get going ...
> --
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6056) Migrate from builds.apache.org by August 15
[
https://issues.apache.org/jira/browse/PHOENIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-6056:
-
Attachment: (was: PHOENIX-6056.master.v3.patch)
> Migrate from builds.apache.org by August 15
> ---
>
> Key: PHOENIX-6056
> URL: https://issues.apache.org/jira/browse/PHOENIX-6056
> Project: Phoenix
> Issue Type: Task
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Blocker
> Attachments: PHOENIX-6056.master.v1.patch,
> PHOENIX-6056.master.v2.patch, PHOENIX-6056.master.v3.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> Hi All,
> This NOTICE is for everyone on builds.apache.org. We are migrating to a new
> Cloudbees based Client Master called https://ci-builds.apache.org. The
> migrations of all jobs needs to be done before the switch off date of 15th
> August 2020, so you have a maximum of 4 weeks.
> There is no tool or automated way of migrating your jobs, the
> differences in the platforms, the plugins and the setup makes it impossible
> to do in a safe way. So, you all need to start creating new jobs on
> ci-infra.a.o and then , when you are happy, turn off your old builds on
> builds.a.o.
> There are currently 4 agents over there ready to take jobs, plus a floating
> agent which is shared amongst many masters (more to come). I will migrate
> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> will keep an eye of load across both and adjust accordingly.
> If needed, create a ticket on INFRA jira for any issues that crop up, or
> email here on builds@a.o. there may be one or two plugins we need to
> install/tweak etc.
> We will be not using 'Views' at the top level, but rather we will take
> advantage of 'Folders Plus' - each project will get its own Folder and have
> authorisation access to create/edit jobs etc within that folder. I will
> create these folders as you ask for them to start with. This setup allows
> for credentials isolation amongst other benefits, including but not limited
> to exclusive agents (Controlled Agents) for your own use , should you have
> any project targeted donations of agents.
> As with other aspects of the ASF, projects can choose to just enable all
> committers access to their folder, just ask.
> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
> be setting up any forwarding rules or anything like that.
> So, please, get started *now *on this so you can be sure we are all
> completed before the final cutoff date of 15th August 2020.
> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> tickets.
> Hadoop and related projects have their own migration path to follow, same
> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
> very well in their new homes.
> Lets get going ...
> --
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6056) Migrate from builds.apache.org by August 15
[
https://issues.apache.org/jira/browse/PHOENIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-6056:
-
Attachment: (was: PHOENIX-6056.master.v3.patch)
> Migrate from builds.apache.org by August 15
> ---
>
> Key: PHOENIX-6056
> URL: https://issues.apache.org/jira/browse/PHOENIX-6056
> Project: Phoenix
> Issue Type: Task
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Critical
> Attachments: PHOENIX-6056.master.v1.patch,
> PHOENIX-6056.master.v2.patch, PHOENIX-6056.master.v3.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> Hi All,
> This NOTICE is for everyone on builds.apache.org. We are migrating to a new
> Cloudbees based Client Master called https://ci-builds.apache.org. The
> migrations of all jobs needs to be done before the switch off date of 15th
> August 2020, so you have a maximum of 4 weeks.
> There is no tool or automated way of migrating your jobs, the
> differences in the platforms, the plugins and the setup makes it impossible
> to do in a safe way. So, you all need to start creating new jobs on
> ci-infra.a.o and then , when you are happy, turn off your old builds on
> builds.a.o.
> There are currently 4 agents over there ready to take jobs, plus a floating
> agent which is shared amongst many masters (more to come). I will migrate
> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> will keep an eye of load across both and adjust accordingly.
> If needed, create a ticket on INFRA jira for any issues that crop up, or
> email here on builds@a.o. there may be one or two plugins we need to
> install/tweak etc.
> We will be not using 'Views' at the top level, but rather we will take
> advantage of 'Folders Plus' - each project will get its own Folder and have
> authorisation access to create/edit jobs etc within that folder. I will
> create these folders as you ask for them to start with. This setup allows
> for credentials isolation amongst other benefits, including but not limited
> to exclusive agents (Controlled Agents) for your own use , should you have
> any project targeted donations of agents.
> As with other aspects of the ASF, projects can choose to just enable all
> committers access to their folder, just ask.
> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
> be setting up any forwarding rules or anything like that.
> So, please, get started *now *on this so you can be sure we are all
> completed before the final cutoff date of 15th August 2020.
> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> tickets.
> Hadoop and related projects have their own migration path to follow, same
> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
> very well in their new homes.
> Lets get going ...
> --
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6056) Migrate from builds.apache.org by August 15
[
https://issues.apache.org/jira/browse/PHOENIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-6056:
-
Attachment: PHOENIX-6056.master.v3.patch
> Migrate from builds.apache.org by August 15
> ---
>
> Key: PHOENIX-6056
> URL: https://issues.apache.org/jira/browse/PHOENIX-6056
> Project: Phoenix
> Issue Type: Task
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Critical
> Attachments: PHOENIX-6056.master.v1.patch,
> PHOENIX-6056.master.v2.patch, PHOENIX-6056.master.v3.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> Hi All,
> This NOTICE is for everyone on builds.apache.org. We are migrating to a new
> Cloudbees based Client Master called https://ci-builds.apache.org. The
> migrations of all jobs needs to be done before the switch off date of 15th
> August 2020, so you have a maximum of 4 weeks.
> There is no tool or automated way of migrating your jobs, the
> differences in the platforms, the plugins and the setup makes it impossible
> to do in a safe way. So, you all need to start creating new jobs on
> ci-infra.a.o and then , when you are happy, turn off your old builds on
> builds.a.o.
> There are currently 4 agents over there ready to take jobs, plus a floating
> agent which is shared amongst many masters (more to come). I will migrate
> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> will keep an eye of load across both and adjust accordingly.
> If needed, create a ticket on INFRA jira for any issues that crop up, or
> email here on builds@a.o. there may be one or two plugins we need to
> install/tweak etc.
> We will be not using 'Views' at the top level, but rather we will take
> advantage of 'Folders Plus' - each project will get its own Folder and have
> authorisation access to create/edit jobs etc within that folder. I will
> create these folders as you ask for them to start with. This setup allows
> for credentials isolation amongst other benefits, including but not limited
> to exclusive agents (Controlled Agents) for your own use , should you have
> any project targeted donations of agents.
> As with other aspects of the ASF, projects can choose to just enable all
> committers access to their folder, just ask.
> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
> be setting up any forwarding rules or anything like that.
> So, please, get started *now *on this so you can be sure we are all
> completed before the final cutoff date of 15th August 2020.
> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> tickets.
> Hadoop and related projects have their own migration path to follow, same
> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
> very well in their new homes.
> Lets get going ...
> --
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (PHOENIX-6056) Migrate from builds.apache.org by August 15
[
https://issues.apache.org/jira/browse/PHOENIX-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated PHOENIX-6056:
-
Priority: Critical (was: Blocker)
> Migrate from builds.apache.org by August 15
> ---
>
> Key: PHOENIX-6056
> URL: https://issues.apache.org/jira/browse/PHOENIX-6056
> Project: Phoenix
> Issue Type: Task
>Reporter: Istvan Toth
>Assignee: Istvan Toth
>Priority: Critical
> Attachments: PHOENIX-6056.master.v1.patch,
> PHOENIX-6056.master.v2.patch, PHOENIX-6056.master.v3.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> Hi All,
> This NOTICE is for everyone on builds.apache.org. We are migrating to a new
> Cloudbees based Client Master called https://ci-builds.apache.org. The
> migrations of all jobs needs to be done before the switch off date of 15th
> August 2020, so you have a maximum of 4 weeks.
> There is no tool or automated way of migrating your jobs, the
> differences in the platforms, the plugins and the setup makes it impossible
> to do in a safe way. So, you all need to start creating new jobs on
> ci-infra.a.o and then , when you are happy, turn off your old builds on
> builds.a.o.
> There are currently 4 agents over there ready to take jobs, plus a floating
> agent which is shared amongst many masters (more to come). I will migrate
> away 2 more agents from builds.a.o to ci-builds.a.o every few days, and
> will keep an eye of load across both and adjust accordingly.
> If needed, create a ticket on INFRA jira for any issues that crop up, or
> email here on builds@a.o. there may be one or two plugins we need to
> install/tweak etc.
> We will be not using 'Views' at the top level, but rather we will take
> advantage of 'Folders Plus' - each project will get its own Folder and have
> authorisation access to create/edit jobs etc within that folder. I will
> create these folders as you ask for them to start with. This setup allows
> for credentials isolation amongst other benefits, including but not limited
> to exclusive agents (Controlled Agents) for your own use , should you have
> any project targeted donations of agents.
> As with other aspects of the ASF, projects can choose to just enable all
> committers access to their folder, just ask.
> We will re-use builds.apache.org as a CNAME to ci-builds.a.o but will not
> be setting up any forwarding rules or anything like that.
> So, please, get started *now *on this so you can be sure we are all
> completed before the final cutoff date of 15th August 2020.
> Any questions - I expect a few (dozen :) ) - ask away and/or file INFRA
> tickets.
> Hadoop and related projects have their own migration path to follow, same
> cut off date, Cassandra, Beam, CouchDB have already migrated and are doing
> very well in their new homes.
> Lets get going ...
> --
> *Gavin McDonald*
> Systems Administrator
> ASF Infrastructure Team{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (PHOENIX-6099) PHOENIX-5881 uses apache commons logging and breaks mvn verify
Istvan Toth created PHOENIX-6099: Summary: PHOENIX-5881 uses apache commons logging and breaks mvn verify Key: PHOENIX-6099 URL: https://issues.apache.org/jira/browse/PHOENIX-6099 Project: Phoenix Issue Type: Bug Reporter: Istvan Toth Assignee: Istvan Toth PHOENIX-5881 imports apache commons logging, which we have replaced with SLF4J some time ago. Apart from being inconsistent with the rest of Phoenix, this causes *mvn verify* to fail at the analyze-dependecies target. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6099) PHOENIX-5881 uses apache commons logging and breaks mvn verify
[ https://issues.apache.org/jira/browse/PHOENIX-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6099: - Description: PHOENIX-5881 imports apache commons logging, which we have replaced with SLF4J some time ago. Apart from being inconsistent with the rest of Phoenix, this causes *mvn verify* to fail at the dependency:analyze-only target. was: PHOENIX-5881 imports apache commons logging, which we have replaced with SLF4J some time ago. Apart from being inconsistent with the rest of Phoenix, this causes *mvn verify* to fail at the analyze-dependecies target. > PHOENIX-5881 uses apache commons logging and breaks mvn verify > -- > > Key: PHOENIX-6099 > URL: https://issues.apache.org/jira/browse/PHOENIX-6099 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.1.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Major > Attachments: PHOENIX-6099.master.v1.patch > > Time Spent: 10m > Remaining Estimate: 0h > > PHOENIX-5881 imports apache commons logging, which we have replaced with > SLF4J some time ago. > Apart from being inconsistent with the rest of Phoenix, this causes *mvn > verify* to fail at the dependency:analyze-only target. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6099) PHOENIX-5881 uses apache commons logging and breaks mvn verify
[ https://issues.apache.org/jira/browse/PHOENIX-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6099: - Priority: Blocker (was: Major) > PHOENIX-5881 uses apache commons logging and breaks mvn verify > -- > > Key: PHOENIX-6099 > URL: https://issues.apache.org/jira/browse/PHOENIX-6099 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.1.0 >Reporter: Istvan Toth >Assignee: Istvan Toth >Priority: Blocker > Attachments: PHOENIX-6099.master.v1.patch > > Time Spent: 10m > Remaining Estimate: 0h > > PHOENIX-5881 imports apache commons logging, which we have replaced with > SLF4J some time ago. > Apart from being inconsistent with the rest of Phoenix, this causes *mvn > verify* to fail at the dependency:analyze-only target. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (PHOENIX-6100) Update HBase-two version in phoenix connectors according to PHOENIX-6028
Richard Antal created PHOENIX-6100: -- Summary: Update HBase-two version in phoenix connectors according to PHOENIX-6028 Key: PHOENIX-6100 URL: https://issues.apache.org/jira/browse/PHOENIX-6100 Project: Phoenix Issue Type: Task Reporter: Richard Antal Assignee: Richard Antal -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6091) Calling MetaDataProtocol.getVersion() on a 4.16 timestamp gives version as 4.15.x
[ https://issues.apache.org/jira/browse/PHOENIX-6091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Antal updated PHOENIX-6091: --- Attachment: PHOENIX-6091.4.x.v1.patch > Calling MetaDataProtocol.getVersion() on a 4.16 timestamp gives version as > 4.15.x > - > > Key: PHOENIX-6091 > URL: https://issues.apache.org/jira/browse/PHOENIX-6091 > Project: Phoenix > Issue Type: Bug >Affects Versions: 4.16.0 >Reporter: Chinmay Kulkarni >Priority: Minor > Fix For: 4.16.0 > > Attachments: PHOENIX-6091.4.x.v1.patch > > > This is probably because we haven't added an entry for 4.16 in the > MetaDataProtocol.TIMESTAMP_VERSION_MAP -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6100) Update HBase-two version in phoenix connectors according to PHOENIX-6028
[ https://issues.apache.org/jira/browse/PHOENIX-6100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth updated PHOENIX-6100: - Component/s: connectors Affects Version/s: connectors-6.0.0 > Update HBase-two version in phoenix connectors according to PHOENIX-6028 > > > Key: PHOENIX-6100 > URL: https://issues.apache.org/jira/browse/PHOENIX-6100 > Project: Phoenix > Issue Type: Task > Components: connectors >Affects Versions: connectors-6.0.0 >Reporter: Richard Antal >Assignee: Richard Antal >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6100) Update HBase-two version in phoenix connectors according to PHOENIX-6028
[ https://issues.apache.org/jira/browse/PHOENIX-6100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Istvan Toth resolved PHOENIX-6100. -- Fix Version/s: connectors-6.0.0 Resolution: Fixed Committed. Thanks for the fix [~RichardAntal] > Update HBase-two version in phoenix connectors according to PHOENIX-6028 > > > Key: PHOENIX-6100 > URL: https://issues.apache.org/jira/browse/PHOENIX-6100 > Project: Phoenix > Issue Type: Task > Components: connectors >Affects Versions: connectors-6.0.0 >Reporter: Richard Antal >Assignee: Richard Antal >Priority: Major > Fix For: connectors-6.0.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6097) Improve LOCAL index consistency tests
[ https://issues.apache.org/jira/browse/PHOENIX-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-6097: --- Fix Version/s: 4.16.0 5.1.0 > Improve LOCAL index consistency tests > - > > Key: PHOENIX-6097 > URL: https://issues.apache.org/jira/browse/PHOENIX-6097 > Project: Phoenix > Issue Type: Sub-task >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Minor > Fix For: 5.1.0, 4.16.0 > > Attachments: 6097-master.txt > > > See parent. Improve the tests in the following simple ways: > # Tests with larger sets - it's still fast, inserting 10k rows takes about > 0.3s > # Test with multiple global and local indexes to verify the locking and the > multi-path logic > The test is the same as in parent: Multiple regions, multiple writers, > inserting new values, and updating existing values) > Since it's only simple test changes, I'm just going to commit. > [~kozdemir], FYI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[DISCUSS] EOL support for HBase 1.3
The HBase community has just unanimously EOLed HBase 1.3. As I recall, 1.3 has some significant differences with 1.4+ that we have to workaround via compatibility shim, particularly with metrics and changes to the HBase Scan API. (In particular, the scan API changes are difficult to handle even with the shim.) Should we simplify our 4.x branch by removing 1.3 support for the upcoming 4.16 release? Geoffrey
[jira] [Updated] (PHOENIX-6069) We should check that the parent table key is in the region in the MetaDataEndpointImpl.dropTable code
[ https://issues.apache.org/jira/browse/PHOENIX-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-6069: -- Attachment: (was: PHOENIX-6069-4.x.patch) > We should check that the parent table key is in the region in the > MetaDataEndpointImpl.dropTable code > - > > Key: PHOENIX-6069 > URL: https://issues.apache.org/jira/browse/PHOENIX-6069 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.0.0, 4.15.0 >Reporter: Chinmay Kulkarni >Assignee: Chinmay Kulkarni >Priority: Major > Fix For: 5.1.0, 4.16.0 > > Attachments: PHOENIX-6069-4.x-v2.patch > > > The check > [here|https://github.com/apache/phoenix/blob/1d844950bb4ec8221873ecd2b094c20f427cd984/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2231] > should check the parentLockKey instead of the lockKey for the current table > which we've already checked before this. Seems to be a copy-paste error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6069) We should check that the parent table key is in the region in the MetaDataEndpointImpl.dropTable code
[jira] [Updated] (PHOENIX-6069) We should check that the parent table key is in the region in the MetaDataEndpointImpl.dropTable code
[ https://issues.apache.org/jira/browse/PHOENIX-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chinmay Kulkarni updated PHOENIX-6069: -- Attachment: (was: PHOENIX-6069-4.x-v1.patch) > We should check that the parent table key is in the region in the > MetaDataEndpointImpl.dropTable code > - > > Key: PHOENIX-6069 > URL: https://issues.apache.org/jira/browse/PHOENIX-6069 > Project: Phoenix > Issue Type: Bug >Affects Versions: 5.0.0, 4.15.0 >Reporter: Chinmay Kulkarni >Assignee: Chinmay Kulkarni >Priority: Major > Fix For: 5.1.0, 4.16.0 > > Attachments: PHOENIX-6069-4.x-v2.patch > > > The check > [here|https://github.com/apache/phoenix/blob/1d844950bb4ec8221873ecd2b094c20f427cd984/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L2231] > should check the parentLockKey instead of the lockKey for the current table > which we've already checked before this. Seems to be a copy-paste error. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: [DISCUSS] EOL support for HBase 1.3
+1 for planning EOL support for HBase 1.3, but can we do it after 4.16 release? I feel it because of the following reasons:- (including user ) * It will be an advance notice to the users who have been waiting for fixes in 4.16 release for a long time but are on HBase-1.3. * As work is already done to support 1.3 through shim, so why not release it if it is possible with minimal effort. * We will have code for 1.3 shim available in release tag, then in future, if someone volunteers to support 1.3(for a minor release or 4.16 point release) doesn't need to revert the set of commits which brings back this shim layer, instead can use the tag and go with it. Regards, Ankit Singhal On Mon, Aug 24, 2020 at 10:04 AM Geoffrey Jacoby wrote: > The HBase community has just unanimously EOLed HBase 1.3. > > As I recall, 1.3 has some significant differences with 1.4+ that we have to > workaround via compatibility shim, particularly with metrics and changes to > the HBase Scan API. (In particular, the scan API changes are difficult to > handle even with the shim.) > > Should we simplify our 4.x branch by removing 1.3 support for the upcoming > 4.16 release? > > Geoffrey >
[jira] [Created] (PHOENIX-6101) Avoid duplicate work between local and global indexes
Lars Hofhansl created PHOENIX-6101: -- Summary: Avoid duplicate work between local and global indexes Key: PHOENIX-6101 URL: https://issues.apache.org/jira/browse/PHOENIX-6101 Project: Phoenix Issue Type: Sub-task Reporter: Lars Hofhansl -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (PHOENIX-6097) Improve LOCAL index consistency tests
[ https://issues.apache.org/jira/browse/PHOENIX-6097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl resolved PHOENIX-6097. Resolution: Fixed > Improve LOCAL index consistency tests > - > > Key: PHOENIX-6097 > URL: https://issues.apache.org/jira/browse/PHOENIX-6097 > Project: Phoenix > Issue Type: Sub-task >Reporter: Lars Hofhansl >Assignee: Lars Hofhansl >Priority: Minor > Fix For: 5.1.0, 4.16.0 > > Attachments: 6097-master.txt > > > See parent. Improve the tests in the following simple ways: > # Tests with larger sets - it's still fast, inserting 10k rows takes about > 0.3s > # Test with multiple global and local indexes to verify the locking and the > multi-path logic > The test is the same as in parent: Multiple regions, multiple writers, > inserting new values, and updating existing values) > Since it's only simple test changes, I'm just going to commit. > [~kozdemir], FYI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6101) Avoid duplicate work between local and global indexes
[ https://issues.apache.org/jira/browse/PHOENIX-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-6101: --- Attachment: 6101-master.txt > Avoid duplicate work between local and global indexes > - > > Key: PHOENIX-6101 > URL: https://issues.apache.org/jira/browse/PHOENIX-6101 > Project: Phoenix > Issue Type: Sub-task >Reporter: Lars Hofhansl >Priority: Major > Attachments: 6101-master.txt > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (PHOENIX-6101) Avoid duplicate work between local and global indexes
[ https://issues.apache.org/jira/browse/PHOENIX-6101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lars Hofhansl updated PHOENIX-6101: --- Description: When there are only local indexes there is still (even after parent) a lot of unnecessary work done. This issue fixes that. > Avoid duplicate work between local and global indexes > - > > Key: PHOENIX-6101 > URL: https://issues.apache.org/jira/browse/PHOENIX-6101 > Project: Phoenix > Issue Type: Sub-task >Reporter: Lars Hofhansl >Priority: Major > Attachments: 6101-master.txt > > > When there are only local indexes there is still (even after parent) a lot of > unnecessary work done. This issue fixes that. -- This message was sent by Atlassian Jira (v8.3.4#803005)
