[GitHub] calcite-avatica-go issue #19: Fix readme

[hsyuan]

Github user hsyuan commented on the issue:

https://github.com/apache/calcite-avatica-go/pull/19
  
So you don't need to open a PR, just commit it.


---

[GitHub] calcite-avatica-go pull request #19: Fix readme

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/19


---

[GitHub] calcite-avatica-go pull request #19: Fix readme

[F21]

GitHub user F21 opened a pull request:

https://github.com/apache/calcite-avatica-go/pull/19

Fix readme



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Boostport/calcite-avatica-go fix-readme

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica-go/pull/19.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #19


commit d31aa931ba548643337c7a537f08ef8e555c16c8
Author: Francis Chuang 
Date:   2018-04-17T05:31:35Z

Fix readme




---

Re: Towards Avatica-Go release ?.?

[Francis Chuang]

Julian,

The release (3.0.0-rc0) is ready for voting. Do the artifacts need to be 
uploaded before sending out the release email? If so, can you please 
sign them? Instructions for making and signing release artifacts are 
here: 
https://github.com/apache/calcite-avatica-go/blob/master/site/go_development.md#releasing


Francis

On 16/04/2018 4:44 PM, Julian Hyde wrote:

Yes, the script isn’t very complicated. We probably need half a dozen lines of 
shell script to create the tar.gz file, sign it, and generate .sha256 
checksums. I don’t mind where you put those lines of shell script, as long as 
the next RM can find them.

The site looks good. It doesn’t have to be perfect before the release as we can 
easily update it after the release. I’d change the date in history.md from 
2017-08-xx to 2018-04-23. If all goes well the release could be announced ~5 
working days after the vote starts.

I’m not sure whether "go” will work. Jekyll markdown is a bit more limited 
than GitHub markdown. We seem to have to use {% highlight sql %} for code sections.

There are probably other issues in the site but we’ll only know when we start 
running jekyll to build and deploy the avatica site.

Julian



On Apr 15, 2018, at 11:27 PM, F21  wrote:

Hey Julian,

The code is in a releasable state. A few questions:
- Building a binary of a library in Go is not useful/meaningful. For the 
release, we just need to tar gz the git repo and sign it. Do you still need a 
script for this? Otherwise we can write the instructions somewhere in the site/ 
directory.

- Still need to write the release notes. Can you have a look at 
https://github.com/apache/calcite-avatica-go/pull/2 to see if I have structured 
the site/ directory correctly? The PR is a bit stale, but it shouldn't be too 
much work to get it up to date.

Francis

On 10/04/2018 8:51 AM, Julian Hyde wrote:

Thanks, Francis.

The most important step is to come up with a release vote email with the same items 
as [1]: release notes, git commit, artifacts to be voted on in 
dist.apache.org/repos/dist/dev , md5 and 
sha256 hashes. (The staged maven repository does not apply.)

Per apache policy, the release needs to be signed by a PMC member. I’ll be 
happy to do that. Or we could skip signing for the first couple of RCs.

Maybe write a shell script that creates the files, and a “howto” that the next 
RM can follow? I’ll be able to run the script when it’s time to create signed 
artifacts.

Julian

[1] 
https://lists.apache.org/thread.html/03b49fbed8617e860f71bc4f80abe411451d5f112beb5837cb9e5367@%3Cdev.calcite.apache.org%3E
 



On Apr 9, 2018, at 3:26 PM, F21  wrote:

I am wrapping up some things today and plan to test Avatica Go against the 
latest version of Avatica.

I think we'll be able to make a release by the end of the week.

I am happy to be the release manager for this one.

The latest version of Avatica is 2.3.1 under Boostport/avatica, I think we 
should make this release 2.4.0.

Francis

On 10/04/2018 3:49 AM, Julian Hyde wrote:

We have to make a release of Avatica Go soon (like, within the next month).

As I’ve said previously, a tar-ball of the source (plus checksums/signatures 
and release notes) is sufficient. But we are an Apache project, and projects 
must make releases.

Can someone please volunteer to be release manager? I am too busy.

What should the version number be?

Julian

[GitHub] calcite-avatica-go pull request #18: Fix link in release history

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/18


---

[GitHub] calcite-avatica-go pull request #18: Fix link in release history

[F21]

GitHub user F21 opened a pull request:

https://github.com/apache/calcite-avatica-go/pull/18

Fix link in release history



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Boostport/calcite-avatica-go fix-link

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica-go/pull/18.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #18


commit 2015238505df44c2cd7a96f12ae258a185ab6fa2
Author: Francis Chuang 
Date:   2018-04-17T04:48:41Z

Fix link in release history




---

[GitHub] calcite-avatica-go pull request #2: Update readme and move documentation int...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/2


---

[GitHub] calcite-avatica-go pull request #17: Update dependencies

[F21]

Github user F21 closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/17


---

[GitHub] calcite-avatica-go pull request #17: Update dependencies

[F21]

GitHub user F21 opened a pull request:

https://github.com/apache/calcite-avatica-go/pull/17

