Re: type name changes

2016-10-18 Thread Mike Carey
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"  wrote:

Thanks for the clarification.

Best,
Taewoo

On Tue, Oct 18, 2016 at 9:12 AM, Yingyi Bu  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  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  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 
> wrote:
> > >
> > > > So, can we use "int" for "bigint" to be consistent?
> > > >
> > > > Best,
> > > > Taewoo
> > > >
> > > > On Tue, Oct 18, 2016 at 7:34 AM, Yingyi Bu 
> 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 
> > > 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" 
> 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 <
> buyin...@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 

Re: type name changes

2016-10-18 Thread Taewoo Kim
Thanks for the clarification.

Best,
Taewoo

On Tue, Oct 18, 2016 at 9:12 AM, Yingyi Bu  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  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  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 
> wrote:
> > >
> > > > So, can we use "int" for "bigint" to be consistent?
> > > >
> > > > Best,
> > > > Taewoo
> > > >
> > > > On Tue, Oct 18, 2016 at 7:34 AM, Yingyi Bu 
> 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 
> > > 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" 
> 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 <
> buyin...@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.
> > > > > > > >
> > > > > > > > 

Re: type name changes

2016-10-18 Thread Yingyi Bu
>> 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  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  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  wrote:
> >
> > > So, can we use "int" for "bigint" to be consistent?
> > >
> > > Best,
> > > Taewoo
> > >
> > > On Tue, Oct 18, 2016 at 7:34 AM, Yingyi Bu  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 
> > 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"  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 
> > > > 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 <
> wangs...@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 

Re: type name changes

2016-10-18 Thread Yingyi Bu
 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  wrote:

> So, can we use "int" for "bigint" to be consistent?
>
> Best,
> Taewoo
>
> On Tue, Oct 18, 2016 at 7:34 AM, Yingyi Bu  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  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"  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 
> > 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 
> > > 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 
> > > > >> Date: Mon, Oct 17, 2016 at 9:55 PM
> > > > >> Subject: type name changes
> > > > >> To: us...@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

2016-10-18 Thread Taewoo Kim
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  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  wrote:
>
> > So, can we use "int" for "bigint" to be consistent?
> >
> > Best,
> > Taewoo
> >
> > On Tue, Oct 18, 2016 at 7:34 AM, Yingyi Bu  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 
> 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"  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 
> > > 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  >
> > > > 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 
> > > > > >> Date: Mon, Oct 17, 2016 at 9:55 PM
> > > > > >> Subject: type name changes
> > > > > >> To: us...@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 

Re: type name changes

2016-10-18 Thread Taewoo Kim
So, can we use "int" for "bigint" to be consistent?

Best,
Taewoo

On Tue, Oct 18, 2016 at 7:34 AM, Yingyi Bu  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  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"  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 
> 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 
> > 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 
> > > >> Date: Mon, Oct 17, 2016 at 9:55 PM
> > > >> Subject: type name changes
> > > >> To: us...@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

2016-10-18 Thread Yingyi Bu
>>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  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"  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  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 
> 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 
> > >> Date: Mon, Oct 17, 2016 at 9:55 PM
> > >> Subject: type name changes
> > >> To: us...@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

2016-10-18 Thread Mike Carey
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"  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  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  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 
> >> Date: Mon, Oct 17, 2016 at 9:55 PM
> >> Subject: type name changes
> >> To: us...@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

2016-10-17 Thread Yingyi Bu
>> 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  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 
> Date: Mon, Oct 17, 2016 at 9:55 PM
> Subject: type name changes
> To: us...@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
>