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 >>>>>>>> >> >