Update dependencies



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Boostport/calcite-avatica-go update-deps

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica-go/pull/17.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #17


commit c7a5668afc3aa51f3af538417478d72b537e5b22
Author: Francis Chuang 
Date:   2018-04-17T00:59:19Z

Update dependencies




---

[GitHub] calcite-avatica-go pull request #16: Remove go-cleanhttp

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/16


---

[GitHub] calcite-avatica-go pull request #16: Remove go-cleanhttp

[F21]

Github user F21 closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/16


---

[GitHub] calcite-avatica-go pull request #16: Remove go-cleanhttp

[F21]

GitHub user F21 opened a pull request:

https://github.com/apache/calcite-avatica-go/pull/16

Remove go-cleanhttp



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Boostport/calcite-avatica-go remove-cleanhttp

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica-go/pull/16.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #16


commit f2f4ba03e3f4dee333ec13d050b2336c391ca835
Author: Francis Chuang 
Date:   2018-04-17T00:41:59Z

Remove go-cleanhttp




---

Re: Supporting named row construction in Calcite SQL

[Julian Hyde]

Yes. “Ask Julian”.

The picture is in a Google Slides document. I don’t want to share it publicly, 
and I don’t want to check in a massive .SVG file.

I don’t think it’s worth the effort to make this small part of the process 
scalable.


> On Apr 16, 2018, at 5:22 PM, Shuyi Chen  wrote:
> 
> Thanks a lot, Julian. Do we have instructions on how to update the website
> and the picture documented?
> 
> On Mon, Apr 16, 2018 at 4:42 AM, Michael Mior  > wrote:
> 
>> Thanks Julian!
>> 
>> --
>> Michael Mior
>> mm...@apache.org 
>> 
>> --
>> Michael Mior
>> mm...@uwaterloo.ca 
>> 
>> 2018-04-16 2:26 GMT-04:00 Julian Hyde > >:
>> 
>>> Beam and HerdDB are now on “powered by”: https://calcite.apache.org/ 
>>> 
>>> docs/powered_by.html >> >
>>> 
 On Apr 12, 2018, at 5:33 AM, Michael Mior > wrote:
 
 FYI, I talked to Julian earlier this week and he will be adding Beam to
>>> the
 powered by page since he has a doc for generating the image with the
>>> logos.
 
 --
 Michael Mior
 mm...@apache.org 
 
 2018-04-12 4:06 GMT-04:00 Shuyi Chen >:
 
> @Andrew, great to see BEAM is also using Calcite streaming SQL. Maybe
>>> you
> can help adding an entry in the Calcite powered_by page
>  > for BEAM  by
>> editing
> site/_docs/powered_by.md
>  
> 1aa810bc92051b46555ee4caf24bd6c3>.
> Also,
> can you explain a bit more on how you plan to use streaming SQL to
> transform
> arbitrary JSON objects with and w/o the AS STRUCT syntax?
> For adding DDL in BEAM, please take a look at the server module and
>> the
> TYPE DDL (https://issues.apache.org/jira/browse/CALCITE-2045 
> ) I am
>>> adding.
> Let me know if you have any comments and need any help.
> 
> @Rong, I think it's better to conform with the ROW SQL standard, and
>> add
> new grammar to handle named struct construction.
> This should work with the TYPE DDL, and we should be able to CAST the
> created STRUCT as a custom type defined using DDL.
> 
> @Julian, thanks for the suggestions. I think the AS STRUCT addition
>>> should
> do it.
> 
> Shuyi
> 
> On Mon, Apr 9, 2018 at 4:36 AM, Julian Hyde  >
> wrote:
> 
>> For what it’s worth, ROW is standard SQL. If it does what you need,
>> we
>> should use it.
>> 
>> Reading your case quickly, I perceived that you needed a concise way
>> to
>> assign field names, and AS STRUCT seemed to do that.
>> 
>> But staying within the standard is always preferred. BigQuery isn’t
> always
>> good at that.
>> 
>> Julian
>> 
>>> On Apr 5, 2018, at 10:18, Rong Rong >> > wrote:
>>> 
>>> Thanks for the fantastic proposal @shuyi. I think the STRUCT idea is
>> great
>>> considering ROW is not standard SQL either. As a user of calcite I
> have a
>>> couple questions.
>>> 
>>> Since ROW constructor is so similar with STRUCT, would it be a good
> idea
>> to
>>> consolidate the two syntax? Or have a clear distinction between?
>>> 
>>> Whats the relationship going forward with DDL, for example
> CALCITE-2045.
>>> DDL seems more flexible in terms of defining the structure not just
>> on
>>> field names but also field types. Maybe @andrew can share more on
>> the
> use
>>> cases on calcite on beam steaming integration?
>>> 
>>> Thanks,
>>> Rong
>>> 
>>> 
>>> On Thu, Apr 5, 2018, 10:05 AM Andrew Pilloud
> 
>>> 
>>> wrote:
>>> 
 As a user of Calcite working on adding streaming SQL to Apache Beam
