Mailing-List: contact dev-help@asterixdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@asterixdb.apache.org
MIME-Version: 1.0
In-Reply-To: <CABytAGqkXBL-v=8r8Lc76vqCKeKw_mR7s=Mq78nZWQZf=1eC3g@mail.gmail.com>
References: <CALjEsF7oZ9oCu64Sb+_8svGSpQGLP_6yb0kvCvacsXk4L3HBdQ@mail.gmail.com>
 <CABytAGpSFEk-E+kEUNuHDy9MCMgMZN=zRw3vvrOEe8Tch8f5Nw@mail.gmail.com>
 <CALjEsF4FXNt7tk8cq8We2ErdJGF8Ed-oJfTs6F6xKucAxi6Jug@mail.gmail.com>
 <CALjEsF43oQDPauCWZ6_uquRHW-0F1AZ76oga+pWWMO5jU55qOg@mail.gmail.com>
 <CAEEsEsRshCif5OuTiD77htoru1VP3RkR7KFLpj2C6hNN63Rgtw@mail.gmail.com>
 <CALjEsF4KDU-RZJSSbwUg3+TP3Ta7cP2Zo1eiNifgTG6RYcZxKw@mail.gmail.com> <CABytAGqkXBL-v=8r8Lc76vqCKeKw_mR7s=Mq78nZWQZf=1eC3g@mail.gmail.com>
From: Yingyi Bu <buyingyi@gmail.com>
Date: Tue, 18 Oct 2016 08:59:51 -0700
Message-ID: <CALjEsF6NGTeNHacGgCcRq+FzOzyoyFo5fOG6iV5X9eg2fSO2zA@mail.gmail.com>
Subject: Re: type name changes
To: dev@asterixdb.apache.org
Content-Type: multipart/alternative; boundary=001a1142259660f5e4053f25c866
archived-at: Tue, 18 Oct 2016 16:00:05 -0000

--001a1142259660f5e4053f25c866
Content-Type: text/plain; charset=UTF-8

 Taewoo,

    >> So, can we use "int" for "bigint" to be consistent?
    That's not what other SQL systems do. We probably don't want to create
new conventions (or surprises) in this area.

    Just FYI.
    Hive:

https://cwiki.apache.org/confluence/display/Hive/LanguageManual+Types#LanguageManualTypes-NumericTypes


    Postgres:

    https://www.postgresql.org/docs/9.6/static/datatype-numeric.html


    MySQL:

    http://dev.mysql.com/doc/refman/5.7/en/integer-types.html


    MSSQL:

    https://msdn.microsoft.com/en-us/library/ms187745.aspx


Best,
Yingyi


On Tue, Oct 18, 2016 at 8:52 AM, Taewoo Kim <wangsaeu@gmail.com> wrote:

> So, can we use "int" for "bigint" to be consistent?
>
> Best,
> Taewoo
>
> On Tue, Oct 18, 2016 at 7:34 AM, Yingyi Bu <buyingyi@gmail.com> wrote:
>
> > >>Actually I think Taewoo is right about having supported int as an int64
> > >>synonym in ADM.
> >
> > Ahh, just checked an old version and you're right!
> >
> > >> But I think the revised 101 examples used int, no?
> > Yes, they use int.
> >
> > >> We should just check so we know if we need to warn them when
> > >> we release....
> >
> > Yes. Datasets created by their old DDLs should still work.
> > But this will impact their new DDLs.
> >
> > Best,
> > Yingyi
> >
> >
> >
> > On Tue, Oct 18, 2016 at 12:49 AM, Mike Carey <dtabass@gmail.com> wrote:
> >
> > > Actually I think Taewoo is right about having supported int as an int64
> > > synonym in ADM.  However, apparently this change didn't break any
> tests,
> > so
> > > we probably didn't have anything whose outputs were changed.  But I
> think
> > > the revised 101 examples used int, no?  Not sure if any of our users
> had
> > > followed that transition - can Ian ask SDSC and Condor for copies of
> > their
> > > current ADMs?  We should just check so we know if we need to warn them
> > when
> > > we release....
> > >
> > > On Oct 17, 2016 11:49 PM, "Yingyi Bu" <buyingyi@gmail.com> wrote:
> > >
> > > > This is the change that changes "record" to "object".
> > > > https://asterix-gerrit.ics.uci.edu/#/c/1295/
> > > >
> > > > The existing record functions will still work.
> > > > If anyone thinks that the change breaks the current use case, please
> > let
> > > me
> > > > know.
> > > >
> > > > Best,
> > > > Yingyi
> > > >
> > > >
> > > >
> > > > On Mon, Oct 17, 2016 at 10:26 PM, Yingyi Bu <buyingyi@gmail.com>
> > wrote:
> > > >
> > > > > >> We used int for the abbreviation
> > > > > >> for INT64 (I assume that is now bigint?) type. Now, INT is an
> > > > > abbreviation
> > > > > >> for INT32?
> > > > >
> > > > > We didn't have "int" as a type name.
> > > > > A constant integer value by default was an int64.  That's
> unchanged.
> > > > > Now, a constant integer value by default is a bigint.
> > > > >
> > > > > >> Aren't INT32 type displaying i32 as suffix?
> > > > > Other than type names, nothing is changed. I think we stopped using
> > > > suffix
> > > > > quite a while ago.
> > > > >
> > > > > Best,
> > > > > Yingyi
> > > > >
> > > > >
> > > > > On Mon, Oct 17, 2016 at 10:14 PM, Taewoo Kim <wangsaeu@gmail.com>
> > > wrote:
> > > > >
> > > > >> I checked the newly changed documentation. We used int for the
> > > > >> abbreviation
> > > > >> for INT64 (I assume that is now bigint?) type. Now, INT is an
> > > > abbreviation
> > > > >> for INT32? I thought we converted the default type to INT64
> > (bigint).
> > > > >> Aren't INT32 type displaying i32 as suffix?
> > > > >>
> > > > >> ---------- Forwarded message ----------
> > > > >> From: Yingyi Bu <buyingyi@gmail.com>
> > > > >> Date: Mon, Oct 17, 2016 at 9:55 PM
> > > > >> Subject: type name changes
> > > > >> To: users@asterixdb.apache.org
> > > > >>
> > > > >>
> > > > >> Hi users,
> > > > >>
> > > > >> Recently, we did some name changes for builtin types to better
> align
> > > > with
> > > > >> SQL's types:
> > > > >> https://ci.apache.org/projects/asterixdb/datamodel.html
> > > > >>
> > > > >> There will be a further name change that changes "record" to
> > "object",
> > > > to
> > > > >> better align with JSON.
> > > > >> The purpose of renaming those builtin types is to lower the usage
> > bar
> > > > for
> > > > >> users who are using either SQL or JSON.
> > > > >>
> > > > >> Note that all the old type names should still work as it used to
> be.
> > > > >> However, it is better to move to new names for future use cases.
> > > > >>
> > > > >> Best,
> > > > >> Yingyi
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

--001a1142259660f5e4053f25c866--