Re: Review Request 33877: HIVE-10618 Fix invocation of toString on byteArray in VerifyFast (250, 254)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33877/#review82631 --- serde/src/test/org/apache/hadoop/hive/serde2/VerifyFast.java https://reviews.apache.org/r/33877/#comment133403 Isn't it supposed to append lengths here? - Prasanth_J On May 6, 2015, 3:53 a.m., Alexander Pivovarov wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33877/ --- (Updated May 6, 2015, 3:53 a.m.) Review request for hive and Prasanth_J. Bugs: HIVE-10618 https://issues.apache.org/jira/browse/HIVE-10618 Repository: hive-git Description --- HIVE-10618 Fix invocation of toString on byteArray in VerifyFast (250, 254) Diffs - serde/src/test/org/apache/hadoop/hive/serde2/VerifyFast.java a3472ad7f565becd2d617289323f18b9df989146 Diff: https://reviews.apache.org/r/33877/diff/ Testing --- Thanks, Alexander Pivovarov
Re: Fwd: [DISCUSS] Allow any jira user to assign HIVE bugs to them self
I would like to emphasise again that this change in adding jira-users, does not change Hive's policy regarding ICLA. In hive, we never required people to file ICLA before submitting a patch. Your question regarding ICLA requirements merits a discussion on its own. Even if ICLA is on file, that does not automatically imply that the contributor had all rights to contribute. It just means that such a contributor has lied, if he didn't have rights to contribute. On Tue, May 5, 2015 at 5:36 PM, Sushanth Sowmyan khorg...@gmail.com wrote: I will defer to the larger community's opinion on this, and from the looks of it, Apache does suggest, but not require (but does heavily suggest as desired) an ICLA from contributors, but I kinda agree with https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ in the place ICLAs have with projects. The relevant portion, as I see it, is this: Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works. This is, I think, the first key point. Contributors explictly grant a license to the upstream project maintainers to use contributions. Sublicensing is important, too, as it opens licensing under new terms in the future, even if the contributor is out of reach. I feel like without having an ICLA requirement for contributors(and yes, I acknowledge that being a jira-user and requesting in the mailing list did not already cover this - it was my mistaken memory that felt like it did from back when the jira had a UI element granting ASF rights), committers open themselves to the possibility that we +1 and accept a contribution that we will wind up being responsible for that should not have been legally acceptable. I also agree with Lefty that taken to an extreme, this could apply for docs and wiki, etc, and that does sound ludicrous, but still a place we open ourselves to legal responsibility. If $COMPANY sues apache because we have some content in our wiki that we should not have, removal is not hard. If that happens with our git repo, we're in for a not-fun exercise in rewriting git history. I also concede the advantages in being more open by making it easier to contribute, and indeed the link I paste above does refer to people that will not contribute to a project that has a CLA requirement, but I'm not completely satisfied by not addressing this issue in some manner either. This is not a -1 for this move, and indeed, would/could not be a binding one even if it were so, but I would like to understand what the hive project's legal position is on the cases where a committer commits a patch that a contributor contributed that they did not have rights to contribute. On Tue, May 5, 2015 at 11:11 AM, Thejas Nair thejas.n...@gmail.com wrote: I guess the limit is around the number of entries in the contributor group, and adding a jira-user group would not count towards that. Let me give it a try. That INFRA jira is another good reason to add jira-users group to contributors! On Mon, May 4, 2015 at 11:31 PM, Carl Steinbach cwsteinb...@gmail.com wrote: It turns out there's a limit on the number of people you can list as contributors for any given JIRA project. I bumped into this a couple months back when I tried adding someone to the list and found this: https://issues.apache.org/jira/browse/INFRA-7293 On Mon, May 4, 2015 at 10:02 PM, Lefty Leverenz leftylever...@gmail.com wrote: Sure, go for it. -- Lefty On Mon, May 4, 2015 at 5:33 PM, Thejas Nair thejas.n...@gmail.com wrote: As Lefty noted, we don't require anyone being made a jira contributor or uploading a patch to have ICLA on file. Apache does not require that, though that is encouraged. So allowing any user to be a contributor without asking for permission does not change things with respect to ICLA. Looks like people are on board with this. I will change the settings in another day as long as there are no objections. On Sat, May 2, 2015 at 11:44 PM, Lefty Leverenz leftylever...@gmail.com wrote: Hive only requires committers to sign ICLAs. That doesn't seem to provide any legal protection when non-committers contribute patches. In days gone by, JIRA made us assign rights to Apache when we attached a patch to an issue. That's still in the instructions for Contributing Your Work https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-ContributingYourWork : Please note that the attachment should be granted license to ASF for inclusion in ASF work although the JIRA GUI doesn't
Re: Fwd: [DISCUSS] Allow any jira user to assign HIVE bugs to them self
Thank you for raising these points about the ICLA, Sushanth. I'm looking forward to the discussion in another thread. -- Lefty On Tue, May 5, 2015 at 9:05 PM, Sushanth Sowmyan khorg...@gmail.com wrote: I accept that this need not be linked to the jira-users issue itself, except that it made it much more difficult to enforce that contributors have ICLAs on file if we choose to go down that route. I will send out another mail asking for the project's position on ICLAs for all contributors, and what the committers should be responsible for in a separate mail. Also, yes, even if ICLA is on file, that does not imply that the contributor had rights to contribute, but it does put the legal responsibility on the contributor, rather than on the project or the committers. On Tue, May 5, 2015 at 5:46 PM, Thejas Nair thejas.n...@gmail.com wrote: I would like to emphasise again that this change in adding jira-users, does not change Hive's policy regarding ICLA. In hive, we never required people to file ICLA before submitting a patch. Your question regarding ICLA requirements merits a discussion on its own. Even if ICLA is on file, that does not automatically imply that the contributor had all rights to contribute. It just means that such a contributor has lied, if he didn't have rights to contribute. On Tue, May 5, 2015 at 5:36 PM, Sushanth Sowmyan khorg...@gmail.com wrote: I will defer to the larger community's opinion on this, and from the looks of it, Apache does suggest, but not require (but does heavily suggest as desired) an ICLA from contributors, but I kinda agree with https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ in the place ICLAs have with projects. The relevant portion, as I see it, is this: Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works. This is, I think, the first key point. Contributors explictly grant a license to the upstream project maintainers to use contributions. Sublicensing is important, too, as it opens licensing under new terms in the future, even if the contributor is out of reach. I feel like without having an ICLA requirement for contributors(and yes, I acknowledge that being a jira-user and requesting in the mailing list did not already cover this - it was my mistaken memory that felt like it did from back when the jira had a UI element granting ASF rights), committers open themselves to the possibility that we +1 and accept a contribution that we will wind up being responsible for that should not have been legally acceptable. I also agree with Lefty that taken to an extreme, this could apply for docs and wiki, etc, and that does sound ludicrous, but still a place we open ourselves to legal responsibility. If $COMPANY sues apache because we have some content in our wiki that we should not have, removal is not hard. If that happens with our git repo, we're in for a not-fun exercise in rewriting git history. I also concede the advantages in being more open by making it easier to contribute, and indeed the link I paste above does refer to people that will not contribute to a project that has a CLA requirement, but I'm not completely satisfied by not addressing this issue in some manner either. This is not a -1 for this move, and indeed, would/could not be a binding one even if it were so, but I would like to understand what the hive project's legal position is on the cases where a committer commits a patch that a contributor contributed that they did not have rights to contribute. On Tue, May 5, 2015 at 11:11 AM, Thejas Nair thejas.n...@gmail.com wrote: I guess the limit is around the number of entries in the contributor group, and adding a jira-user group would not count towards that. Let me give it a try. That INFRA jira is another good reason to add jira-users group to contributors! On Mon, May 4, 2015 at 11:31 PM, Carl Steinbach cwsteinb...@gmail.com wrote: It turns out there's a limit on the number of people you can list as contributors for any given JIRA project. I bumped into this a couple months back when I tried adding someone to the list and found this: https://issues.apache.org/jira/browse/INFRA-7293 On Mon, May 4, 2015 at 10:02 PM, Lefty Leverenz leftylever...@gmail.com wrote: Sure, go for it. -- Lefty On Mon, May 4, 2015 at 5:33 PM, Thejas Nair thejas.n...@gmail.com wrote: As Lefty noted, we don't require anyone being made a jira contributor or uploading a patch to have ICLA on file.
[jira] [Created] (HIVE-10617) fix allocator concurrency rarely causing spurious failure to allocate due to partitioned locking
Sergey Shelukhin created HIVE-10617: --- Summary: fix allocator concurrency rarely causing spurious failure to allocate due to partitioned locking Key: HIVE-10617 URL: https://issues.apache.org/jira/browse/HIVE-10617 Project: Hive Issue Type: Sub-task Reporter: Sergey Shelukhin See HIVE-10482 and the comment in code. Simple case - thread can reserve memory from manager and bounce between checking arena 1 and arena 2 for memory as other threads allocate and deallocate from respective arenas in reverse order, making it look like there's no memory. More importantly this can happen when buddy blocks are split when lots of stuff is allocated. This can be solved either with some form of helping (esp. for split case) or by making allocator an actor (or set of actors, one per 1-N arenas that they would own), to satisfy alloc requests more deterministically (and also get rid of most sync). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Fwd: [DISCUSS] Allow any jira user to assign HIVE bugs to them self
I accept that this need not be linked to the jira-users issue itself, except that it made it much more difficult to enforce that contributors have ICLAs on file if we choose to go down that route. I will send out another mail asking for the project's position on ICLAs for all contributors, and what the committers should be responsible for in a separate mail. Also, yes, even if ICLA is on file, that does not imply that the contributor had rights to contribute, but it does put the legal responsibility on the contributor, rather than on the project or the committers. On Tue, May 5, 2015 at 5:46 PM, Thejas Nair thejas.n...@gmail.com wrote: I would like to emphasise again that this change in adding jira-users, does not change Hive's policy regarding ICLA. In hive, we never required people to file ICLA before submitting a patch. Your question regarding ICLA requirements merits a discussion on its own. Even if ICLA is on file, that does not automatically imply that the contributor had all rights to contribute. It just means that such a contributor has lied, if he didn't have rights to contribute. On Tue, May 5, 2015 at 5:36 PM, Sushanth Sowmyan khorg...@gmail.com wrote: I will defer to the larger community's opinion on this, and from the looks of it, Apache does suggest, but not require (but does heavily suggest as desired) an ICLA from contributors, but I kinda agree with https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ in the place ICLAs have with projects. The relevant portion, as I see it, is this: Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works. This is, I think, the first key point. Contributors explictly grant a license to the upstream project maintainers to use contributions. Sublicensing is important, too, as it opens licensing under new terms in the future, even if the contributor is out of reach. I feel like without having an ICLA requirement for contributors(and yes, I acknowledge that being a jira-user and requesting in the mailing list did not already cover this - it was my mistaken memory that felt like it did from back when the jira had a UI element granting ASF rights), committers open themselves to the possibility that we +1 and accept a contribution that we will wind up being responsible for that should not have been legally acceptable. I also agree with Lefty that taken to an extreme, this could apply for docs and wiki, etc, and that does sound ludicrous, but still a place we open ourselves to legal responsibility. If $COMPANY sues apache because we have some content in our wiki that we should not have, removal is not hard. If that happens with our git repo, we're in for a not-fun exercise in rewriting git history. I also concede the advantages in being more open by making it easier to contribute, and indeed the link I paste above does refer to people that will not contribute to a project that has a CLA requirement, but I'm not completely satisfied by not addressing this issue in some manner either. This is not a -1 for this move, and indeed, would/could not be a binding one even if it were so, but I would like to understand what the hive project's legal position is on the cases where a committer commits a patch that a contributor contributed that they did not have rights to contribute. On Tue, May 5, 2015 at 11:11 AM, Thejas Nair thejas.n...@gmail.com wrote: I guess the limit is around the number of entries in the contributor group, and adding a jira-user group would not count towards that. Let me give it a try. That INFRA jira is another good reason to add jira-users group to contributors! On Mon, May 4, 2015 at 11:31 PM, Carl Steinbach cwsteinb...@gmail.com wrote: It turns out there's a limit on the number of people you can list as contributors for any given JIRA project. I bumped into this a couple months back when I tried adding someone to the list and found this: https://issues.apache.org/jira/browse/INFRA-7293 On Mon, May 4, 2015 at 10:02 PM, Lefty Leverenz leftylever...@gmail.com wrote: Sure, go for it. -- Lefty On Mon, May 4, 2015 at 5:33 PM, Thejas Nair thejas.n...@gmail.com wrote: As Lefty noted, we don't require anyone being made a jira contributor or uploading a patch to have ICLA on file. Apache does not require that, though that is encouraged. So allowing any user to be a contributor without asking for permission does not change things with respect to ICLA. Looks like people are on board with this. I will change the settings in another day as long as there are no
[jira] [Created] (HIVE-10618) Fix invocation of toString on byteArray in VerifyFast (250, 254)
Alexander Pivovarov created HIVE-10618: -- Summary: Fix invocation of toString on byteArray in VerifyFast (250, 254) Key: HIVE-10618 URL: https://issues.apache.org/jira/browse/HIVE-10618 Project: Hive Issue Type: Bug Components: Serializers/Deserializers Reporter: Alexander Pivovarov Assignee: Alexander Pivovarov Priority: Minor Arrays.toString(byteArray) can be used to convert byte[] to string -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Review Request 33877: HIVE-10618 Fix invocation of toString on byteArray in VerifyFast (250, 254)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33877/ --- Review request for hive and Prasanth_J. Bugs: HIVE-10618 https://issues.apache.org/jira/browse/HIVE-10618 Repository: hive-git Description --- HIVE-10618 Fix invocation of toString on byteArray in VerifyFast (250, 254) Diffs - serde/src/test/org/apache/hadoop/hive/serde2/VerifyFast.java a3472ad7f565becd2d617289323f18b9df989146 Diff: https://reviews.apache.org/r/33877/diff/ Testing --- Thanks, Alexander Pivovarov
[jira] [Created] (HIVE-10616) TypeInfoUtils doesn't handle DECIMAL with just precision specified
Thomas Friedrich created HIVE-10616: --- Summary: TypeInfoUtils doesn't handle DECIMAL with just precision specified Key: HIVE-10616 URL: https://issues.apache.org/jira/browse/HIVE-10616 Project: Hive Issue Type: Bug Components: Serializers/Deserializers Affects Versions: 1.0.0 Reporter: Thomas Friedrich Assignee: Thomas Friedrich Priority: Minor The parseType method in TypeInfoUtils doesn't handle decimal types with just precision specified although that's a valid type definition. As a result, TypeInfoUtils.getTypeInfoFromTypeString will always return decimal(10,0) for any decimal(precision) string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Fwd: [DISCUSS] Allow any jira user to assign HIVE bugs to them self
I made the change to add jira-users to the contributors group a few hours back. On Tue, May 5, 2015 at 11:11 AM, Thejas Nair thejas.n...@gmail.com wrote: I guess the limit is around the number of entries in the contributor group, and adding a jira-user group would not count towards that. Let me give it a try. That INFRA jira is another good reason to add jira-users group to contributors! On Mon, May 4, 2015 at 11:31 PM, Carl Steinbach cwsteinb...@gmail.com wrote: It turns out there's a limit on the number of people you can list as contributors for any given JIRA project. I bumped into this a couple months back when I tried adding someone to the list and found this: https://issues.apache.org/jira/browse/INFRA-7293 On Mon, May 4, 2015 at 10:02 PM, Lefty Leverenz leftylever...@gmail.com wrote: Sure, go for it. -- Lefty On Mon, May 4, 2015 at 5:33 PM, Thejas Nair thejas.n...@gmail.com wrote: As Lefty noted, we don't require anyone being made a jira contributor or uploading a patch to have ICLA on file. Apache does not require that, though that is encouraged. So allowing any user to be a contributor without asking for permission does not change things with respect to ICLA. Looks like people are on board with this. I will change the settings in another day as long as there are no objections. On Sat, May 2, 2015 at 11:44 PM, Lefty Leverenz leftylever...@gmail.com wrote: Hive only requires committers to sign ICLAs. That doesn't seem to provide any legal protection when non-committers contribute patches. In days gone by, JIRA made us assign rights to Apache when we attached a patch to an issue. That's still in the instructions for Contributing Your Work https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-ContributingYourWork : Please note that the attachment should be granted license to ASF for inclusion in ASF work although the JIRA GUI doesn't have that option anymore. See Apache's page on licenses http://www.apache.org/licenses/#clas: The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via postal mail, fax or email) an Individual Contributor License Agreement *(highlighting added)*. So documentation in the wiki should also be covered by ICLAs. Carried to extremes, anyone who participates on a mailing list, comments on a JIRA issue, or reviews a patch should sign an ICLA. -- Lefty On Sun, May 3, 2015 at 12:30 AM, Sushanth Sowmyan khorg...@gmail.com wrote: I seem to remember something on the lines of that the traditional reason was so that a project could be sure that the contributor had an ICLA on file with apache so as to not expose the project to legal risk of code that was contributed that the contributor did not have any rights to. We should probably check with folks from other projects who've had experience dealing with stuff like this? Maybe Owen? On May 2, 2015 17:08, Thejas Nair thejas.n...@gmail.com wrote: Sending again, didn't make to the list for some reason. -- Forwarded message -- From: Thejas Nair thejas.n...@gmail.com Date: Fri, May 1, 2015 at 1:53 PM Subject: [DISCUSS] Allow any jira user to assign HIVE bugs to them self To: dev dev@hive.apache.org I am not sure why a user needs to ask to be added as a contributor in HIVE jira to be able to assign jiras to themselves. I don't see it adding any value. Also the jira ADMIN UI for adding this is usually flaky. I think we should let any jira users assign the bugs to them self. Looks like adding jira-users group to contributions would do it. Thoughts ? Thanks, Thejas
[jira] [Created] (HIVE-10619) Fix ConcurrentHashMap.get in MetadataListStructObjectInspector.getInstance (52)
Alexander Pivovarov created HIVE-10619:
--
Summary: Fix ConcurrentHashMap.get in
MetadataListStructObjectInspector.getInstance (52)
Key: HIVE-10619
URL: https://issues.apache.org/jira/browse/HIVE-10619
Project: Hive
Issue Type: Bug
Components: Serializers/Deserializers
Reporter: Alexander Pivovarov
Assignee: Alexander Pivovarov
Priority: Minor
cached.get(columnNames) should be replaced with cached.get(key) in the code
block below
{code}
cached = new ConcurrentHashMapListListString,
MetadataListStructObjectInspector();
public static MetadataListStructObjectInspector getInstance(
ListString columnNames) {
ArrayListListString key = new ArrayListListString(1);
key.add(columnNames);
MetadataListStructObjectInspector result = cached.get(columnNames);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HIVE-10620) ZooKeeperHiveLock overrides equal() method but not hashcode()
Chaoyu Tang created HIVE-10620: -- Summary: ZooKeeperHiveLock overrides equal() method but not hashcode() Key: HIVE-10620 URL: https://issues.apache.org/jira/browse/HIVE-10620 Project: Hive Issue Type: Bug Affects Versions: 1.0.0 Reporter: Chaoyu Tang Assignee: Chaoyu Tang ZooKeeperHiveLock overrides the public boolean equals(Object o) method but does not for public int hashCode(). It violates the Java contract that equal and may cause unexpected results. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Fwd: [DISCUSS] Allow any jira user to assign HIVE bugs to them self
I will defer to the larger community's opinion on this, and from the looks of it, Apache does suggest, but not require (but does heavily suggest as desired) an ICLA from contributors, but I kinda agree with https://julien.ponge.org/blog/in-defense-of-contributor-license-agreements/ in the place ICLAs have with projects. The relevant portion, as I see it, is this: Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to the Foundation and to recipients of software distributed by the Foundation a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works. This is, I think, the first key point. Contributors explictly grant a license to the upstream project maintainers to use contributions. Sublicensing is important, too, as it opens licensing under new terms in the future, even if the contributor is out of reach. I feel like without having an ICLA requirement for contributors(and yes, I acknowledge that being a jira-user and requesting in the mailing list did not already cover this - it was my mistaken memory that felt like it did from back when the jira had a UI element granting ASF rights), committers open themselves to the possibility that we +1 and accept a contribution that we will wind up being responsible for that should not have been legally acceptable. I also agree with Lefty that taken to an extreme, this could apply for docs and wiki, etc, and that does sound ludicrous, but still a place we open ourselves to legal responsibility. If $COMPANY sues apache because we have some content in our wiki that we should not have, removal is not hard. If that happens with our git repo, we're in for a not-fun exercise in rewriting git history. I also concede the advantages in being more open by making it easier to contribute, and indeed the link I paste above does refer to people that will not contribute to a project that has a CLA requirement, but I'm not completely satisfied by not addressing this issue in some manner either. This is not a -1 for this move, and indeed, would/could not be a binding one even if it were so, but I would like to understand what the hive project's legal position is on the cases where a committer commits a patch that a contributor contributed that they did not have rights to contribute. On Tue, May 5, 2015 at 11:11 AM, Thejas Nair thejas.n...@gmail.com wrote: I guess the limit is around the number of entries in the contributor group, and adding a jira-user group would not count towards that. Let me give it a try. That INFRA jira is another good reason to add jira-users group to contributors! On Mon, May 4, 2015 at 11:31 PM, Carl Steinbach cwsteinb...@gmail.com wrote: It turns out there's a limit on the number of people you can list as contributors for any given JIRA project. I bumped into this a couple months back when I tried adding someone to the list and found this: https://issues.apache.org/jira/browse/INFRA-7293 On Mon, May 4, 2015 at 10:02 PM, Lefty Leverenz leftylever...@gmail.com wrote: Sure, go for it. -- Lefty On Mon, May 4, 2015 at 5:33 PM, Thejas Nair thejas.n...@gmail.com wrote: As Lefty noted, we don't require anyone being made a jira contributor or uploading a patch to have ICLA on file. Apache does not require that, though that is encouraged. So allowing any user to be a contributor without asking for permission does not change things with respect to ICLA. Looks like people are on board with this. I will change the settings in another day as long as there are no objections. On Sat, May 2, 2015 at 11:44 PM, Lefty Leverenz leftylever...@gmail.com wrote: Hive only requires committers to sign ICLAs. That doesn't seem to provide any legal protection when non-committers contribute patches. In days gone by, JIRA made us assign rights to Apache when we attached a patch to an issue. That's still in the instructions for Contributing Your Work https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-ContributingYourWork : Please note that the attachment should be granted license to ASF for inclusion in ASF work although the JIRA GUI doesn't have that option anymore. See Apache's page on licenses http://www.apache.org/licenses/#clas: The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via postal mail, fax or email) an Individual Contributor License Agreement *(highlighting added)*. So documentation in the wiki should also be covered by ICLAs. Carried to extremes, anyone who participates on a mailing list, comments on a JIRA issue, or reviews a patch should sign an ICLA. -- Lefty On Sun,
Review Request 33878: HIVE-10619 Fix ConcurrentHashMap.get in MetadataListStructObjectInspector.getInstance (52)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33878/ --- Review request for hive, Dhruba Borthakur and Szehon Ho. Bugs: HIVE-10619 https://issues.apache.org/jira/browse/HIVE-10619 Repository: hive-git Description --- HIVE-10619 Fix ConcurrentHashMap.get in MetadataListStructObjectInspector.getInstance (52) Diffs - serde/src/java/org/apache/hadoop/hive/serde2/objectinspector/MetadataListStructObjectInspector.java e68325f8548d2115f9fedd54cc8adefd4d5e76f8 Diff: https://reviews.apache.org/r/33878/diff/ Testing --- Thanks, Alexander Pivovarov
[jira] [Created] (HIVE-10622) Hive doc error: 'from' is a keyword, when use it as a column name throw error.
Anne Yu created HIVE-10622:
--
Summary: Hive doc error: 'from' is a keyword, when use it as a
column name throw error.
Key: HIVE-10622
URL: https://issues.apache.org/jira/browse/HIVE-10622
Project: Hive
Issue Type: Bug
Components: Documentation
Affects Versions: 1.1.1
Reporter: Anne Yu
Fix For: 1.1.1
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DML, Use from
as a column name in create table, throw error.
{code}
CREATE TABLE pageviews (userid VARCHAR(64), link STRING, from STRING)
PARTITIONED BY (datestamp STRING) CLUSTERED BY (userid) INTO 256 BUCKETS
STORED AS ORC;
Error: Error while compiling statement: FAILED: ParseException line 1:57 cannot
recognize input near 'from' 'STRING' ')' in column specification
(state=42000,code=4)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Review Request 33877: HIVE-10618 Fix invocation of toString on byteArray in VerifyFast (250, 254)
On May 6, 2015, 4:09 a.m., Prasanth_J wrote: serde/src/test/org/apache/hadoop/hive/serde2/VerifyFast.java, line 250 https://reviews.apache.org/r/33877/diff/1/?file=950807#file950807line250 Isn't it supposed to append lengths here? I think it is more informative if failure error message has both arrays content(not just arrays lenght). - Alexander --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33877/#review82631 --- On May 6, 2015, 3:53 a.m., Alexander Pivovarov wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33877/ --- (Updated May 6, 2015, 3:53 a.m.) Review request for hive and Prasanth_J. Bugs: HIVE-10618 https://issues.apache.org/jira/browse/HIVE-10618 Repository: hive-git Description --- HIVE-10618 Fix invocation of toString on byteArray in VerifyFast (250, 254) Diffs - serde/src/test/org/apache/hadoop/hive/serde2/VerifyFast.java a3472ad7f565becd2d617289323f18b9df989146 Diff: https://reviews.apache.org/r/33877/diff/ Testing --- Thanks, Alexander Pivovarov
Review Request 33880: HIVE-10621 serde typeinfo equals methods are not symmetric
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33880/ --- Review request for hive and Ashutosh Chauhan. Bugs: HIVE-10621 https://issues.apache.org/jira/browse/HIVE-10621 Repository: hive-git Description --- HIVE-10621 serde typeinfo equals methods are not symmetric Diffs - serde/src/java/org/apache/hadoop/hive/serde2/io/HiveDecimalWritable.java 6ab64e56c37f127551bbf21213ff4d4a98803c43 serde/src/java/org/apache/hadoop/hive/serde2/typeinfo/CharTypeInfo.java 610818e21be3b376b1d40f3d16bf8bf7fc47adf3 serde/src/java/org/apache/hadoop/hive/serde2/typeinfo/DecimalTypeInfo.java cbe48029307a370d229d8e444ec6542e093e959a serde/src/java/org/apache/hadoop/hive/serde2/typeinfo/PrimitiveTypeInfo.java a66b50a6a224b75d5c0f5dac5ec07eab44128c12 serde/src/java/org/apache/hadoop/hive/serde2/typeinfo/VarcharTypeInfo.java 5ac2b46ac9ef3d6ddbf4496b23f43ff410a10e2f Diff: https://reviews.apache.org/r/33880/diff/ Testing --- Thanks, Alexander Pivovarov
[jira] [Created] (HIVE-10621) serde typeinfo equals methods are not symmetric
Alexander Pivovarov created HIVE-10621: -- Summary: serde typeinfo equals methods are not symmetric Key: HIVE-10621 URL: https://issues.apache.org/jira/browse/HIVE-10621 Project: Hive Issue Type: Bug Components: Serializers/Deserializers Reporter: Alexander Pivovarov Assignee: Alexander Pivovarov Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Review Request 33877: HIVE-10618 Fix invocation of toString on byteArray in VerifyFast (250, 254)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33877/#review82635 --- Ship it! Ship It! - Prasanth_J On May 6, 2015, 3:53 a.m., Alexander Pivovarov wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33877/ --- (Updated May 6, 2015, 3:53 a.m.) Review request for hive and Prasanth_J. Bugs: HIVE-10618 https://issues.apache.org/jira/browse/HIVE-10618 Repository: hive-git Description --- HIVE-10618 Fix invocation of toString on byteArray in VerifyFast (250, 254) Diffs - serde/src/test/org/apache/hadoop/hive/serde2/VerifyFast.java a3472ad7f565becd2d617289323f18b9df989146 Diff: https://reviews.apache.org/r/33877/diff/ Testing --- Thanks, Alexander Pivovarov
Re: Review Request 33816: HIVE-10597: Relative path doesn't work with CREATE TABLE LOCATION 'relative/path'
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33816/ --- (Updated 5 5, 2015, 3:14 오후) Review request for hive and Sergio Pena. Changes --- Updated diff to throw exceptions on relative path, also updated comments and added unit tests. Bugs: HIVE-10597 https://issues.apache.org/jira/browse/HIVE-10597 Repository: hive-git Description --- Allow warehouse to work with relative locations. Diffs (updated) - metastore/src/java/org/apache/hadoop/hive/metastore/Warehouse.java 25119abf97382df7c0615edbaff29ba20624a137 metastore/src/test/org/apache/hadoop/hive/metastore/TestWarehouse.java PRE-CREATION Diff: https://reviews.apache.org/r/33816/diff/ Testing --- Tested locally Thanks, Reuben Kuhnert
Re: Review Request 28109: HiveServer2 dynamic service discovery: use persistent ephemeral nodes curator recipe
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28109/#review82516 --- Ship it! Ship It! - Thejas Nair On April 28, 2015, 6:40 p.m., Vaibhav Gumashta wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/28109/ --- (Updated April 28, 2015, 6:40 p.m.) Review request for hive and Thejas Nair. Bugs: HIVE-8890 https://issues.apache.org/jira/browse/HIVE-8890 Repository: hive-git Description --- https://issues.apache.org/jira/browse/HIVE-8890 Diffs - common/src/java/org/apache/hadoop/hive/conf/HiveConf.java c9ee423 pom.xml 9a1dae9 service/pom.xml 421bb9b service/src/java/org/apache/hive/service/cli/thrift/ThriftBinaryCLIService.java ca1eae6 service/src/java/org/apache/hive/service/server/HiveServer2.java 222cb45 Diff: https://reviews.apache.org/r/28109/diff/ Testing --- Thanks, Vaibhav Gumashta
Fwd: Can't access file in Distributed Cache in Hive 1.1.0
Hi,
I've just upgraded to Hive 1.1.0 and it looks like there is a problem with
the distributed cache.
I use ADD FILE, then an UDF that wants to read the file. The following
syntax works in Hive 1.0.0 but Hive can't find the file in 1.1.0 (testfile
exists on hdfs, the built-in udf in_file is just an example):
add file hdfs:///tmp/testfile;
select in_file('a', './testfile') from a;
However, it works with the local path:
select in_file('a',
'/tmp/462e6854-10f3-4a68-a290-615e6e9d60ff_resources/testfile') from a;
When I try to list the files in the directory ./ in Hive 1.1.0, it lists
the cluster's root directory. It looks like the working directory changed
in Hive 1.1.0. Is this intended? If so, how can I access the files in the
distributed cache added with ADD FILE?
Regards,
Zsolt
[jira] [Created] (HIVE-10615) LLAP: Invalid containerId prefix
Prasanth Jayachandran created HIVE-10615:
Summary: LLAP: Invalid containerId prefix
Key: HIVE-10615
URL: https://issues.apache.org/jira/browse/HIVE-10615
Project: Hive
Issue Type: Sub-task
Affects Versions: llap
Reporter: Prasanth Jayachandran
I encountered this error when I ran a simple query in llap mode today.
{code}org.apache.hadoop.ipc.RemoteException(java.io.IOException):
java.lang.IllegalArgumentException: Invalid ContainerId prefix:
at
org.apache.hadoop.yarn.api.records.ContainerId.fromString(ContainerId.java:211)
at
org.apache.hadoop.yarn.util.ConverterUtils.toContainerId(ConverterUtils.java:178)
at
org.apache.tez.dag.app.TezTaskCommunicatorImpl$TezTaskUmbilicalProtocolImpl.heartbeat(TezTaskCommunicatorImpl.java:311)
at
org.apache.hadoop.hive.llap.tezplugins.LlapTaskCommunicator$LlapTaskUmbilicalProtocolImpl.heartbeat(LlapTaskCommunicator.java:398)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.apache.hadoop.ipc.WritableRpcEngine$Server$WritableRpcInvoker.call(WritableRpcEngine.java:514)
at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:962)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2039)
at org.apache.hadoop.ipc.Server$Handler$1.run(Server.java:2035)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2033)
at org.apache.hadoop.ipc.Client.call(Client.java:1468)
at org.apache.hadoop.ipc.Client.call(Client.java:1399)
at
org.apache.hadoop.ipc.WritableRpcEngine$Invoker.invoke(WritableRpcEngine.java:244)
at com.sun.proxy.$Proxy14.heartbeat(Unknown Source)
at
org.apache.hadoop.hive.llap.daemon.impl.LlapTaskReporter$HeartbeatCallable.heartbeat(LlapTaskReporter.java:256)
at
org.apache.hadoop.hive.llap.daemon.impl.LlapTaskReporter$HeartbeatCallable.call(LlapTaskReporter.java:184)
at
org.apache.hadoop.hive.llap.daemon.impl.LlapTaskReporter$HeartbeatCallable.call(LlapTaskReporter.java:126)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
15/05/05 15:24:22 [Task-Executor-0] INFO task.TezTaskRunner : Interrupted while
waiting for task to complete. Interrupting task
15/05/05 15:24:22 [TezTaskRunner_attempt_1430816501738_0034_1_00_00_0] INFO
task.TezTaskRunner : Encounted an error while executing task:
attempt_1430816501738_0034_1_00_00_0
java.lang.InterruptedException
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:2017)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2052)
at
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at
java.util.concurrent.ExecutorCompletionService.take(ExecutorCompletionService.java:193)
at
org.apache.tez.runtime.LogicalIOProcessorRuntimeTask.initialize(LogicalIOProcessorRuntimeTask.java:218)
at
org.apache.tez.runtime.task.TezTaskRunner$TaskRunnerCallable$1.run(TezTaskRunner.java:177)
at
org.apache.tez.runtime.task.TezTaskRunner$TaskRunnerCallable$1.run(TezTaskRunner.java:172)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at
org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1628)
at
org.apache.tez.runtime.task.TezTaskRunner$TaskRunnerCallable.callInternal(TezTaskRunner.java:172)
at
org.apache.tez.runtime.task.TezTaskRunner$TaskRunnerCallable.callInternal(TezTaskRunner.java:168)
at org.apache.tez.common.CallableWithNdc.call(CallableWithNdc.java:36)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
15/05/05 15:24:22 [Task-Executor-0] INFO impl.TaskRunnerCallable : Failed to
run:
[jira] [Created] (HIVE-10612) HIVE-10578 broke TestSQLStdHiveAccessControllerHS2 tests
Thejas M Nair created HIVE-10612: Summary: HIVE-10578 broke TestSQLStdHiveAccessControllerHS2 tests Key: HIVE-10612 URL: https://issues.apache.org/jira/browse/HIVE-10612 Project: Hive Issue Type: Bug Components: Authorization Reporter: Thejas M Nair Assignee: Thejas M Nair The change in HIVE-10578 has broken two tests in TestSQLStdHiveAccessControllerHS2 - testConfigProcessing and testConfigProcessingCustomSetWhitelistAppend. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Why SQL Standards Based Authorization is implemented on HiveServer2 side only?
The issue is that security checks are done in the client. In order to fully do them in the metastore we would have been forced to move significant amounts of functionality out of the client and into the metastore. Query parsing and planning would have had to be moved to the metastore, basically making it HS2. A few more comments inline: Sergey Tryuber mailto:stryu...@gmail.com May 4, 2015 at 12:56 Hi Guys, My understanding is that there are two safe ways of usage of SQL Standards Based Authorization (SSBA): 1. Hide Hive Metastore from the world by embedding it into HiveServer2. *MetaStoreAuthzAPIAuthorizerEmbedOnly* configuration for Metastore is only a half-protection since everyone can change tables-specific metadata. 2. Have two Metastores, but Public one should be additionally protected by Storage Based Authorization Option #2 is much more demanded, since there are too many frameworks in Hadoop ecosystem which use Hive Metastore. But necessity to keep both SQL and HDFS ACLs in sync is an administration nightmare (especially taking into account that doAs option is false in SSBA mode). *Why isn't it possible to add SSBA-like authorizer to Hive Metastore as well?* The authorizer could check if a user has permissions to update table-specific metadata according to his role and username. I could even imagine following layout: 1. All the files in Hive tables can be accessed only by few system users (hive, spark-sql, impala, etc) How would you accomplish this? Hive's files are stored in HDFS and thus must work with HDFS file permissions. You could construct a group that contained those users and make the files accessible to that group, but each cluster admin would have to do that. 2. There is only a single place of granting permissions - through SQL standards and all SQL-like frameworks around the metastore should use it We can't break backwards compatibility, so we could make this an option but we couldn't enforce it. 3. Additional HDFS permissions configuration would be needed only for rare cases of data access from non-impersonated execution pipelines (Spark Core, etc) 4. No necessity to have embedded into HiveServer2 metastore, no strange configuration options, easier for understanding and documentation May be I've missed something in my understanding... So, please, point me to my mistake in this case.
Re: Fwd: [DISCUSS] Allow any jira user to assign HIVE bugs to them self
It turns out there's a limit on the number of people you can list as contributors for any given JIRA project. I bumped into this a couple months back when I tried adding someone to the list and found this: https://issues.apache.org/jira/browse/INFRA-7293 On Mon, May 4, 2015 at 10:02 PM, Lefty Leverenz leftylever...@gmail.com wrote: Sure, go for it. -- Lefty On Mon, May 4, 2015 at 5:33 PM, Thejas Nair thejas.n...@gmail.com wrote: As Lefty noted, we don't require anyone being made a jira contributor or uploading a patch to have ICLA on file. Apache does not require that, though that is encouraged. So allowing any user to be a contributor without asking for permission does not change things with respect to ICLA. Looks like people are on board with this. I will change the settings in another day as long as there are no objections. On Sat, May 2, 2015 at 11:44 PM, Lefty Leverenz leftylever...@gmail.com wrote: Hive only requires committers to sign ICLAs. That doesn't seem to provide any legal protection when non-committers contribute patches. In days gone by, JIRA made us assign rights to Apache when we attached a patch to an issue. That's still in the instructions for Contributing Your Work https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-ContributingYourWork : Please note that the attachment should be granted license to ASF for inclusion in ASF work although the JIRA GUI doesn't have that option anymore. See Apache's page on licenses http://www.apache.org/licenses/#clas: The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via postal mail, fax or email) an Individual Contributor License Agreement *(highlighting added)*. So documentation in the wiki should also be covered by ICLAs. Carried to extremes, anyone who participates on a mailing list, comments on a JIRA issue, or reviews a patch should sign an ICLA. -- Lefty On Sun, May 3, 2015 at 12:30 AM, Sushanth Sowmyan khorg...@gmail.com wrote: I seem to remember something on the lines of that the traditional reason was so that a project could be sure that the contributor had an ICLA on file with apache so as to not expose the project to legal risk of code that was contributed that the contributor did not have any rights to. We should probably check with folks from other projects who've had experience dealing with stuff like this? Maybe Owen? On May 2, 2015 17:08, Thejas Nair thejas.n...@gmail.com wrote: Sending again, didn't make to the list for some reason. -- Forwarded message -- From: Thejas Nair thejas.n...@gmail.com Date: Fri, May 1, 2015 at 1:53 PM Subject: [DISCUSS] Allow any jira user to assign HIVE bugs to them self To: dev dev@hive.apache.org I am not sure why a user needs to ask to be added as a contributor in HIVE jira to be able to assign jiras to themselves. I don't see it adding any value. Also the jira ADMIN UI for adding this is usually flaky. I think we should let any jira users assign the bugs to them self. Looks like adding jira-users group to contributions would do it. Thoughts ? Thanks, Thejas
[jira] [Created] (HIVE-10610) hive command fails to get hadoop version
Shwetha G S created HIVE-10610:
--
Summary: hive command fails to get hadoop version
Key: HIVE-10610
URL: https://issues.apache.org/jira/browse/HIVE-10610
Project: Hive
Issue Type: Bug
Reporter: Shwetha G S
If debug level logging is enabled, hive command fails with the following
exception:
{noformat}
apache-hive-1.2.0-SNAPSHOT-bin$ ./bin/hive
Unable to determine Hadoop version information from 13:54:07,683
'hadoop version' returned:
2015-05-05 13:54:08,014 DEBUG - [main:] ~ version: 2.5.0-cdh5.3.3
(VersionInfo:171) Hadoop 2.5.0-cdh5.3.3 Subversion
http://github.com/cloudera/hadoop -r 82a65209d6e9e4a2b41fdbcd8190c7ea38730627
Compiled by jenkins on 2015-04-08T22:00Z Compiled with protoc 2.5.0 From source
with checksum 1531e104cdad7489656f44875f3334b This command was run using
/Users/sshivalingamurthy/installs/hadoop-2.5.0-cdh5.3.3/share/hadoop/common/hadoop-common-2.5.0-cdh5.3.3.jar
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HIVE-10613) HCatSchemaUtils getHCatFieldSchema should include field comment
Thomas Friedrich created HIVE-10613: --- Summary: HCatSchemaUtils getHCatFieldSchema should include field comment Key: HIVE-10613 URL: https://issues.apache.org/jira/browse/HIVE-10613 Project: Hive Issue Type: Bug Components: HCatalog Affects Versions: 1.0.0 Reporter: Thomas Friedrich Assignee: Thomas Friedrich Priority: Minor HCatSchemaUtils.getHCatFieldSchema converts a FieldSchema to a HCatFieldSchema. Instead of initializing the comment property from the FieldSchema object, the comment in the HCatFieldSchema is always set to null. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Review Request 33861: HIVE-10608 Fix useless 'if' stamement in RetryingMetaStoreClient (135)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33861/ --- Review request for hive and Szehon Ho. Bugs: HIVE-10608 https://issues.apache.org/jira/browse/HIVE-10608 Repository: hive-git Description --- HIVE-10608 Fix useless 'if' stamement in RetryingMetaStoreClient (135) Diffs - metastore/src/java/org/apache/hadoop/hive/metastore/RetryingMetaStoreClient.java 1b6487af748202d1d0411ac23a7507a9fbd7f251 Diff: https://reviews.apache.org/r/33861/diff/ Testing --- Thanks, Alexander Pivovarov
[jira] [Created] (HIVE-10614) schemaTool upgrade from 0.14.0 to 1.3.0 causes failure
Hari Sankar Sivarama Subramaniyan created HIVE-10614:
Summary: schemaTool upgrade from 0.14.0 to 1.3.0 causes failure
Key: HIVE-10614
URL: https://issues.apache.org/jira/browse/HIVE-10614
Project: Hive
Issue Type: Bug
Components: Metastore
Reporter: Hari Sankar Sivarama Subramaniyan
Assignee: Hari Sankar Sivarama Subramaniyan
Priority: Critical
./schematool -dbType mysql -upgradeSchemaFrom 0.14.0 -verbose
{code}
++--+
|
|
++--+
| HIVE-7018 Remove Table and Partition tables column LINK_TARGET_ID from
Mysql for other DBs do not have it |
++--+
1 row selected (0.004 seconds)
0: jdbc:mysql://node-1.example.com/hive DROP PROCEDURE IF EXISTS RM_TLBS_LINKID
No rows affected (0.005 seconds)
0: jdbc:mysql://node-1.example.com/hive DROP PROCEDURE IF EXISTS
RM_PARTITIONS_LINKID
No rows affected (0.006 seconds)
0: jdbc:mysql://node-1.example.com/hive DROP PROCEDURE IF EXISTS RM_LINKID
No rows affected (0.002 seconds)
0: jdbc:mysql://node-1.example.com/hive CREATE PROCEDURE RM_TLBS_LINKID()
BEGIN IF EXISTS (SELECT * FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE
`TABLE_NAME` = 'TBLS' AND `COLUMN_NAME` = 'LINK_TARGET_ID') THEN ALTER TABLE
`TBLS` DROP FOREIGN KEY `TBLS_FK3` ; ALTER TABLE `TBLS` DROP KEY `TBLS_N51` ;
ALTER TABLE `TBLS` DROP COLUMN `LINK_TARGET_ID` ; END IF; END
Error: You have an error in your SQL syntax; check the manual that corresponds
to your MySQL server version for the right syntax to use near '' at line 1
(state=42000,code=1064)
Closing: 0: jdbc:mysql://node-1.example.com/hive?createDatabaseIfNotExist=true
org.apache.hadoop.hive.metastore.HiveMetaException: Upgrade FAILED! Metastore
state would be inconsistent !!
org.apache.hadoop.hive.metastore.HiveMetaException: Upgrade FAILED! Metastore
state would be inconsistent !!
at
org.apache.hive.beeline.HiveSchemaTool.doUpgrade(HiveSchemaTool.java:229)
at org.apache.hive.beeline.HiveSchemaTool.main(HiveSchemaTool.java:468)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.hadoop.util.RunJar.run(RunJar.java:221)
at org.apache.hadoop.util.RunJar.main(RunJar.java:136)
Caused by: java.io.IOException: Schema script failed, errorcode 2
at
org.apache.hive.beeline.HiveSchemaTool.runBeeLine(HiveSchemaTool.java:355)
at
org.apache.hive.beeline.HiveSchemaTool.runBeeLine(HiveSchemaTool.java:326)
at
org.apache.hive.beeline.HiveSchemaTool.doUpgrade(HiveSchemaTool.java:224)
{code}
Looks like HIVE-7018 has introduced stored procedure as part of mysql upgrade
script and it is causing issues with schematool upgrade.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Fwd: [DISCUSS] Allow any jira user to assign HIVE bugs to them self
I guess the limit is around the number of entries in the contributor group, and adding a jira-user group would not count towards that. Let me give it a try. That INFRA jira is another good reason to add jira-users group to contributors! On Mon, May 4, 2015 at 11:31 PM, Carl Steinbach cwsteinb...@gmail.com wrote: It turns out there's a limit on the number of people you can list as contributors for any given JIRA project. I bumped into this a couple months back when I tried adding someone to the list and found this: https://issues.apache.org/jira/browse/INFRA-7293 On Mon, May 4, 2015 at 10:02 PM, Lefty Leverenz leftylever...@gmail.com wrote: Sure, go for it. -- Lefty On Mon, May 4, 2015 at 5:33 PM, Thejas Nair thejas.n...@gmail.com wrote: As Lefty noted, we don't require anyone being made a jira contributor or uploading a patch to have ICLA on file. Apache does not require that, though that is encouraged. So allowing any user to be a contributor without asking for permission does not change things with respect to ICLA. Looks like people are on board with this. I will change the settings in another day as long as there are no objections. On Sat, May 2, 2015 at 11:44 PM, Lefty Leverenz leftylever...@gmail.com wrote: Hive only requires committers to sign ICLAs. That doesn't seem to provide any legal protection when non-committers contribute patches. In days gone by, JIRA made us assign rights to Apache when we attached a patch to an issue. That's still in the instructions for Contributing Your Work https://cwiki.apache.org/confluence/display/Hive/HowToContribute#HowToContribute-ContributingYourWork : Please note that the attachment should be granted license to ASF for inclusion in ASF work although the JIRA GUI doesn't have that option anymore. See Apache's page on licenses http://www.apache.org/licenses/#clas: The ASF desires that all contributors of ideas, code, or documentation to the Apache projects complete, sign, and submit (via postal mail, fax or email) an Individual Contributor License Agreement *(highlighting added)*. So documentation in the wiki should also be covered by ICLAs. Carried to extremes, anyone who participates on a mailing list, comments on a JIRA issue, or reviews a patch should sign an ICLA. -- Lefty On Sun, May 3, 2015 at 12:30 AM, Sushanth Sowmyan khorg...@gmail.com wrote: I seem to remember something on the lines of that the traditional reason was so that a project could be sure that the contributor had an ICLA on file with apache so as to not expose the project to legal risk of code that was contributed that the contributor did not have any rights to. We should probably check with folks from other projects who've had experience dealing with stuff like this? Maybe Owen? On May 2, 2015 17:08, Thejas Nair thejas.n...@gmail.com wrote: Sending again, didn't make to the list for some reason. -- Forwarded message -- From: Thejas Nair thejas.n...@gmail.com Date: Fri, May 1, 2015 at 1:53 PM Subject: [DISCUSS] Allow any jira user to assign HIVE bugs to them self To: dev dev@hive.apache.org I am not sure why a user needs to ask to be added as a contributor in HIVE jira to be able to assign jiras to themselves. I don't see it adding any value. Also the jira ADMIN UI for adding this is usually flaky. I think we should let any jira users assign the bugs to them self. Looks like adding jira-users group to contributions would do it. Thoughts ? Thanks, Thejas
[jira] [Created] (HIVE-10611) Mini tez tests wait for 5 minutes before shutting down
Vikram Dixit K created HIVE-10611: - Summary: Mini tez tests wait for 5 minutes before shutting down Key: HIVE-10611 URL: https://issues.apache.org/jira/browse/HIVE-10611 Project: Hive Issue Type: Bug Components: Tests Affects Versions: 1.3.0 Reporter: Vikram Dixit K Assignee: Vikram Dixit K Currently, at shutdown, the tez mini cluster waits for the session to close before shutting down the cluster. This ends up being 5 minutes - the default value. We can shut down the session to alleviate this situation. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