> this
 sounds like a fantastic proposal. Our initial goal is to be able to
> run
>> SQL
 queries that transform arbitrary JSON objects. Without this syntax
>> objects
 must be flattened when they pass through the transform. Is this
>> something
 that might make it into 1.17?
 
 We have also had some discussion about adding DDL to Beam so a user
> can
 describe the schema of a stream of JSON in pure SQL. Our current

[GitHub] calcite-avatica-go pull request #15: Add script to generate release artifact...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/calcite-avatica-go/pull/15


---

Re: Supporting named row construction in Calcite SQL

[Shuyi Chen]

Thanks a lot, Julian. Do we have instructions on how to update the website
and the picture documented?

On Mon, Apr 16, 2018 at 4:42 AM, Michael Mior  wrote:

> Thanks Julian!
>
> --
> Michael Mior
> mm...@apache.org
>
> --
> Michael Mior
> mm...@uwaterloo.ca
>
> 2018-04-16 2:26 GMT-04:00 Julian Hyde :
>
> > Beam and HerdDB are now on “powered by”: https://calcite.apache.org/
> > docs/powered_by.html 
> >
> > > On Apr 12, 2018, at 5:33 AM, Michael Mior  wrote:
> > >
> > > FYI, I talked to Julian earlier this week and he will be adding Beam to
> > the
> > > powered by page since he has a doc for generating the image with the
> > logos.
> > >
> > > --
> > > Michael Mior
> > > mm...@apache.org
> > >
> > > 2018-04-12 4:06 GMT-04:00 Shuyi Chen :
> > >
> > >> @Andrew, great to see BEAM is also using Calcite streaming SQL. Maybe
> > you
> > >> can help adding an entry in the Calcite powered_by page
> > >>  for BEAM  by
> editing
> > >> site/_docs/powered_by.md
> > >>  > >> 1aa810bc92051b46555ee4caf24bd6c3>.
> > >> Also,
> > >> can you explain a bit more on how you plan to use streaming SQL to
> > >> transform
> > >> arbitrary JSON objects with and w/o the AS STRUCT syntax?
> > >> For adding DDL in BEAM, please take a look at the server module and
> the
> > >> TYPE DDL (https://issues.apache.org/jira/browse/CALCITE-2045) I am
> > adding.
> > >> Let me know if you have any comments and need any help.
> > >>
> > >> @Rong, I think it's better to conform with the ROW SQL standard, and
> add
> > >> new grammar to handle named struct construction.
> > >> This should work with the TYPE DDL, and we should be able to CAST the
> > >> created STRUCT as a custom type defined using DDL.
> > >>
> > >> @Julian, thanks for the suggestions. I think the AS STRUCT addition
> > should
> > >> do it.
> > >>
> > >> Shuyi
> > >>
> > >> On Mon, Apr 9, 2018 at 4:36 AM, Julian Hyde 
> > >> wrote:
> > >>
> > >>> For what it’s worth, ROW is standard SQL. If it does what you need,
> we
> > >>> should use it.
> > >>>
> > >>> Reading your case quickly, I perceived that you needed a concise way
> to
> > >>> assign field names, and AS STRUCT seemed to do that.
> > >>>
> > >>> But staying within the standard is always preferred. BigQuery isn’t
> > >> always
> > >>> good at that.
> > >>>
> > >>> Julian
> > >>>
> >  On Apr 5, 2018, at 10:18, Rong Rong  wrote:
> > 
> >  Thanks for the fantastic proposal @shuyi. I think the STRUCT idea is
> > >>> great
> >  considering ROW is not standard SQL either. As a user of calcite I
> > >> have a
> >  couple questions.
> > 
> >  Since ROW constructor is so similar with STRUCT, would it be a good
> > >> idea
> > >>> to
> >  consolidate the two syntax? Or have a clear distinction between?
> > 
> >  Whats the relationship going forward with DDL, for example
> > >> CALCITE-2045.
> >  DDL seems more flexible in terms of defining the structure not just
> on
> >  field names but also field types. Maybe @andrew can share more on
> the
> > >> use
> >  cases on calcite on beam steaming integration?
> > 
> >  Thanks,
> >  Rong
> > 
> > 
> >  On Thu, Apr 5, 2018, 10:05 AM Andrew Pilloud
> > >>  > 
> >  wrote:
> > 
> > > As a user of Calcite working on adding streaming SQL to Apache Beam
> > >> this
> > > sounds like a fantastic proposal. Our initial goal is to be able to
> > >> run
> > >>> SQL
> > > queries that transform arbitrary JSON objects. Without this syntax
> > >>> objects
> > > must be flattened when they pass through the transform. Is this
> > >>> something
> > > that might make it into 1.17?
> > >
> > > We have also had some discussion about adding DDL to Beam so a user
> > >> can
> > > describe the schema of a stream of JSON in pure SQL. Our current
> > >> though
> > >>> is
> > > to use Big Query compatible STRUCT and ARRAY syntax. Big Query is a
> > >>> popular
> > > sink for our users. Syntax compatible with Big Query would be a big
> > >> plus
> > > for us.
> > >
> > > Andrew
> > >
> > >> On Thu, Apr 5, 2018 at 12:43 AM Shuyi Chen 
> > >> wrote:
> > >>
> > >> @Michael, @Albert, yes, I dont think it is SQL standard. But I
> think
> > >>> it's
> > >> very useful in the context of streaming SQL, e.g. Flink SQL, where
> > >> the
> > >> sinks can be a database or endpoints with defined protobuf/thrift
> > >>> schema.
> > >> They usually have complex structure. Supporting complex structure
> in
> > >>> SQL
> > >> output will make it much easier to write to different sinks with
> > > predefined
> > >> schemas in a unified 

[GitHub] calcite-avatica-go pull request #15: Add script to generate release artifact...

[risdenk]

Github user risdenk commented on a diff in the pull request:

https://github.com/apache/calcite-avatica-go/pull/15#discussion_r181917580
  
--- Diff: make-release-artifacts.sh ---
@@ -0,0 +1,26 @@
+# Clean dist directory
+rm -rf dist
+mkdir -p dist
+
+# Get new tags from remote
+git fetch --tags
+
+# Get latest tag name
+latestTag=$(git describe --tags `git rev-list --tags --max-count=1`)
--- End diff --

Fair enough just checking :)


