calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Brown <...@mult.ifario.us>
Subject Re: Should Jackson-annotated POJOs stick around
Date Tue, 11 Aug 2015 18:25:20 GMT
Just to let you guys know that you have some Jackson folks lurking around
on the list, so if there are things that we can do to help PB/JSON/other
work smoothly, let us know, as we're actively thinking about the best ways
to deal with multiple data protocols.

—
prb@mult.ifario.us | Multifarious, Inc. | http://mult.ifario.us/

On Tue, Aug 11, 2015 at 11:21 AM, Julian Hyde <jhyde@apache.org> wrote:

> The conventional way of implementing a driver uses an end-to-end
> design: "just use the MySQL driver and have a MySQL server on the
> other end and it will just work".
>
> With Avatica I'm trying to introduce a layered approach (inspired by
> the OSI model) where we specify what happens at several levels. We
> specify a wire format, and we specify the Java API.
>
> An application doesn't have to to use all of the levels. Some
> applications might want to use the Java API but plug in a different
> transport. Other applications might want to build a C or Python API on
> top of the wire format.
>
> My goal is to ensure that the driver stack can be re-used for
> different database engines, and from different languages, and that a
> driver in local mode is substantially the same as a driver in remote
> mode.
>
> Notice I said "a wire format". I don't mind if there are other wire
> formats. But I would be concerned if one transport muscled in and left
> its mark up and down the whole stack.
>
>
> On Tue, Aug 11, 2015 at 10:58 AM, Josh Elser <josh.elser@gmail.com> wrote:
> > Ok, that's where the confusion is coming in :). I envision protocol
> buffer
> > objects replacing the POJOs in both the wire api and the Meta API.
> >
> > Trying to do both seems without gain for me (again, aside from preserving
> > backwards compatibility with existing releases). If that requires a
> > different Meta interface+impl (or a translation layer), that's fine too
> --
> > just extra work (and a slight performance hit on whichever is treated as
> the
> > reference object).
> >
> > Does that make sense?
> >
> > Julian Hyde wrote:
> >>
> >> Yes, the POJOs are needed. The service layer (which for a particular
> >> client may or may not be backed by RPC) consists of methods that take
> >> complex arguments and return complex results. Those arguments and
> >> results are expressed as POJOs.
> >>
> >> One example:
> >>
> >> Frame fetch(StatementHandle h, List<TypedValue>  parameterValues, long
> >> offset,
> >>      int fetchMaxRowCount);
> >>
> >> class Frame {
> >>    public final long offset;
> >>    public final boolean done;
> >>    public final Iterable<Object>  rows;
> >> }
> >>
> >> public class TypedValue {
> >>    public final ColumnMetaData.Rep type;
> >>    public final Object value;
> >> }
> >>
> >> The POJOs are definitely needed for the Java API Meta and appear in
> >> some form by whatever the wire protocol is.
> >>
> >> Julian
> >>
> >>
> >>
> >>
> >> On Tue, Aug 11, 2015 at 10:16 AM, Josh Elser<josh.elser@gmail.com>
> wrote:
> >>>
> >>> Pulling this out to email to avoid cluttering JIRA. I feel like I might
> >>> not
> >>> be on the same page.
> >>>
> >>> I see CALCITE-839 and CALCITE-840 being one in the same change, or at
> >>> least
> >>> the root cause being solved by it.
> >>>
> >>> Julian, I'm getting the impression that you envision protocol buffer
> >>> encoding being just another option for encoding requests and responses.
> >>> My
> >>> opinion is that using protocol buffers to define these requests and
> >>> responses completely invalidates the need to support these POJOs. These
> >>> objects should be usable cross-language, so aside from support the
> >>> releases
> >>> of Calcite which shipped only these POJOs, I don't see a need to
> maintain
> >>> them.
> >>>
> >>> I am admittedly hedging my bet that the PB devs will release a new
> >>> version
> >>> that has the advertised JSON-esque serialization format (instead of
> just
> >>> a
> >>> binary format). If this ultimately falls through, POJOs that just wrap
> >>> the
> >>> PB classes could also be done.
> >>>
> >>> I just wanted to make sure I'm not dancing by myself and that we're all
> >>> in
> >>> agreement on a general direction.
> >>>
> >>> -------- Original Message --------
> >>> Subject: [jira] [Commented] (CALCITE-839) Remove Jackson annotations
> from
> >>> POJO classes in Meta
> >>> Date: Tue, 11 Aug 2015 05:41:45 +0000 (UTC)
> >>> From: Julian Hyde (JIRA)<jira@apache.org>
> >>> Reply-To: dev@calcite.incubator.apache.org
> >>> To: issues@calcite.incubator.apache.org
> >>>
> >>>
> >>>      [
> >>>
> >>>
> https://issues.apache.org/jira/browse/CALCITE-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14681279#comment-14681279
> >>> ]
> >>>
> >>> Julian Hyde commented on CALCITE-839:
> >>> -------------------------------------
> >>>
> >>> Well then, I've assigned CALCITE-840 to you.
> >>>
> >>>> Remove Jackson annotations from POJO classes in Meta
> >>>> ----------------------------------------------------
> >>>>
> >>>>                  Key: CALCITE-839
> >>>>                  URL:
> https://issues.apache.org/jira/browse/CALCITE-839
> >>>>              Project: Calcite
> >>>>           Issue Type: Bug
> >>>>           Components: avatica
> >>>>             Reporter: Julian Hyde
> >>>>             Assignee: Julian Hyde
> >>>>
> >>>> The Meta interface contains several POJO classes that represent RPC
> >>>> requests or responses. Currently a few of those classes have Jackson
> >>>> annotations such as @JsonCreator, @JsonProperty to help Jackson
> >>>> serialize
> >>>> the POJO to JSON and de-serialize from JSON to the object.
> >>>> As [~ndimiduk] pointed out in
> >>>>
> >>>>
> http://mail-archives.apache.org/mod_mbox/incubator-calcite-dev/201503.mbox/%3CCANZa=GvKGD+BKJ4+eJMuO6iVhS+OkGSkG1VwDAZCy-ZijyyyPw@mail.gmail.com%3E
> >>>> these annotations are a "code smell" and should be removed. It makes
> it
> >>>> look
> >>>> as if Jackson is the only possible transport, which is not the case.
> We
> >>>> can
> >>>> continue to use Jackson as a transport, just specify the mappings
> >>>> elsewhere,
> >>>> not as annotations.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> This message was sent by Atlassian JIRA
> >>> (v6.3.4#6332)
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message