You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@asterixdb.apache.org by Taewoo Kim <wa...@gmail.com> on 2016/10/18 05:14:57 UTC

Fwd: type name changes

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 <bu...@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

Re: type name changes

Posted by Mike Carey <dt...@gmail.com>.

Agreed that this is a needed consistency correction and should be benign.
I think our first top level project release, with SQL++ and other goodies,
should be the point beyond which such changes are no longer okay .... I
think this is "last call" for data-impacting changes.  Henceforth we'll
need to provide serious backward compatibility!  (For real, not just talk.)

On Oct 18, 2016 9:14 AM, "Taewoo Kim" <wa...@gmail.com> wrote:

Thanks for the clarification.

Best,
Taewoo

On Tue, Oct 18, 2016 at 9:12 AM, Yingyi Bu <bu...@gmail.com> wrote:

> >> 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.
>
> As I said, if they have created a dataset using the old DDL on an old
> version,
> nothing will break because in the metadata, the type is int64.
>
> The only thing is that if they're going to create a new dataset based on
> the new binary, they need to
> be aware that int means int32.  Since we will notify them, I think it's
> fine.
>
> Best,
> Yingyi
>
>
> On Tue, Oct 18, 2016 at 9:05 AM, Taewoo Kim <wa...@gmail.com> wrote:
>
> > 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 <bu...@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 <wa...@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 <bu...@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 <dt...@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" <bu...@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 <bu...@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
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>