calcite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Hyde <jh...@apache.org>
Subject Re: Should Jackson-annotated POJOs stick around
Date Tue, 11 Aug 2015 17:52:15 GMT
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
View raw message