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 <buyin...@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 <wangs...@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 <buyin...@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 <dtab...@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" <buyin...@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 <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. > > > > > > > > > > > > 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 type to INT64 > > > (bigint). > > > > > >> Aren't INT32 type displaying i32 as suffix? > > > > > >> > > > > > >> ---------- Forwarded message ---------- > > > > > >> From: Yingyi Bu <buyin...@gmail.com> > > > > > >> 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 > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > >
