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