I agree with Vladimir.
Although i am very new here but in my mind having one repository will reduce
lot of efforts while not necessarily it will reduce flexibility and modularity
of the the project.
My initial impression is that we can achieve the same modularity constraints
even after merging
Francis>I remembered joining this list a few years back then
Francis>- Calcite - SQL engine used to build the SQL part of your database.
The things is "apache/calcite" is tons of features as in "thing that
converts SQL to MongoDB" or "thing that executes SQL queries over InnoDB
data files",
or "t
I know the below is too wordy, however, English is not my native language,
so I tend to overexplain and duplicate thoughts.
Julian>To allow separate communities
This is something I do not understand.
Let me be explicit: I am OK to maintain bits of avatica code when Calcite
fixes overlap with Avat
Vladimir Sitnikov created CALCITE-4881:
--
Summary: Calcite release tags should have rel/... prefix as per
the ASF requirements
Key: CALCITE-4881
URL: https://issues.apache.org/jira/browse/CALCITE-4881
sunjincheng created CALCITE-4880:
Summary: Re-Open the Travis job that uses Calcite master until
[CALCITE-4877] is fixed
Key: CALCITE-4880
URL: https://issues.apache.org/jira/browse/CALCITE-4880
Proje
I think it is still worthwhile to keep Avatica and Calcite as 2 separate
repositories. I remembered joining this list a few years back then
Avatica was moved into its own repository and my perception of the
components were:
- Avatica - HTTP server that you can put in front of your database so
t
I have no opinion on merging the two repositories or don't.
But If we don't merge it. About CALCITE-4877, Maybe we can:
1) we cancel test Calcite's master branch with Avatica's master branch
directly. (It is unreasonable)
When have an ISSUE need to submit PR in both, we can try:
1) If the PR is go
There are many reasons to divide code into modules. To allow separate
communities, to allow separate release schedules, to reduce coupling, to make
it easier to contribute (because contributors don’t need to understand a large
code base), to increase adoption (because people perceive that they c
These repositories are separate because they have separate release
schedules. Those who were working on calcite.git typically do not want
to be bothered with changes to calcite-avatica.git, and vice versa.
Further, there are downstream users of Avatica directly (without
Calcite) who would be bu
Currently CI for avatica verifies building with calcite/master, and vice
versa.
Otherwise we won't notice integration issues before we release.
Julian suggested that we should support one avatica version only. I agree,
especially of that means we merge the repositories back.
> I think it is a mi
Can you confirm that Calcite is building against both avatica latest
release and avatica master (this seems to be the case based on an avatica
merge breaking calcite ci)? If we truly want to treat the projects as
separate, I would suggest that Calcite only be built against released
avatica artifact
Hi,
Currently, we have calcite-avatica and calcite in different repositories.
Frankly speaking, I do not know what it brings, however, it does create
points of friction:
1) If a feature touches Avatica and Calcite, then PRs are hard to create
and maintain. We just can't create a single PR across b
I think you meant to write “tab1.id = tab2.id”.
Based on your description I think there are a couple of things going wrong in
the JDBC adapter. It should be putting the tables from different MySQL
databases into different calcite schemas. (A calcite schema is a namespace. It
may map onto a da
13 matches
Mail list logo
