git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to create user-defined data types in calcite?


Sure, I understand. But no one can do a fast-forward merge to the site
branch unless they know for sure that nothing in there is going to make
changes to the site that shouldn't be deployed. And then we're back to
whoever updates the site needing to already know what should be deployed.

I'm suggesting the following:

1. During development, cherry pick *only* commits which affect the site
from `master` to `site`
2. At release time, force push the `master` branch to `site`.
Unfortunately, this means if someone does mistakenly make site changes
directly to the `site` branch, then these will be lost. I don't see an easy
way of preventing this.

--
Michael Mior
mmior@xxxxxxxxxxxx

2018-04-25 14:25 GMT-04:00 Julian Hyde <jhyde@xxxxxxxxxx>:

> Well, consider the current “master” and “site” branches[1]. They were in
> sync until CALCITE-2267 [2]. Then Shuyi committed CALCITE-2045 [3], which
> had changes to the site related to product features, so “master” and “site”
> had to diverge.
>
> It isn’t always possible for “master” and “site” to be on the same path,
> but for this release, it was until just before CALCITE-2045.
>
> Julian
>
> [1] https://github.com/apache/calcite/network <https://github.com/apache/
> calcite/network>
>
> [2] https://github.com/apache/calcite/commit/
> f5b041ff46710fca7d104385b7f917384e4a7f1a <https://github.com/apache/
> calcite/commit/f5b041ff46710fca7d104385b7f917384e4a7f1a>
>
> [3] https://github.com/apache/calcite/commit/
> 570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c <https://github.com/apache/
> calcite/commit/570aca3d4fea34edcb04d0a5ec02f0fcf8925b0c>
>
>
>
> > On Apr 25, 2018, at 11:16 AM, Michael Mior <mmior@xxxxxxxxxxxx> wrote:
> >
> > I don't see how the sync with the master branch could be a fast-forward
> > merge. This isn't possible if commits just affecting the site have been
> > cherry picked since the last sync.
> >
> > --
> > Michael Mior
> > mmior@xxxxxxxxxxxx
> >
> > 2018-04-25 14:13 GMT-04:00 Julian Hyde <jhyde@xxxxxxxxxx>:
> >
> >> My personal opinion about (non-fast-forward) merge commits: never do
> them.
> >>
> >> If site and master can be on the same line (i.e. if there is no new
> >> product-related changes to the site) then they should be.
> >>
> >> If they need to diverge, then cherry-pick individual commits from master
> >> to site.
> >>
> >> I added some instructions at the end of https://github.com/apache/
> >> calcite/blob/master/site/README.md <https://github.com/apache/
> >> calcite/blob/master/site/README.md>.
> >>
> >> Julian
> >>
> >>
> >>
> >>> On Apr 25, 2018, at 11:06 AM, Michael Mior <mmior@xxxxxxxxxxxx> wrote:
> >>>
> >>> Sure. Although there (at least) two ways of syncing site with master.
> One
> >>> being to force push master to the site branch and the other to merge
> the
> >>> master branch into site. I do kind of like the idea of the force push
> >> just
> >>> to avoid having the site branch be eternally filled with a bunch of
> merge
> >>> commits.
> >>>
> >>> One thing that didn't immediately occur to me is what happens with the
> >>> Javadoc?
> >>>
> >>> --
> >>> Michael Mior
> >>> mmior@xxxxxxxxxxxx
> >>>
> >>> 2018-04-25 13:30 GMT-04:00 Julian Hyde <jhyde@xxxxxxxxxx>:
> >>>
> >>>> A force-push to the “site” branch each release would not be a terrible
> >>>> thing. (Force-pushes are only suspect when they are to the master
> >> branch or
> >>>> a release branch.) Before the release, the release manager should make
> >> sure
> >>>> that edits on “site" have made it to “master”. Right after the
> release,
> >>>> they will deploy the site from the “site” branch, which almost
> certainly
> >>>> means syncing “site" with “master”.
> >>>>
> >>>>> On Apr 25, 2018, at 10:24 AM, Michael Mior <mmior@xxxxxxxxxxxx>
> wrote:
> >>>>>
> >>>>> Sounds reasonable to me. I like that better than the current approach
> >> of
> >>>>> whoever is updating the site needing to maintain mental state on what
> >> is
> >>>>> and isn't ready to be posted. We should of course add documentation
> for
> >>>>> this as part of the release process. We also should make clear in the
> >>>> site
> >>>>> documentation that nothing should be committed to the site branch
> >>>> directly,
> >>>>> but only what is cherry picked from master. I might even suggest that
> >> the
> >>>>> sync which happens during release be a force push of the current
> master
> >>>> to
> >>>>> the site branch, but I'm not sure I like that idea.
> >>>>>
> >>>>> --
> >>>>> Michael Mior
> >>>>> mmior@xxxxxxxxxxxx
> >>>>>
> >>>>> 2018-04-25 12:52 GMT-04:00 Julian Hyde <jhyde@xxxxxxxxxx>:
> >>>>>
> >>>>>> I am adding Kevin to the committers list, and I am seeing the
> problem
> >> of
> >>>>>> mixed changes - recently Michael has edited the site to add two PMC
> >>>>>> members, and Shuyi has added documentation for CREATE TYPE. We want
> >> the
> >>>>>> former to appear on the site, but the latter should wait until the
> >>>> release.
> >>>>>>
> >>>>>> I propose to create a “site” git branch that cherry-picks changes
> that
> >>>> we
> >>>>>> wish to have appear on the site immediately.
> >>>>>>
> >>>>>> On each release, it would be in sync with master, but might start to
> >>>>>> differ when we add documentation for features. It would sync up on
> the
> >>>> next
> >>>>>> release.
> >>>>>>
> >>>>>> Any comments/objections?
> >>>>>>
> >>>>>> Julian
> >>>>>>
> >>>>>>
> >>>>>>> On Apr 24, 2018, at 10:17 PM, Shuyi Chen <suez1224@xxxxxxxxx>
> wrote:
> >>>>>>>
> >>>>>>> You are right. Thanks a lot for the explanation, Julian.
> >>>>>>>
> >>>>>>> On Tue, Apr 24, 2018 at 12:27 PM, Julian Hyde <jhyde@xxxxxxxxxx>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> I think it’s misleading to end-users if the web site contains
> >> features
> >>>>>>>> that have not yet been released. So, we aim to re-generate the web
> >>>> site
> >>>>>>>> just after a release. (For non product-related stuff, such as
> >>>> committers
> >>>>>>>> and upcoming talks, we change the web site continuously. The
> person
> >>>>>>>> maintaining the web site has to be a bit careful not to publish
> the
> >>>>>> wrong
> >>>>>>>> stuff.)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Apr 21, 2018, at 10:13 PM, Shuyi Chen <suez1224@xxxxxxxxx>
> >> wrote:
> >>>>>>>>>
> >>>>>>>>> @Julian, thanks for reviewing the code. I think we need to
> >> regenerate
> >>>>>> the
> >>>>>>>>> website as well so that it contains the latest documentation on
> >> type
> >>>>>>>>> collection and type DDLs. Let me know how I can help.
> >>>>>>>>>
> >>>>>>>>> @Valli, with the latest master, you should be able to either use
> >>>> CREATE
> >>>>>>>>> TYPE statement to define your own type or define your new type in
> >> the
> >>>>>>>> JSON
> >>>>>>>>> schema.
> >>>>>>>>>
> >>>>>>>>> On Sat, Apr 21, 2018 at 12:48 AM, Shuyi Chen <suez1224@xxxxxxxxx
> >
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Thanks a lot for your time , Julian. Let me know if you need
> >>>> anything.
> >>>>>>>>>>
> >>>>>>>>>> shuyi
> >>>>>>>>>> On Fri, Apr 20, 2018 at 5:57 PM Julian Hyde <jhyde@xxxxxxxxxx>
> >>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Yes, I’ve ignored that change for a couple of months (sorry
> >> Shuyi)
> >>>>>> but
> >>>>>>>> I
> >>>>>>>>>>> reviewed it yesterday and am currently testing, so it should be
> >>>>>>>> committed
> >>>>>>>>>>> to master shortly.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Apr 20, 2018, at 5:41 PM, Shuyi Chen <suez1224@xxxxxxxxx>
> >>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Currently, user defined type is not supported in Calcite. But
> >> it's
> >>>>>>>> WIP,
> >>>>>>>>>>>> please see https://issues.apache.org/jira/browse/CALCITE-2045
> .
> >>>> With
> >>>>>>>>>>> this
> >>>>>>>>>>>> PR, you can either use CREATE TYPE statement to define your
> own
> >>>> type
> >>>>>>>> or
> >>>>>>>>>>>> define your new type in the JSON schema.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks
> >>>>>>>>>>>> Shuyi
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Fri, Apr 20, 2018 at 4:27 AM, Valli Annamalai <
> >>>>>>>>>>> aishwaryaanns@xxxxxxxxx>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I want to parse a query having 'text' in place of 'varchar'.
> >> For
> >>>>>>>>>>>>> example, select
> >>>>>>>>>>>>> cast(ps_comment as text) from part While parsing calcite is
> >>>>>> showing,
> >>>>>>>>>>>>> Unknown data type name 'TEXT'.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> How can I make calcite to parse the above query successfully
> >>>> having
> >>>>>>>>>>>>> user-defined data type 'text'?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks in advance
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> "So you have to trust that the dots will somehow connect in
> your
> >>>>>>>>>>> future."
> >>>>>>>>>>>
> >>>>>>>>>>> --
> >>>>>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>>>>>> future."
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>>>> future."
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> "So you have to trust that the dots will somehow connect in your
> >>>> future."
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>