---

[GitHub] calcite-avatica-go pull request #15: Add script to generate release artifact...

[F21]

Github user F21 commented on a diff in the pull request:

https://github.com/apache/calcite-avatica-go/pull/15#discussion_r181917310
  
--- Diff: make-release-artifacts.sh ---
@@ -0,0 +1,26 @@
+# Clean dist directory
+rm -rf dist
+mkdir -p dist
+
+# Get new tags from remote
+git fetch --tags
+
+# Get latest tag name
+latestTag=$(git describe --tags `git rev-list --tags --max-count=1`)
--- End diff --

To keep the script simple, it will only release the latest tag. In most 
cases, we only need to sign and release each tag once. If required in the 
future, we can include functionality to allow tag selection, but that's 
gold-plating at the moment in my opinion.


---

[GitHub] calcite-avatica-go pull request #15: Add script to generate release artifact...

[F21]

Github user F21 commented on a diff in the pull request:

https://github.com/apache/calcite-avatica-go/pull/15#discussion_r181917109
  
--- Diff: make-release-artifacts.sh ---
@@ -0,0 +1,26 @@
+# Clean dist directory
+rm -rf dist
+mkdir -p dist
+
+# Get new tags from remote
+git fetch --tags
+
+# Get latest tag name
+latestTag=$(git describe --tags `git rev-list --tags --max-count=1`)
+
+# Checkout latest tag
+git checkout $latestTag
+
+# Make tar
+tar -zcvf dist/calcite-avatica-go-src-$latestTag.tar.gz --transform 
"s/^\./calcite-avatica-go-src-$latestTag/g" --exclude "dist" .
+
+cd dist
+
+# Calculate MD5
+gpg --print-md MD5 calcite-avatica-go-src-$latestTag.tar.gz > 
calcite-avatica-go-src-$latestTag.tar.gz.md5
+
+# Calculate SHA256
+gpg --print-md SHA256 calcite-avatica-go-src-$latestTag.tar.gz > 
calcite-avatica-go-src-$latestTag.tar.gz.sha512
--- End diff --

Good catch.


---

[GitHub] calcite-avatica-go pull request #15: Add script to generate release artifact...

[risdenk]

Github user risdenk commented on a diff in the pull request:

https://github.com/apache/calcite-avatica-go/pull/15#discussion_r181916510
  
--- Diff: make-release-artifacts.sh ---
@@ -0,0 +1,26 @@
+# Clean dist directory
+rm -rf dist
+mkdir -p dist
+
+# Get new tags from remote
+git fetch --tags
+
+# Get latest tag name
+latestTag=$(git describe --tags `git rev-list --tags --max-count=1`)
--- End diff --

Will this always be the latest tag? Could tag be specified?


---

[GitHub] calcite-avatica-go pull request #15: Add script to generate release artifact...

[risdenk]

Github user risdenk commented on a diff in the pull request:

https://github.com/apache/calcite-avatica-go/pull/15#discussion_r181916445
  
--- Diff: make-release-artifacts.sh ---
@@ -0,0 +1,26 @@
+# Clean dist directory
+rm -rf dist
+mkdir -p dist
+
+# Get new tags from remote
+git fetch --tags
+
+# Get latest tag name
+latestTag=$(git describe --tags `git rev-list --tags --max-count=1`)
+
+# Checkout latest tag
+git checkout $latestTag
+
+# Make tar
+tar -zcvf dist/calcite-avatica-go-src-$latestTag.tar.gz --transform 
"s/^\./calcite-avatica-go-src-$latestTag/g" --exclude "dist" .
+
+cd dist
+
+# Calculate MD5
+gpg --print-md MD5 calcite-avatica-go-src-$latestTag.tar.gz > 
calcite-avatica-go-src-$latestTag.tar.gz.md5
+
+# Calculate SHA256
+gpg --print-md SHA256 calcite-avatica-go-src-$latestTag.tar.gz > 
calcite-avatica-go-src-$latestTag.tar.gz.sha512
--- End diff --

