git.net

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

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


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