From dev-return-59923-archive-asf-public=cust-asf.ponee.io@phoenix.apache.org Mon Feb 10 07:22:08 2020 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 14D4218062B for ; Mon, 10 Feb 2020 08:22:07 +0100 (CET) Received: (qmail 77981 invoked by uid 500); 10 Feb 2020 07:22:07 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 77959 invoked by uid 99); 10 Feb 2020 07:22:06 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Feb 2020 07:22:06 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 18EE4C0C21 for ; Mon, 10 Feb 2020 07:22:06 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=cloudera.com Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id wXapdse_mLxK for ; Mon, 10 Feb 2020 07:22:03 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2a00:1450:4864:20::436; helo=mail-wr1-x436.google.com; envelope-from=stoty@cloudera.com; receiver= Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id E1EB57DD70 for ; Mon, 10 Feb 2020 07:22:02 +0000 (UTC) Received: by mail-wr1-x436.google.com with SMTP id c9so6163936wrw.8 for ; Sun, 09 Feb 2020 23:22:02 -0800 (PST) X-ASF-DKIM-Sig: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudera.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=oXrVAkutvkmlFbtcDIKhQiCegb6xDk4Z0RQnOR+keXk=; b=mHCK+J2OBMqXT5wf3Ky2ofQ/i+GksoxtgOw4U/dvxA555BvyNV2KD5zFyb4tHXIChX iJmoqJ6s2M6zdEVXceKfjlJRHft5KpPCAOATrERdmWFyWMe4FgpzNYKgKbnxJd9fr4xw cDNVgH8GN0tk4AHpNAPFhIqLqlt8ufQ26B+v63P7umbn4wX1/FFO8y11E6Z9wXEDnBF2 qWAiQEHhRZ6UFO4dhnrU2sDJvoqj2fBZNK24RJdSdYY/bleccIOy6NrsdQn8B1F8sS0/ YMDUEBvSvlTySCVcUZvtnHcvURe8g+WgmJZpPC/PCTWrjjgjmpraOBnNmIdUFhRlgsQE mQuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=oXrVAkutvkmlFbtcDIKhQiCegb6xDk4Z0RQnOR+keXk=; b=MT8MdbwXeRZbC0XFG/j9f+eVk+5BRYPku4+MLs2HxHn8aWG1yOo3BeeKeBMl7Zr9wJ atziEwh1STc3VsK6aDKqJQ/KF8hfcaGfVG4RRv7cFtRgpNLiOHKS2FyRxGcYQxceguth gbPHj59B2tLMjjTaPApLPPMiEIMf2l4lz8+HHq2HqdCl67m9JU7WkfUcOts96PuCCCa+ rRdPrRUPwpbtOAwbbVA3DybF0frTUjEd4I0ykdtX/FrhFwzKjl1lnIF9OZb8KG71S98a N33ivqe4adJ4TZu/TvlB/98Nb7u4uAOWlnDJe/MVqBQ9yo5Uw6zh3ONBfMkQc07rcqI+ zyZw== X-Gm-Message-State: APjAAAWnnewbi2HP58hoYDgNsZwog7Z6QKZc0e3+TRtoIHCunqJrCQHb C9LvP0MOfw7slYlD9tcx7ZQCDXomunoJbkYlldfIgubObdk= X-Google-Smtp-Source: APXvYqxq5DVJxy+rd+/Jb+29zl6+CsX8pbpTbjLX32hHHprYvi5ILufXDDMw/SWMnhi0ZFzsLew1dW4WRBwwk/azNoo= X-Received: by 2002:a5d:610a:: with SMTP id v10mr94995wrt.267.1581319316077; Sun, 09 Feb 2020 23:21:56 -0800 (PST) MIME-Version: 1.0 References: <53c742d6-ac66-bb0b-403c-421bab6990db@apache.org> In-Reply-To: From: =?UTF-8?B?SXN0dsOhbiBUw7N0aA==?= Date: Mon, 10 Feb 2020 08:21:45 +0100 Message-ID: Subject: Re: [DISCUSS] Unifying the 4.x branches To: dev@phoenix.apache.org Content-Type: multipart/alternative; boundary="0000000000001ca835059e3398e2" --0000000000001ca835059e3398e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the feedback, Geoffrey. I took the lazy option of just creating compatibility methods to paper over the HBase API changes (emulate the latest version) when we are calling into HBase. For the APIs implemented by Phoenix, I added compatibility superclasses. So I expect that we will be able to add a dummy RegionObserver.preWALAppend to the compatibility coprocessor superclass(es), so that the same code compiles for older versions as well. Of course if other code paths depend on having that functionality, those should also be gated by similar compatibility shims/version checks. My current approach is a quick fix, and does not preclude (in fact it enables) later efforts at refactoring/cleanup. On Fri, Feb 7, 2020 at 7:31 PM Geoffrey Jacoby wrote: > If unification could be done, that would be great. (I apologize that I > haven't had the bandwidth over the past week or two to take a close look = at > the work Istvan has been doing to unify the 5.x branches -- as one who > spends too much time cherry-picking I very much appreciate this effort! := -) > ) > > I still think the hardest part, as I think I mentioned in some previous > thread, is what to do when the HBase coprocs themselves diverge between > minor versions, as they can do. How do you handle the fact that > RegionObserver.preWALAppend exists in 1.5 but not 1.3 and 1.4, and will > exist in 2.3 but not 2.2 and 2.1? And that therefore any features that > depend on preWALAppend existing (none yet, but they're coming later this > year) will work in a 1.5 or 2.3 environment, but not a 1.4 or 2.2 one? > > Since our coprocessors tend to be giant monoliths, trying to create > release-based versions of them selectable by maven profile would > either require lots of developer copy/paste for each change, or a > significant (probably long overdue) refactor to make the coprocs small > shims that call out to smaller, fine-grained classes that can occasionall= y > be release-specific. > > Geoffrey > > On Fri, Feb 7, 2020 at 9:31 AM Josh Elser wrote: > > > Sounds like a good idea to me. > > > > On 2/6/20 8:40 AM, Istvan Toth wrote: > > > Hello! > > > > > > Now that we have a working solution in master for handling different > > HBase > > > minor versions, I think that we should think about applying the same > > > template to 4.x., and unifying the 4.x-HBase-1.3, 1.4, and 1.5 > branches. > > > > > > Are there any intentional differences between the branches, apart fro= m > > > having to conform to the slightly different APIs ? > > > If there are, what are they, and are they considered blockers? > > > > > > Any other reasons not do this ? > > > > > > I expect that based on my experience with the master branch, I can do > > this > > > in a few days, but I don't want to put in the effort if there is no > > > interest in it. > > > > > > My plan is to take the 1.5 branch as a base. > > > > > > best regards > > > Istvan > > > > > > --=20 *Istv=C3=A1n T=C3=B3th* | Sr. Software Engineer t. (36) 70 283-1788 stoty@cloudera.com [image: Cloudera] [image: Cloudera on Twitter] [image: Cloudera on Facebook] [image: Cloudera on LinkedIn] ------------------------------ --0000000000001ca835059e3398e2--