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: <CALjEsF6NGTeNHacGgCcRq+FzOzyoyFo5fOG6iV5X9eg2fSO2zA@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> <CALjEsF6NGTeNHacGgCcRq+FzOzyoyFo5fOG6iV5X9eg2fSO2zA@mail.gmail.com>
From: Taewoo Kim <wangsaeu@gmail.com>
Date: Tue, 18 Oct 2016 09:05:03 -0700
Message-ID: <CABytAGryopvRcxxG4jEZHdh+a+y=bqVOH7jbrVYwAn8+Kt_8zA@mail.gmail.com>
Subject: Re: type name changes
To: dev@asterixdb.apache.org
Content-Type: multipart/alternative; boundary=94eb2c094852bfad85053f25dc50
archived-at: Tue, 18 Oct 2016 16:05:41 -0000

--94eb2c094852bfad85053f25dc50
Content-Type: text/plain; charset=UTF-8

I understood that other SQL based systems have int and bigint. What we used
was "int" for "int64". I'm just worried about the backward compatibility.
If we change the definition (before:int for int64, after:int for integer
(int32)) and outside users that Mike mentioned did not have numbers greater
than INT32 range, I think it's OK.

Best,
Taewoo

On Tue, Oct 18, 2016 at 8:59 AM, Yingyi Bu <buyingyi@gmail.com> wrote:

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

--94eb2c094852bfad85053f25dc50--