On Nov 8, 2016, at 2:22 PM, Josh Elser <[email protected]> wrote:
Great, thanks for the input, Francis. I think the Go driver would be a good "guinea
pig" for the process.
Let's less this proposed process shake out with input from others and then we
can start planning how to move forward specifically with the Golang driver.
F21 wrote:
Hey all,
My thoughts in-line:
On 9/11/2016 4:34 AM, Josh Elser wrote:
Re-vitalizing some discussion here (updating the subject accordingly)
Thinking ahead with the assumption that the PMC and Francis all want
to bring this code under governance of the Calcite PMC, what does
"adoption of an Avatica client" really entail? My thoughts..
* Perform ASF IP Clearance [1]. Dbl-checking copyright is the most
difficult thing (in most cases, it shouldn't be difficult).
This shouldn't be a problem. However the project imports some
dependencies that are not licensed under the Apache 2 License. The
dependencies are not stored in the git repository, but are imported by
the user's package manager. Will this be an issue? See dependency list
here: https://github.com/Boostport/avatica/blob/master/vendor/vendor.json
* Create a new repository for the new client
+1. In general, it is best to have the code in its own repository, so
that it's easier to import.
* Define what (if any) released artifacts are (in addition to
source-code)
Go library maintainers do not release any artifacts (in general), and we
are not providing any artifacts, so this should not be a problem.
* Ensure code meets licensing requirements of ASF
The code is licensed under the Apache 2 License. Is there anything else
that needs to be done?
Short-answer: yes :)
Having the ASL already applied to the code base makes this process very easy,
however.
* Establish build, test, and release steps for the new client
This should be quite straight forward. Since we do not need to build
anything, we just need to make sure we have tests running on master and
any pull requests. When required, pushing a tag will generate a release.
As Go's package management story is somewhat fragmented, we do need to
provide some instructions on installing the package and pulling in the
dependencies. It currently uses govendor, but I want to switch to glide
soon, as glide is more mature and works better (from my experience).
* Establish CI for commits/patches (manual, if not automated?)
Automated CI is a must. I currently use Wercker, as it allows me to
easily build in docker containers using the official Go image. I can
then easily update Go's version by switching the image in the
configuration file. I believe Jenkins does support using docker for
builds, so I hope this is something that is possible. For commits and
patches, I would prefer to use Github pull requests, just like Calcite.
We should also get the ASF bot to automatically build PRs and ping the
relevant JIRAs (if any).
Cool. Definitely implementation details here. Some leg-work would be required
to figure out exactly how we want to approach this. I'm sure we have lots of
freedom.
My thinking is that we can rely on the backwards compatibility
guarantees of Avatica's wire protocol to deal with the differing
release schedules. Specifically, an older version of the Golang client
should still work with newer versions of the Avatica server -- they
should not require simultaneous releases of all Avatica clients with
the de-facto Java client and Avatica server.
+1. In fact, I believe that most clients have switched to using
protobufs, so backwards compatibility should not be a big problem unless
we accidentally break something.
Agreed.
If we can codify these practices, it would make adoption of future
clients less intimidating, letting us focus on the positives of having
a large collection of clients in other languages.
Thoughts?
+1 Having lots of clients would be a huge plus for Calcite and other
projects such as Phoenix, etc. Go 1.8, which is due in a few months will
bring a lot of new features to the database/sql package (see
https://docs.google.com/document/d/1F778e7ZSNiSmbju3jsEWzShcb8lIO4kDyfKDNm4PNd8/edit?usp=sharing).
I haven't had a chance to update the project to include the new
features, but I am really excited :)
- Josh
[1] http://incubator.apache.org/ip-clearance/
Julian Hyde wrote:
Probably not, in the near term at least. The two projects have
separate release schedules, artifacts and web sites, which seems to
give them enough breathing space for now. Maybe we’ll split source
code repositories at some point. Because the code is all managed by
Apache’s IP governance, any option we choose would be fairly
straightforward.
Julian
On May 17, 2016, at 8:11 PM, F21<[email protected]> wrote:
Thanks for opening the issue on JIRA, Julian.
Let me know if there's anything I can do to speed up the process.
Will Avatica be spun out as its own project?
Francis
On 18/05/2016 1:06 PM, Julian Hyde wrote:
It sounds as if there is general approval for this. I have logged
https://issues.apache.org/jira/browse/CALCITE-1240<https://issues.apache.org/jira/browse/CALCITE-1240>
to track.
Julian
On May 17, 2016, at 8:00 PM, Josh Elser<[email protected]> wrote:
Big +1 from me.
I think if you're amenable to it, Francis, I'm more than willing
to help make this a "formal" part of Avatica!
Congrats and great work on what you have done already!
F21 wrote:
That would be really great! I think that would help make a lot of
Phoenix drivers currently available to support avatica
generically. It
would also reduce the burden of driver maintainers maintaining a
list of
errors.
On 18/05/2016 3:48 AM, Julian Hyde wrote:
Would it help if we added a function to Avatica’s API, so a client
could ask for that map when connecting? It would allow the
driver to
work against multiple servers, and in the phoenix-only case it
would
mean that you would’t have to upgrade the client driver if you
upgraded the phoenix server.
(We’re still talking hypotheticals. I would like to hear more of a
consensus from the community before we include this in Avatica.)
Julian
On May 16, 2016, at 10:57 PM, F21<[email protected]> wrote:
Hey Julian,
The code should be useful for avatica in general. The only phoenix
specific bit is the map of Phoenix error codes here:
https://github.com/Boostport/avatica/blob/master/errors.go#L77
I think other database backends can have their own maps. It might
also be nice to be able to interrogate the avatica server to
see if
the backend is Phoenix or some other database, and the switch the
errors map accordingly.
Francis
On 17/05/2016 3:54 PM, Julian Hyde wrote:
Excellent! Thanks for doing this.
I haven't yet looked at the code to see how much is specific to
Phoenix and whether it would work against any Avatica
provider. If
it is generic, and if you are amenable, there might be a place
for
it in the Avatica project.
What do others think?
Julian
On May 16, 2016, at 10:43 PM, F21<[email protected]> wrote:
Hi all,
I have just open sourced a golang driver for Phoenix and
Avatica.
The code is licensed using the Apache 2 License and is available
here: https://github.com/Boostport/avatica
Contributions are very welcomed :)
Cheers,
Francis
