asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yingyi Bu <buyin...@gmail.com>
Subject Re: type name changes
Date Tue, 18 Oct 2016 15:59:51 GMT
 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
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message