git.net

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

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


Good point about the rebase. I would suggest that as the proposed process
since it means we don't lose changes mistakenly committed to site. I would
suggest that after the rebase, "git log master..site" to be run to ensure
that it produces no output. So the only purpose of the rebase vs "git reset
--hard origin/master" is tto catch commits that have snuck directly into
the `site` branch.

--
Michael Mior
mmior@xxxxxxxxxxxx

2018-04-25 14:41 GMT-04:00 Julian Hyde <jhyde.apache@xxxxxxxxx>:

> I think if you rebase “site” onto “master”, git will spot commits that are
> already on “site”.
>
> $ git checkout site
> $ git rebase -i origin master
>
> All being well, site should end up identical to master after the rebase.
> So force-push is not scary.
>
> Julian
>
>
> > On Apr 25, 2018, at 11:31 AM, Michael Mior <mmior@xxxxxxxxxxxx> wrote:
> >
> > 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."
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>