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" <wangs...@gmail.com> wrote: Thanks for the clarification. Best, Taewoo On Tue, Oct 18, 2016 at 9:12 AM, Yingyi Bu <buyin...@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 <wangs...@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 <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 > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
