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
On Oct 17, 2016 11:49 PM, "Yingyi Bu" <buyin...@gmail.com> wrote:
> This is the change that changes "record" to "object".
> The existing record functions will still work.
> If anyone thinks that the change breaks the current use case, please let me
> 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
> > 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
> >> 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
> >> SQL's types:
> >> https://ci.apache.org/projects/asterixdb/datamodel.html
> >> There will be a further name change that changes "record" to "object",
> >> better align with JSON.
> >> The purpose of renaming those builtin types is to lower the usage bar
> >> 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