Re: type name changes

[Yingyi Bu]

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  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  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 
>> 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
>>
>
>

Re: Debugging with generated code

[Ildar Absalyamov]

Hit that issue as well.
Is there any workaround to configure the debugger to pick up generated byte 
code?
Or alternatively have a flag which disables runtime codegen during debug 
sessions?

> On Sep 13, 2016, at 19:00, Michael Blow  wrote:
> 
> I believed ASTERIX-1459 to be fixed, but it seems there are some issues.
> When running the execution tests, if I step into a generated evaluator, I
> can set breakpoints as normal.  But, when running a one-off single test, it
> seems while I can step into the generated evaluators, I cannot set
> breakpoints.  I will re-open 1459 for further investigation.
> 
> Thanks,
> 
> -MDB
> 
> On Tue, Sep 13, 2016 at 6:16 PM Xikui Wang  wrote:
> 
>> Hi Devs,
>> 
>> I am debugging with FieldAccessByIndexEvalFactory, and the break points are
>> not working here. This may be related to  ASTERIXDB-1459
>> . Is this fixed in
>> the code base? Thanks.
>> 
>> Best,
>> Xikui
>> 

Best regards,
Ildar

Re: type name changes

[Yingyi Bu]

>> 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  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 
> 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
>

Fwd: type name changes

[Taewoo Kim]

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 
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

Jenkins build became unstable: asterix-integration-tests e17454ae

[Asterix build server]

See