Extension should be sha256


---

[GitHub] calcite-avatica-go pull request #15: Add script to generate release artifact...

[F21]

GitHub user F21 opened a pull request:

https://github.com/apache/calcite-avatica-go/pull/15

Add script to generate release artifacts



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Boostport/calcite-avatica-go 
release-artifacts-script

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/calcite-avatica-go/pull/15.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #15


commit 2e6d4fdf62bd8d96bbf0e9296a52f0354c32d973
Author: Francis Chuang 
Date:   2018-04-16T23:37:57Z

Add script to generate release artifacts




---

[jira] [Created] (CALCITE-2260) RelFieldTrimmer incorrectly trims fields when trimming a distinct UNION

[Jacques Nadeau (JIRA)]

Jacques Nadeau created CALCITE-2260:
---

 Summary: RelFieldTrimmer incorrectly trims fields when trimming a 
distinct UNION
 Key: CALCITE-2260
 URL: https://issues.apache.org/jira/browse/CALCITE-2260
 Project: Calcite
  Issue Type: Bug
Affects Versions: 1.12.0
Reporter: Jacques Nadeau
Assignee: Laurent Goujon


While working with RelFieldTrimmer, identified that if it will push a project 
field trimming through a distinct union, causing wrong result.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Supporting named row construction in Calcite SQL

[Michael Mior]

Thanks Julian!

--
Michael Mior
mm...@apache.org

--
Michael Mior
mm...@uwaterloo.ca

2018-04-16 2:26 GMT-04:00 Julian Hyde :

