[jira] [Comment Edited] (CALCITE-1938) First Apache release for Avatica Go
[
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124449#comment-16124449
]
Francis Chuang edited comment on CALCITE-1938 at 8/12/17 4:52 AM:
--
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary files or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
In terms of developer instructions:
If you want to contribute to the project:
- Fork it.
- Clone the official repo (github.com/apache/calcite-avatica-go) to
GOPATH/src/github.com/apache/calcite-avatica-go.
- Add your fork as a remote for in the cloned repo.
- Make changes, run tests using `go test`, commit and push to your fork.
- Merge on Github (if using apache gitbox), or have a committer fetch your
changes into a branch on the apache git repo and merge.
If you want to use the library in a project:
- Install the dep tool (https://github.com/golang/dep) by running go get -u
github.com/golang/dep/cmd/dep
- Run `dep ensure -add github.com/apache/calcite-avatica-go` in your
project's root.
- Use the library in your project by `import`ing it and using it:
{code}
import _ "github.com/apache/calcite-avatica-go"
func main(){
db := ...
}
{code}
was (Author: francischuang):
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/
[jira] [Commented] (CALCITE-1937) Web site for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124458#comment-16124458 ] Francis Chuang commented on CALCITE-1937: - I've updated the web pages to include relevant information regarding Phoenix support. I also added a README under site/ stating that the files are symlinked by calcite-avatica and pushes should be done from that repository. > Web site for Avatica Go > --- > > Key: CALCITE-1937 > URL: https://issues.apache.org/jira/browse/CALCITE-1937 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Create a web site for calcite-avatica-go. > How about this: > * At run time, the pages should appear under http://calcite.apache.org/avatica > * The pages should be source-controlled under calcite-avatica-go/site, in > markdown format (same as calcite and avatica), and generated into svn using > similar trickery to calcite and avatica. > * Reduce the amount of content in > https://github.com/apache/calcite-avatica-go/blob/master/README.md. The > "documentation" stuff should move to under http://calcite.apache.org/avatica. > So the page will be mainly a re-direct to the Apache home page. Similar to > https://github.com/apache/calcite-avatica/blob/master/README.md, in fact. > * Add a go_history.md file. > Should avatica-go appear on http://calcite.apache.org/avatica/downloads, or > should it have its own download page? I think it probably the former. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1938) First Apache release for Avatica Go
[
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124449#comment-16124449
]
Francis Chuang edited comment on CALCITE-1938 at 8/12/17 4:30 AM:
--
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
In terms of developer instructions:
If you want to contribute to the project:
- Fork it.
- Clone the official repo (github.com/apache/calcite-avatica-go) to
GOPATH/src/github.com/apache/calcite-avatica-go.
- Add your fork as a remote for in the cloned repo.
- Make changes, run tests using `go test`, commit and push to your fork.
- Merge on Github (if using apache gitbox), or have a committer fetch your
changes into a branch on the apache git repo and merge.
If you want to use the library in a project:
- Install the dep tool (https://github.com/golang/dep) by running go get -u
github.com/golang/dep/cmd/dep
- Run `dep ensure -add github.com/apache/calcite-avatica-go` in your
project's root.
- Use the library in your project by `import`ing it and using it:
{code}
import _ "github.com/apache/calcite-avatica-go"
func main(){
db := ...
}
{code}
was (Author: francischuang):
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder
[jira] [Comment Edited] (CALCITE-1938) First Apache release for Avatica Go
[
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124449#comment-16124449
]
Francis Chuang edited comment on CALCITE-1938 at 8/12/17 4:29 AM:
--
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
In terms of developer instructions:
If you want to contribute to the project:
- Fork it.
- Clone the official repo (github.com/apache/calcite-avatica-go) to
GOPATH/src/github.com/apache/calcite-avatica-go.
- Add your fork as a remote for in the cloned repo.
- Make changes, run tests using `go test`, commit and push to your fork.
- Merge on Github (if using apache gitbox), or have a committer fetch your
changes into a branch on the apache git repo and merge.
If you want to use the library in a project:
- Install the dep tool (https://github.com/golang/dep) by running go get -u
github.com/golang/dep/cmd/dep
- Run `dep ensure -add github.com/apache/calcite-avatica-go`.
- Use the library in your project by `import`ing it and using it:
{code:go}
import _ "github.com/apache/calcite-avatica-go"
func main(){
db := ...
}
{code}
was (Author: francischuang):
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain
[jira] [Comment Edited] (CALCITE-1938) First Apache release for Avatica Go
[
https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124449#comment-16124449
]
Francis Chuang edited comment on CALCITE-1938 at 8/12/17 4:29 AM:
--
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the source of
our dependencies.
- Go install is not meaningful for a library. If the project produced an
executable, then `go install` can be used to build and place the binary into
GOPATH/bin. However, since calcite-avatica-go is a library, and there is no
main package in the code, it is not meaningful to build a binary.
In terms of developer instructions:
If you want to contribute to the project:
- Fork it.
- Clone the official repo (github.com/apache/calcite-avatica-go) to
GOPATH/src/github.com/apache/calcite-avatica-go.
- Add your fork as a remote for in the cloned repo.
- Make changes, run tests using `go test`, commit and push to your fork.
- Merge on Github (if using apache gitbox), or have a committer fetch your
changes into a branch on the apache git repo and merge.
If you want to use the library in a project:
- Install the dep tool (https://github.com/golang/dep) by running go get -u
github.com/golang/dep/cmd/dep
- Run `dep ensure -add github.com/apache/calcite-avatica-go`.
- Use the library in your project by `import`ing it and using it:
{code}
import _ "github.com/apache/calcite-avatica-go"
func main(){
db := ...
}
{code}
was (Author: francischuang):
For Go libraries, building a binary out of a library isn't very useful.
In Go, there is the concept of the GOPATH. It is an environment variable
pointing to a folder where you store and work on your Go projects. GOPATH
should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`,
for example `src/github.com/apache/calcite-avatica-go`. Executables are placed
in bin, and they are built by running `go install` in your project. Under
`pkg/`, you'd find the package binaries. They are intermediate objects that are
cached by the go tool. For example, if I run `go install` in
`src/github.com/some-org/some-project` to build an executable, and that project
imports a certain version of calcite-avatica-go, the calcite-avatica-go
dependency will be built as `src/github.com/apache/calcite-avatica-go.a`.
In Go, libraries are not shipped and built as binaries are they are not very
useful. The built binaries under the pkg/ folder are only temporary objects
cached by Go to improve build performance and they should be re-built during
the compilation of an executable.
The standard workflow is to use the dep tool or some third party dependency
management tool. It will check out the source into the project's vendor
directory, and if `go install` or `go build` is executed, it will build the
final binary.
>From my understand of maven and comparing with Go:
- Go does not need the clean step, as running tests or building does not create
temporary or binaries in the source tree.
- To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does
is tell the go tool to traverse the project for test files and execute them,
but exclude anything in the vendor/ folder because they contain the
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124449#comment-16124449 ] Francis Chuang commented on CALCITE-1938: - For Go libraries, building a binary out of a library isn't very useful. In Go, there is the concept of the GOPATH. It is an environment variable pointing to a folder where you store and work on your Go projects. GOPATH should contain the src/, pkg/ and bin/ folders. Projects are placed in `src/`, for example `src/github.com/apache/calcite-avatica-go`. Executables are placed in bin, and they are built by running `go install` in your project. Under `pkg/`, you'd find the package binaries. They are intermediate objects that are cached by the go tool. For example, if I run `go install` in `src/github.com/some-org/some-project` to build an executable, and that project imports a certain version of calcite-avatica-go, the calcite-avatica-go dependency will be built as `src/github.com/apache/calcite-avatica-go.a`. In Go, libraries are not shipped and built as binaries are they are not very useful. The built binaries under the pkg/ folder are only temporary objects cached by Go to improve build performance and they should be re-built during the compilation of an executable. The standard workflow is to use the dep tool or some third party dependency management tool. It will check out the source into the project's vendor directory, and if `go install` or `go build` is executed, it will build the final binary. >From my understand of maven and comparing with Go: - Go does not need the clean step, as running tests or building does not create temporary or binaries in the source tree. - To test, we run `go test $(go list ./... | grep -v /vendor/)`. All this does is tell the go tool to traverse the project for test files and execute them, but exclude anything in the vendor/ folder because they contain the source of our dependencies. - Go install is not meaningful for a library. If the project produced an executable, then `go install` can be used to build and place the binary into GOPATH/bin. However, since calcite-avatica-go is a library, and there is no main package in the code, it is not meaningful to build a binary. > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16124435#comment-16124435 ] Julian Hyde commented on CALCITE-1938: -- As part of the release, we need developer instructions. Under Apache, it's important that when you download a source distribution, you can build that actual source code. Not the source code that is in github etc. Maybe I misunderstand the current developer instructions in README.md, but it seems to be building code that is in a particular github repo (or referencing binaries that have been previously built from that repo). For the purposes of an Apache release, we need the equivalent of 'mvn clean test install', and that needs to be fairly prominent in the README that comes with the release. Is that possible? > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CALCITE-1939) DatabaseMetaData.getColumns() returns -1 for columns COLUMN_SIZE , BUFFER_LENGTH and DECIMAL_DIGITS
Sergio Sainz created CALCITE-1939: - Summary: DatabaseMetaData.getColumns() returns -1 for columns COLUMN_SIZE , BUFFER_LENGTH and DECIMAL_DIGITS Key: CALCITE-1939 URL: https://issues.apache.org/jira/browse/CALCITE-1939 Project: Calcite Issue Type: Bug Components: avatica Affects Versions: 1.10.0 Environment: The database in this case is Druid 0.10 Reporter: Sergio Sainz When querying DatabaseMetaData.getColumns(null, "druidDB", "sampleDruidTable", null), the following results are received: || db name || table name || column name || || type || COLUMN_SIZE || BUFFER_LENGTH || DECIMAL_DIGITS || |druidDB|sampleDruidDB|__time|93 | TIMESTAMP | -1 | -1 | -1 | |druidDB|sampleDruidDB|dimA|12| VARCHAR | -1 | -1 | -1 | |druidDB|sampleDruidDB|m1|-5| BIGINT | -1 | -1 | -1 | Unsure whether this is more of a druid side issue. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1938) First Apache release for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123753#comment-16123753 ] Josh Elser commented on CALCITE-1938: - bq. Josh Elser might be better able to set up CI. He did it for Calcite and Avatica. Would you mind taking this on, Josh? Yup! Not a problem. Will try to do it this weekend. > First Apache release for Avatica Go > --- > > Key: CALCITE-1938 > URL: https://issues.apache.org/jira/browse/CALCITE-1938 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Make a release for Avatica Go. > Release number is TBD. > This will be the first Apache release for Avacica Go, so expect more > diligence / issues than usual. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde resolved CALCITE-1930.
--
Resolution: Fixed
Fix Version/s: 1.14.0
Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/7321c870.
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
> Fix For: 1.14.0
>
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-1936) Allow ROUND() and TRUNCATE() to take only one operand
[ https://issues.apache.org/jira/browse/CALCITE-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-1936. -- Resolution: Fixed Fix Version/s: 1.14.0 Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/bfaea7cc. I also made ROUND and TRUNCATE work when their 2nd argument is NULL. > Allow ROUND() and TRUNCATE() to take only one operand > - > > Key: CALCITE-1936 > URL: https://issues.apache.org/jira/browse/CALCITE-1936 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > Fix For: 1.14.0 > > > Some databases (e.g. Oracle and MS Sqlserver) allow ROUND and TRUNCATE to > take only one operand for ease of use. For example, we could allow > ROUND(12.3) to mean ROUND(12.3, 0), TRUNCATE(12.3, 0) to mean TRUNCATE(12.3). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1911) Support WITHIN clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123502#comment-16123502
]
Julian Hyde commented on CALCITE-1911:
--
You've addressed almost everything. I was pleased to see negative tests for
ORDER BY.
Can you make the unit tests for intervals much smaller? The only difference
between testMatchRecognizeWithin6 and testMatchRecognizeWithin7 is the kind of
interval. That's the purpose of those tests, after all. You know that, I know
that, but whoever maintains this code in the future won't be able to see the
wood for the trees. Don't write a 50 line test when a 1 line test will do. As I
said earlier, you can test using a 1-line VALUES statement.
> Support WITHIN clause in MATCH_RECOGNIZE
>
>
> Key: CALCITE-1911
> URL: https://issues.apache.org/jira/browse/CALCITE-1911
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Julian Hyde
> Labels: match
>
> Window is an important feature for pattern detection, it defines the time
> duration for the events to match a pattern. Here is an example from
> [doc|https://docs.oracle.com/middleware/1213/eventprocessing/cql-reference/GUID-34D4968E-C55A-4BC7-B1CE-C84B202217BD.htm#CQLLR2119]:
> {code}
> SELECT T.Ac2, T.Bc2, T.Cc2
> FROM S
> MATCH_RECOGNIZE(
> MEASURES A.c2 as Ac2, B.c2 as Bc2, C.c2 as Cc2
> PATTERN (A (B+ | C)) within 3000 milliseconds
> DEFINE
> A as A.c1=10 or A.c1=25,
> B as B.c1=20 or B.c1=15 or B.c1=25,
> C as C.c1=15
> ) as T
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1937) Web site for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123484#comment-16123484 ] Julian Hyde commented on CALCITE-1937: -- I think we should describe avatica-go as a general purpose client for avatica but also have a section about how it works for PQS right out of the box. This way we don't scare off people who are not using Phoenix. But we can make it clear in the Phoenix section that it works great for Phoenix, is tested on Phoenix versions x.x and y.y, and we have extensions such as the error message codes. Then I think Phoenix can also have a section on their site about the driver. [~jamestaylor], What do you think? > Web site for Avatica Go > --- > > Key: CALCITE-1937 > URL: https://issues.apache.org/jira/browse/CALCITE-1937 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Create a web site for calcite-avatica-go. > How about this: > * At run time, the pages should appear under http://calcite.apache.org/avatica > * The pages should be source-controlled under calcite-avatica-go/site, in > markdown format (same as calcite and avatica), and generated into svn using > similar trickery to calcite and avatica. > * Reduce the amount of content in > https://github.com/apache/calcite-avatica-go/blob/master/README.md. The > "documentation" stuff should move to under http://calcite.apache.org/avatica. > So the page will be mainly a re-direct to the Apache home page. Similar to > https://github.com/apache/calcite-avatica/blob/master/README.md, in fact. > * Add a go_history.md file. > Should avatica-go appear on http://calcite.apache.org/avatica/downloads, or > should it have its own download page? I think it probably the former. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123478#comment-16123478
]
Julian Hyde commented on CALCITE-1935:
--
Remember, it doesn't have to be efficient. Could you use Java's built-in
regular expression support? Compile a regular expression, and as each row comes
in, add a string token to a StringBuilder, then see whether the regular
expression has matched.
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (CALCITE-1240) Avatica client written in Golang
[ https://issues.apache.org/jira/browse/CALCITE-1240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Hyde resolved CALCITE-1240. -- Resolution: Fixed Fix Version/s: avatica-go-2.2.0 > Avatica client written in Golang > > > Key: CALCITE-1240 > URL: https://issues.apache.org/jira/browse/CALCITE-1240 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Julian Hyde > Fix For: avatica-go-2.2.0 > > > Add a client for Avatica written in the Go language (aka "Golang"). > There is one at https://github.com/Boostport/avatica and the author has > offered to contribute it. > The driver is currently somewhat specialized for Phoenix but our goal should > be to allow it to work against any Avatica provider (without diminishing its > value to Phoenix users). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1930) AggregateExpandDistinctAggregatesRule does not expand aggregates properly
[
https://issues.apache.org/jira/browse/CALCITE-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123467#comment-16123467
]
Julian Hyde commented on CALCITE-1930:
--
Reviewing and testing now.
> AggregateExpandDistinctAggregatesRule does not expand aggregates properly
> -
>
> Key: CALCITE-1930
> URL: https://issues.apache.org/jira/browse/CALCITE-1930
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: MinJi Kim
>Assignee: Julian Hyde
>
> A query with two aggregate calls, sum(comm) and min(comm), it produces an
> incorrect plan. The main problem is that it fails to index the input of
> sum(comm) and min(comm) properly. This seems to only happen in the special
> case where there is only one distinct aggregate call.
> {code}
> SELECT deptno, sum(comm), min(comm), SUM(DISTINCT sal) FROM emp GROUP BY
> deptno
> {code}
> AggregateExpandDistinctAggregatesRule produces the following plan in this
> case.
> {code}
> LogicalAggregate(group=[{0}], EXPR$1=[SUM($3)], EXPR$2=[MIN($3)],
> EXPR$3=[SUM($1)])
> LogicalAggregate(group=[{0, 2}], EXPR$1=[SUM($1)], EXPR$2=[MIN($1)])
> LogicalProject(DEPTNO=[$7], COMM=[$6], SAL=[$5])
> LogicalTableScan(table=[[CATALOG, SALES, EMP]])
> {code}
> In the above plan, the top LogicalAggregate EXPR$1=[SUM($3]] is incorrect, it
> should be SUM($2).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1936) Allow ROUND() and TRUNCATE() to take only one operand
[ https://issues.apache.org/jira/browse/CALCITE-1936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123465#comment-16123465 ] Julian Hyde commented on CALCITE-1936: -- Reviewing and testing now. > Allow ROUND() and TRUNCATE() to take only one operand > - > > Key: CALCITE-1936 > URL: https://issues.apache.org/jira/browse/CALCITE-1936 > Project: Calcite > Issue Type: Bug > Components: core >Reporter: MinJi Kim >Assignee: Julian Hyde > > Some databases (e.g. Oracle and MS Sqlserver) allow ROUND and TRUNCATE to > take only one operand for ease of use. For example, we could allow > ROUND(12.3) to mean ROUND(12.3, 0), TRUNCATE(12.3, 0) to mean TRUNCATE(12.3). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (CALCITE-1935) Reference implementation for MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123288#comment-16123288
]
Dian Fu commented on CALCITE-1935:
--
[~julianhyde], sorry for late response. IMO, it's not easy to add the reference
implementation in calcite as we need a NFA for pattern detection. [~ransom],
thoughts?
> Reference implementation for MATCH_RECOGNIZE
>
>
> Key: CALCITE-1935
> URL: https://issues.apache.org/jira/browse/CALCITE-1935
> Project: Calcite
> Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> We now have comprehensive support for parsing and validating MATCH_RECOGNIZE
> queries (see CALCITE-1570 and sub-tasks) but we cannot execute them. I know
> the purpose of this work is to do CEP within Flink, but a reference
> implementation that works on non-streaming data would be valuable.
> I propose that we add a class EnumerableMatch that can generate Java code to
> evaluate MATCH_RECOGNIZE queries on Enumerable data. It does not need to be
> efficient. I don't mind if it (say) buffers all the data in memory and makes
> O(n ^ 3) passes over it. People can make it more efficient over time.
> When we have a reference implementation, people can start playing with this
> feature. And we can start building a corpus of data sets, queries, and their
> expected result. The Flink implementation will be able to test against those
> same queries, and should give the same results, even though Flink will be
> reading streaming data.
> Let's create {{match.iq}} with the following query based on
> https://oracle-base.com/articles/12c/pattern-matching-in-oracle-database-12cr1:
> {code}
> !set outputformat mysql
> !use match
> SELECT *
> FROM sales_history MATCH_RECOGNIZE (
> PARTITION BY product
> ORDER BY tstamp
> MEASURES STRT.tstamp AS start_tstamp,
>LAST(UP.tstamp) AS peak_tstamp,
>LAST(DOWN.tstamp) AS end_tstamp,
>MATCH_NUMBER() AS mno
> ONE ROW PER MATCH
> AFTER MATCH SKIP TO LAST DOWN
> PATTERN (STRT UP+ FLAT* DOWN+)
> DEFINE
>UP AS UP.units_sold > PREV(UP.units_sold),
>FLAT AS FLAT.units_sold = PREV(FLAT.units_sold),
>DOWN AS DOWN.units_sold < PREV(DOWN.units_sold)
>) MR
> ORDER BY MR.product, MR.start_tstamp;
> PRODUCTSTART_TSTAM PEAK_TSTAMP END_TSTAMP MNO
> -- --- --- --- --
> TWINKIES 01-OCT-2014 03-OCT-2014 06-OCT-2014 1
> TWINKIES 06-OCT-2014 08-OCT-2014 09-OCT-2014 2
> TWINKIES 09-OCT-2014 13-OCT-2014 16-OCT-2014 3
> TWINKIES 16-OCT-2014 18-OCT-2014 20-OCT-2014 4
> 4 rows selected.
> !ok
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1911) Support WITHIN clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123278#comment-16123278
]
Dian Fu commented on CALCITE-1911:
--
Have updated the PR according to review comments.
Have also added the following method in {{LogicalMatch}}. Although this is not
related to this JIRA, but the change is very small and so just fix it here.
{quote}
@Override public RelNode accept(RelShuttle shuttle) {
return shuttle.visit(this);
}
{quote}
> Support WITHIN clause in MATCH_RECOGNIZE
>
>
> Key: CALCITE-1911
> URL: https://issues.apache.org/jira/browse/CALCITE-1911
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Julian Hyde
> Labels: match
>
> Window is an important feature for pattern detection, it defines the time
> duration for the events to match a pattern. Here is an example from
> [doc|https://docs.oracle.com/middleware/1213/eventprocessing/cql-reference/GUID-34D4968E-C55A-4BC7-B1CE-C84B202217BD.htm#CQLLR2119]:
> {code}
> SELECT T.Ac2, T.Bc2, T.Cc2
> FROM S
> MATCH_RECOGNIZE(
> MEASURES A.c2 as Ac2, B.c2 as Bc2, C.c2 as Cc2
> PATTERN (A (B+ | C)) within 3000 milliseconds
> DEFINE
> A as A.c1=10 or A.c1=25,
> B as B.c1=20 or B.c1=15 or B.c1=25,
> C as C.c1=15
> ) as T
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (CALCITE-1911) Support WITHIN clause in MATCH_RECOGNIZE
[
https://issues.apache.org/jira/browse/CALCITE-1911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123278#comment-16123278
]
Dian Fu edited comment on CALCITE-1911 at 8/11/17 12:38 PM:
Have updated the PR according to review comments.
Have also added the following method in {{LogicalMatch}}. Although this is not
related to this JIRA, but the change is very small and so just fix it here.
{code}
public RelNode accept(RelShuttle shuttle) {
return shuttle.visit(this);
}
{code}
was (Author: dian.fu):
Have updated the PR according to review comments.
Have also added the following method in {{LogicalMatch}}. Although this is not
related to this JIRA, but the change is very small and so just fix it here.
{quote}
@Override public RelNode accept(RelShuttle shuttle) {
return shuttle.visit(this);
}
{quote}
> Support WITHIN clause in MATCH_RECOGNIZE
>
>
> Key: CALCITE-1911
> URL: https://issues.apache.org/jira/browse/CALCITE-1911
> Project: Calcite
> Issue Type: Bug
>Reporter: Dian Fu
>Assignee: Julian Hyde
> Labels: match
>
> Window is an important feature for pattern detection, it defines the time
> duration for the events to match a pattern. Here is an example from
> [doc|https://docs.oracle.com/middleware/1213/eventprocessing/cql-reference/GUID-34D4968E-C55A-4BC7-B1CE-C84B202217BD.htm#CQLLR2119]:
> {code}
> SELECT T.Ac2, T.Bc2, T.Cc2
> FROM S
> MATCH_RECOGNIZE(
> MEASURES A.c2 as Ac2, B.c2 as Bc2, C.c2 as Cc2
> PATTERN (A (B+ | C)) within 3000 milliseconds
> DEFINE
> A as A.c1=10 or A.c1=25,
> B as B.c1=20 or B.c1=15 or B.c1=25,
> C as C.c1=15
> ) as T
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1937) Web site for Avatica Go
[ https://issues.apache.org/jira/browse/CALCITE-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123227#comment-16123227 ] Francis Chuang commented on CALCITE-1937: - I've done the following: - Move documentation into go_client_reference.md under site/ - Create go_history.md under site/ - Reduced README.md to the barebones. See PR: https://github.com/apache/calcite-avatica-go/pull/2 Question: I've removed most references to Apache Phoenix. Is this a good idea? There may be some benefits of including references to Phoenix as there is no doubt people are searching for a Go Phoenix database/sql driver using their favorite search engine. Having no references to Phoenix reduces this visibility, although it prevents confusion between the Phoenix and Calcite projects. > Web site for Avatica Go > --- > > Key: CALCITE-1937 > URL: https://issues.apache.org/jira/browse/CALCITE-1937 > Project: Calcite > Issue Type: Bug > Components: avatica-go >Reporter: Julian Hyde >Assignee: Francis Chuang > > Create a web site for calcite-avatica-go. > How about this: > * At run time, the pages should appear under http://calcite.apache.org/avatica > * The pages should be source-controlled under calcite-avatica-go/site, in > markdown format (same as calcite and avatica), and generated into svn using > similar trickery to calcite and avatica. > * Reduce the amount of content in > https://github.com/apache/calcite-avatica-go/blob/master/README.md. The > "documentation" stuff should move to under http://calcite.apache.org/avatica. > So the page will be mainly a re-direct to the Apache home page. Similar to > https://github.com/apache/calcite-avatica/blob/master/README.md, in fact. > * Add a go_history.md file. > Should avatica-go appear on http://calcite.apache.org/avatica/downloads, or > should it have its own download page? I think it probably the former. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (CALCITE-1918) Add support for Regular Expression Operators (RLIKE)
[
https://issues.apache.org/jira/browse/CALCITE-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sunjincheng closed CALCITE-1918.
Resolution: Won't Fix
> Add support for Regular Expression Operators (RLIKE)
> -
>
> Key: CALCITE-1918
> URL: https://issues.apache.org/jira/browse/CALCITE-1918
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: sunjincheng
>Assignee: sunjincheng
>
> Currently Regular Expression Operators (RLIKE) are not supported. e.g.:
> {code}
> select * from emps name rlike '^(K|G|W)'
> {code}
> we'll get Error:
> {code}
> Error: Error while executing SQL "select * from emps name rlike '^(K|G|W)'":
> parse failed: Encountered "rlike" at line 1, column 25.
> {code}
> So, in this JIRA. I want add RLIKE supported.
> Reference:
> MySql: https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CALCITE-1918) Add support for Regular Expression Operators (RLIKE)
[
https://issues.apache.org/jira/browse/CALCITE-1918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16122980#comment-16122980
]
sunjincheng commented on CALCITE-1918:
--
Thanks [~julianhyde], your right. I'll close this JIRA. :-)
> Add support for Regular Expression Operators (RLIKE)
> -
>
> Key: CALCITE-1918
> URL: https://issues.apache.org/jira/browse/CALCITE-1918
> Project: Calcite
> Issue Type: Bug
> Components: core
>Reporter: sunjincheng
>Assignee: sunjincheng
>
> Currently Regular Expression Operators (RLIKE) are not supported. e.g.:
> {code}
> select * from emps name rlike '^(K|G|W)'
> {code}
> we'll get Error:
> {code}
> Error: Error while executing SQL "select * from emps name rlike '^(K|G|W)'":
> parse failed: Encountered "rlike" at line 1, column 25.
> {code}
> So, in this JIRA. I want add RLIKE supported.
> Reference:
> MySql: https://dev.mysql.com/doc/refman/5.7/en/regexp.html#operator_regexp
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
