Mailing-List: contact commits-help@beam.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@beam.apache.org
Date: Sat, 2 Dec 2017 08:35:00 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: commits@beam.apache.org
Message-ID: <JIRA.13116941.1510138708000.371034.1512203700289@Atlassian.JIRA>
In-Reply-To: <JIRA.13116941.1510138708000@Atlassian.JIRA>
References: <JIRA.13116941.1510138708000@Atlassian.JIRA> <JIRA.13116941.1510138708123@jira-lw-us.apache.org>
Subject: [jira] [Commented] (BEAM-3157) BeamSql transform should support
 other PCollection types
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Sat, 02 Dec 2017 08:35:06 -0000


    [ https://issues.apache.org/jira/browse/BEAM-3157?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D16275=
479#comment-16275479 ]=20

ASF GitHub Bot commented on BEAM-3157:
--------------------------------------

akedin opened a new pull request #4204: [BEAM-3157] Generate BeamRecord typ=
es from Pojos
URL: https://github.com/apache/beam/pull/4204
=20
=20
   This implements automatic generation of BeamRecordTypes and BeamRecordSq=
lTypes from pojo types. Work is being done as part of [BEAM-3157](https://i=
ssues.apache.org/jira/browse/BEAM-3157).
  =20
   Main piece is [RecordFactory](https://github.com/apache/beam/compare/mas=
ter...akedin:generate-record-types?expand=3D1#diff-55e6442c81f404c1004a445b=
550f03c9) which exposes a method to generate BeamRecords from pojos. See [R=
ecordFactoryTest](https://github.com/apache/beam/compare/master...akedin:ge=
nerate-record-types?expand=3D1#diff-869b654afa6699d55098a8fc3f2e5740) for u=
sage examples.=20
  =20
   The plan is to integrate this into the Beam SQL framework. Integration i=
nto SQL will be done in the future PRs.
  =20
   Records generation is a major step to simplify conversion of pojo model =
to BeamRecords. Immediate use case is implementation of Nexmark queries in =
Beam SQL using existing pojo models.=20
   This can also be used as a starting point for code generation for schema=
-aware collections.
  =20
  =20
  =20
  =20
  =20
   Follow this checklist to help us incorporate your contribution quickly a=
nd easily:
  =20
    - [ ] Make sure there is a [JIRA issue](https://issues.apache.org/jira/=
projects/BEAM/issues/) filed for the change (usually before you start worki=
ng on it).  Trivial changes like typos do not require a JIRA issue.  Your p=
ull request should address just this issue, without pulling in other change=
s.
    - [ ] Each commit in the pull request should have a meaningful subject =
line and body.
    - [ ] Format the pull request title like `[BEAM-XXX] Fixes bug in Appro=
ximateQuantiles`, where you replace `BEAM-XXX` with the appropriate JIRA is=
sue.
    - [ ] Write a pull request description that is detailed enough to under=
stand what the pull request does, how, and why.
    - [ ] Run `mvn clean verify` to make sure basic checks pass. A more tho=
rough check will be performed on your pull request automatically.
    - [ ] If this contribution is large, please file an Apache [Individual =
Contributor License Agreement](https://www.apache.org/licenses/icla.pdf).
  =20
   ---
  =20

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
=20
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


> BeamSql transform should support other PCollection types
> --------------------------------------------------------
>
>                 Key: BEAM-3157
>                 URL: https://issues.apache.org/jira/browse/BEAM-3157
>             Project: Beam
>          Issue Type: Improvement
>          Components: dsl-sql
>            Reporter: Isma=C3=ABl Mej=C3=ADa
>            Assignee: Anton Kedin
>
> Currently the Beam SQL transform only supports input and output data repr=
esented as a BeamRecord. This seems to me like an usability limitation (eve=
n if we can do a ParDo to prepare objects before and after the transform).
> I suppose this constraint comes from the fact that we need to map name/ty=
pe/value from an object field into Calcite so it is convenient to have a sp=
ecific data type (BeamRecord) for this. However we can accomplish the same =
by using a PCollection of JavaBean (where we know the same information via =
the field names/types/values) or by using Avro records where we also have t=
he Schema information. For the output PCollection we can map the object via=
 a Reference (e.g. a JavaBean to be filled with the names of an Avro object=
).
> Note: I am assuming for the moment simple mappings since the SQL does not=
 support composite types for the moment.
> A simple API idea would be something like this:
> A simple filter:
> PCollection<MyPojo> col =3D BeamSql.query("SELECT * FROM .... WHERE ...")=
.from(MyPojo.class);
> A projection:
> PCollection<MyNewPojo> newCol =3D BeamSql.query("SELECT id, name").from(M=
yPojo.class).as(MyNewPojo.class);
> A first approach could be to just add the extra ParDos + transform DoFns =
however I suppose that for memory use reasons maybe mapping directly into C=
alcite would make sense.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)