> Beam and HerdDB are now on “powered by”: https://calcite.apache.org/
> docs/powered_by.html 
>
> > On Apr 12, 2018, at 5:33 AM, Michael Mior  wrote:
> >
> > FYI, I talked to Julian earlier this week and he will be adding Beam to
> the
> > powered by page since he has a doc for generating the image with the
> logos.
> >
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > 2018-04-12 4:06 GMT-04:00 Shuyi Chen :
> >
> >> @Andrew, great to see BEAM is also using Calcite streaming SQL. Maybe
> you
> >> can help adding an entry in the Calcite powered_by page
> >>  for BEAM  by editing
> >> site/_docs/powered_by.md
> >>  >> 1aa810bc92051b46555ee4caf24bd6c3>.
> >> Also,
> >> can you explain a bit more on how you plan to use streaming SQL to
> >> transform
> >> arbitrary JSON objects with and w/o the AS STRUCT syntax?
> >> For adding DDL in BEAM, please take a look at the server module and the
> >> TYPE DDL (https://issues.apache.org/jira/browse/CALCITE-2045) I am
> adding.
> >> Let me know if you have any comments and need any help.
> >>
> >> @Rong, I think it's better to conform with the ROW SQL standard, and add
> >> new grammar to handle named struct construction.
> >> This should work with the TYPE DDL, and we should be able to CAST the
> >> created STRUCT as a custom type defined using DDL.
> >>
> >> @Julian, thanks for the suggestions. I think the AS STRUCT addition
> should
> >> do it.
> >>
> >> Shuyi
> >>
> >> On Mon, Apr 9, 2018 at 4:36 AM, Julian Hyde 
> >> wrote:
> >>
> >>> For what it’s worth, ROW is standard SQL. If it does what you need, we
> >>> should use it.
> >>>
> >>> Reading your case quickly, I perceived that you needed a concise way to
> >>> assign field names, and AS STRUCT seemed to do that.
> >>>
> >>> But staying within the standard is always preferred. BigQuery isn’t
> >> always
> >>> good at that.
> >>>
> >>> Julian
> >>>
>  On Apr 5, 2018, at 10:18, Rong Rong  wrote:
> 
>  Thanks for the fantastic proposal @shuyi. I think the STRUCT idea is
> >>> great
>  considering ROW is not standard SQL either. As a user of calcite I
> >> have a
>  couple questions.
> 
>  Since ROW constructor is so similar with STRUCT, would it be a good
> >> idea
> >>> to
>  consolidate the two syntax? Or have a clear distinction between?
> 
>  Whats the relationship going forward with DDL, for example
> >> CALCITE-2045.
>  DDL seems more flexible in terms of defining the structure not just on
>  field names but also field types. Maybe @andrew can share more on the
> >> use
>  cases on calcite on beam steaming integration?
> 
>  Thanks,
>  Rong
> 
> 
>  On Thu, Apr 5, 2018, 10:05 AM Andrew Pilloud
> >>  
>  wrote:
> 
> > As a user of Calcite working on adding streaming SQL to Apache Beam
> >> this
> > sounds like a fantastic proposal. Our initial goal is to be able to
> >> run
> >>> SQL
> > queries that transform arbitrary JSON objects. Without this syntax
> >>> objects
> > must be flattened when they pass through the transform. Is this
> >>> something
> > that might make it into 1.17?
> >
> > We have also had some discussion about adding DDL to Beam so a user
> >> can
> > describe the schema of a stream of JSON in pure SQL. Our current
> >> though
> >>> is
> > to use Big Query compatible STRUCT and ARRAY syntax. Big Query is a
> >>> popular
> > sink for our users. Syntax compatible with Big Query would be a big
> >> plus
> > for us.
> >
> > Andrew
> >
> >> On Thu, Apr 5, 2018 at 12:43 AM Shuyi Chen 
> >> wrote:
> >>
> >> @Michael, @Albert, yes, I dont think it is SQL standard. But I think
> >>> it's
> >> very useful in the context of streaming SQL, e.g. Flink SQL, where
> >> the
> >> sinks can be a database or endpoints with defined protobuf/thrift
> >>> schema.
> >> They usually have complex structure. Supporting complex structure in
> >>> SQL
> >> output will make it much easier to write to different sinks with
> > predefined
> >> schemas in a unified way,
> >>
> >> @julian, that's great suggestion, I think instead of extending the
> >> ROW
> >> constructor, which is not SQL standard, adding a new extension might
> >> be
> > the
> >> right way to go. Looking at the STRUCT big query syntax, we can
> >>> implement
> >> something like the following:
> >>
> >> SELECT STRUCT(a as first_name, b as last_name, STRUCT(c as zip code,
> >> d
> >>> as
> >> street, e as state) as 

Re: Towards Avatica-Go release ?.?

[Francis Chuang]

Thanks, Julian.

I will add a release script to the repo and add the release notes to the 
site/ directory. I also had to make some breaking changes to the public 
interfaces with the updates, so we'll release it as 3.0.0.


Francis

On 16/04/2018 4:44 PM, Julian Hyde wrote:

Yes, the script isn’t very complicated. We probably need half a dozen lines of 
shell script to create the tar.gz file, sign it, and generate .sha256 
checksums. I don’t mind where you put those lines of shell script, as long as 
the next RM can find them.

The site looks good. It doesn’t have to be perfect before the release as we can 
easily update it after the release. I’d change the date in history.md from 
2017-08-xx to 2018-04-23. If all goes well the release could be announced ~5 
working days after the vote starts.

I’m not sure whether "go” will work. Jekyll markdown is a bit more limited 
than GitHub markdown. We seem to have to use {% highlight sql %} for code sections.

There are probably other issues in the site but we’ll only know when we start 
running jekyll to build and deploy the avatica site.

Julian



On Apr 15, 2018, at 11:27 PM, F21  wrote:

Hey Julian,

The code is in a releasable state. A few questions:
- Building a binary of a library in Go is not useful/meaningful. For the 
release, we just need to tar gz the git repo and sign it. Do you still need a 
script for this? Otherwise we can write the instructions somewhere in the site/ 
directory.

- Still need to write the release notes. Can you have a look at 
https://github.com/apache/calcite-avatica-go/pull/2 to see if I have structured 
the site/ directory correctly? The PR is a bit stale, but it shouldn't be too 
much work to get it up to date.

Francis

On 10/04/2018 8:51 AM, Julian Hyde wrote:

Thanks, Francis.

The most important step is to come up with a release vote email with the same items 
as [1]: release notes, git commit, artifacts to be voted on in 
dist.apache.org/repos/dist/dev , md5 and 
sha256 hashes. (The staged maven repository does not apply.)

Per apache policy, the release needs to be signed by a PMC member. I’ll be 
happy to do that. Or we could skip signing for the first couple of RCs.

Maybe write a shell script that creates the files, and a “howto” that the next 
RM can follow? I’ll be able to run the script when it’s time to create signed 
artifacts.

Julian

[1] 
https://lists.apache.org/thread.html/03b49fbed8617e860f71bc4f80abe411451d5f112beb5837cb9e5367@%3Cdev.calcite.apache.org%3E
 



On Apr 9, 2018, at 3:26 PM, F21  wrote:

I am wrapping up some things today and plan to test Avatica Go against the 
latest version of Avatica.

I think we'll be able to make a release by the end of the week.

I am happy to be the release manager for this one.

The latest version of Avatica is 2.3.1 under Boostport/avatica, I think we 
should make this release 2.4.0.

Francis

On 10/04/2018 3:49 AM, Julian Hyde wrote:

We have to make a release of Avatica Go soon (like, within the next month).

As I’ve said previously, a tar-ball of the source (plus checksums/signatures 
and release notes) is sufficient. But we are an Apache project, and projects 
must make releases.

Can someone please volunteer to be release manager? I am too busy.

What should the version number be?

Julian

Re: Towards Avatica-Go release ?.?

[Julian Hyde]

Yes, the script isn’t very complicated. We probably need half a dozen lines of 
shell script to create the tar.gz file, sign it, and generate .sha256 
checksums. I don’t mind where you put those lines of shell script, as long as 
the next RM can find them.

The site looks good. It doesn’t have to be perfect before the release as we can 
easily update it after the release. I’d change the date in history.md from 
2017-08-xx to 2018-04-23. If all goes well the release could be announced ~5 
working days after the vote starts.

I’m not sure whether "go” will work. Jekyll markdown is a bit more limited 
than GitHub markdown. We seem to have to use {% highlight sql %} for code 
sections.

There are probably other issues in the site but we’ll only know when we start 
running jekyll to build and deploy the avatica site.

Julian


> On Apr 15, 2018, at 11:27 PM, F21  wrote:
> 
> Hey Julian,
> 
> The code is in a releasable state. A few questions:
> - Building a binary of a library in Go is not useful/meaningful. For the 
> release, we just need to tar gz the git repo and sign it. Do you still need a 
> script for this? Otherwise we can write the instructions somewhere in the 
> site/ directory.
> 
> - Still need to write the release notes. Can you have a look at 
> https://github.com/apache/calcite-avatica-go/pull/2 to see if I have 
> structured the site/ directory correctly? The PR is a bit stale, but it 
> shouldn't be too much work to get it up to date.
> 
> Francis
> 
> On 10/04/2018 8:51 AM, Julian Hyde wrote:
>> Thanks, Francis.
>> 
>> The most important step is to come up with a release vote email with the 
>> same items as [1]: release notes, git commit, artifacts to be voted on in 
>> dist.apache.org/repos/dist/dev , md5 
>> and sha256 hashes. (The staged maven repository does not apply.)
>> 
>> Per apache policy, the release needs to be signed by a PMC member. I’ll be 
>> happy to do that. Or we could skip signing for the first couple of RCs.
>> 
>> Maybe write a shell script that creates the files, and a “howto” that the 
>> next RM can follow? I’ll be able to run the script when it’s time to create 
>> signed artifacts.
>> 
>> Julian
>> 
>> [1] 
>> https://lists.apache.org/thread.html/03b49fbed8617e860f71bc4f80abe411451d5f112beb5837cb9e5367@%3Cdev.calcite.apache.org%3E
>>  
>> 
>> 
>>> On Apr 9, 2018, at 3:26 PM, F21  wrote:
>>> 
>>> I am wrapping up some things today and plan to test Avatica Go against the 
>>> latest version of Avatica.
>>> 
>>> I think we'll be able to make a release by the end of the week.
>>> 
>>> I am happy to be the release manager for this one.
>>> 
>>> The latest version of Avatica is 2.3.1 under Boostport/avatica, I think we 
>>> should make this release 2.4.0.
>>> 
>>> Francis
>>> 
>>> On 10/04/2018 3:49 AM, Julian Hyde wrote:
 We have to make a release of Avatica Go soon (like, within the next month).
 
 As I’ve said previously, a tar-ball of the source (plus 
 checksums/signatures and release notes) is sufficient. But we are an 
 Apache project, and projects must make releases.
 
 Can someone please volunteer to be release manager? I am too busy.
 
 What should the version number be?
 
 Julian
 
>> 
> 

Re: Towards Avatica-Go release ?.?

[F21]

Hey Julian,

The code is in a releasable state. A few questions:
- Building a binary of a library in Go is not useful/meaningful. For the 
release, we just need to tar gz the git repo and sign it. Do you still 
need a script for this? Otherwise we can write the instructions 
somewhere in the site/ directory.


- Still need to write the release notes. Can you have a look at 
https://github.com/apache/calcite-avatica-go/pull/2 to see if I have 
structured the site/ directory correctly? The PR is a bit stale, but it 
shouldn't be too much work to get it up to date.


Francis

On 10/04/2018 8:51 AM, Julian Hyde wrote:

Thanks, Francis.

The most important step is to come up with a release vote email with the same items 
as [1]: release notes, git commit, artifacts to be voted on in 
dist.apache.org/repos/dist/dev , md5 and 
sha256 hashes. (The staged maven repository does not apply.)

Per apache policy, the release needs to be signed by a PMC member. I’ll be 
happy to do that. Or we could skip signing for the first couple of RCs.

Maybe write a shell script that creates the files, and a “howto” that the next 
RM can follow? I’ll be able to run the script when it’s time to create signed 
artifacts.

Julian

[1] 
https://lists.apache.org/thread.html/03b49fbed8617e860f71bc4f80abe411451d5f112beb5837cb9e5367@%3Cdev.calcite.apache.org%3E
 



On Apr 9, 2018, at 3:26 PM, F21  wrote:

I am wrapping up some things today and plan to test Avatica Go against the 
latest version of Avatica.

I think we'll be able to make a release by the end of the week.

I am happy to be the release manager for this one.

The latest version of Avatica is 2.3.1 under Boostport/avatica, I think we 
should make this release 2.4.0.

Francis

On 10/04/2018 3:49 AM, Julian Hyde wrote:

We have to make a release of Avatica Go soon (like, within the next month).

As I’ve said previously, a tar-ball of the source (plus checksums/signatures 
and release notes) is sufficient. But we are an Apache project, and projects 
must make releases.

Can someone please volunteer to be release manager? I am too busy.

What should the version number be?

Julian

Re: Supporting named row construction in Calcite SQL

[Julian Hyde]

Beam and HerdDB are now on “powered by”: 
https://calcite.apache.org/docs/powered_by.html 


> On Apr 12, 2018, at 5:33 AM, Michael Mior  wrote:
> 
> FYI, I talked to Julian earlier this week and he will be adding Beam to the
> powered by page since he has a doc for generating the image with the logos.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> 2018-04-12 4:06 GMT-04:00 Shuyi Chen :
> 
>> @Andrew, great to see BEAM is also using Calcite streaming SQL. Maybe you
>> can help adding an entry in the Calcite powered_by page
>>  for BEAM  by editing
>> site/_docs/powered_by.md
>> > 1aa810bc92051b46555ee4caf24bd6c3>.
>> Also,
>> can you explain a bit more on how you plan to use streaming SQL to
>> transform
>> arbitrary JSON objects with and w/o the AS STRUCT syntax?
>> For adding DDL in BEAM, please take a look at the server module and the
>> TYPE DDL (https://issues.apache.org/jira/browse/CALCITE-2045) I am adding.
>> Let me know if you have any comments and need any help.
>> 
>> @Rong, I think it's better to conform with the ROW SQL standard, and add
>> new grammar to handle named struct construction.
>> This should work with the TYPE DDL, and we should be able to CAST the
>> created STRUCT as a custom type defined using DDL.
>> 
>> @Julian, thanks for the suggestions. I think the AS STRUCT addition should
>> do it.
>> 
>> Shuyi
>> 
>> On Mon, Apr 9, 2018 at 4:36 AM, Julian Hyde 
>> wrote:
>> 
>>> For what it’s worth, ROW is standard SQL. If it does what you need, we
>>> should use it.
>>> 
>>> Reading your case quickly, I perceived that you needed a concise way to
>>> assign field names, and AS STRUCT seemed to do that.
>>> 
>>> But staying within the standard is always preferred. BigQuery isn’t
>> always
>>> good at that.
>>> 
>>> Julian
>>> 
 On Apr 5, 2018, at 10:18, Rong Rong  wrote:
 
 Thanks for the fantastic proposal @shuyi. I think the STRUCT idea is
>>> great
 considering ROW is not standard SQL either. As a user of calcite I
>> have a
 couple questions.
 
 Since ROW constructor is so similar with STRUCT, would it be a good
>> idea
>>> to
 consolidate the two syntax? Or have a clear distinction between?
 
 Whats the relationship going forward with DDL, for example
>> CALCITE-2045.
 DDL seems more flexible in terms of defining the structure not just on
 field names but also field types. Maybe @andrew can share more on the
>> use
 cases on calcite on beam steaming integration?
 
 Thanks,
 Rong
 
 
 On Thu, Apr 5, 2018, 10:05 AM Andrew Pilloud
>>  As a user of Calcite working on adding streaming SQL to Apache Beam
>> this
> sounds like a fantastic proposal. Our initial goal is to be able to
>> run
>>> SQL
> queries that transform arbitrary JSON objects. Without this syntax
>>> objects
> must be flattened when they pass through the transform. Is this
>>> something
> that might make it into 1.17?
> 
> We have also had some discussion about adding DDL to Beam so a user
>> can
> describe the schema of a stream of JSON in pure SQL. Our current
>> though
>>> is
> to use Big Query compatible STRUCT and ARRAY syntax. Big Query is a
>>> popular
> sink for our users. Syntax compatible with Big Query would be a big
>> plus
> for us.
> 
> Andrew
> 
>> On Thu, Apr 5, 2018 at 12:43 AM Shuyi Chen 
>> wrote:
>> 
>> @Michael, @Albert, yes, I dont think it is SQL standard. But I think
>>> it's
>> very useful in the context of streaming SQL, e.g. Flink SQL, where
>> the
>> sinks can be a database or endpoints with defined protobuf/thrift
>>> schema.
>> They usually have complex structure. Supporting complex structure in
>>> SQL
>> output will make it much easier to write to different sinks with
> predefined
>> schemas in a unified way,
>> 
>> @julian, that's great suggestion, I think instead of extending the
>> ROW
>> constructor, which is not SQL standard, adding a new extension might
>> be
> the
>> right way to go. Looking at the STRUCT big query syntax, we can
>>> implement
>> something like the following:
>> 
>> SELECT STRUCT(a as first_name, b as last_name, STRUCT(c as zip code,
>> d
>>> as
>> street, e as state) as address) as record FROM example_table
>> 
>> On Wed, Apr 4, 2018 at 5:51 PM, Julian Hyde 
>> wrote:
>> 
>>> If I recall correctly, Google BigQuery has SELECT AS STRUCT. It’s
>> not
>>> standard, but if it does what you need we could consider adopting
>> that
>>> syntax.
>>> 
>>> Julian
>>> 
 On Apr 4, 2018, at 10:23 AM, Albert