asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yingyi Bu <buyin...@gmail.com>
Subject Re: type name changes
Date Tue, 18 Oct 2016 14:34:35 GMT
>>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 <dtabass@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" <buyingyi@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 <buyingyi@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 <wangsaeu@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 <buyingyi@gmail.com>
> > >> Date: Mon, Oct 17, 2016 at 9:55 PM
> > >> Subject: type name changes
> > >> To: users@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
> > >>
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message