Isn't this the same behaviour as running any ASH function in the CLI?
Feature - Implemented print()++
- Thread starter fredg1
- Start date
Isn't this the same behaviour as running any ASH function in the CLI?
No, this is specific to dump (and to_json, for that matter)
The issue boils down to this:
See that null? That's the "issue" itself.
Explanation
Now to understand "how" this is the issue:
First, take a look at the expected data type of the dump function:
You'll notice that dump expects "ANY_TYPE". This is because, while there is a way to tell a function to accept "any aggregate", it's not, as far as I know, possible to tell a function to accept "any record".
(Actually, even if it was possible, all this would do is make it so that "the problem doesn't affect dump". The problem is still there regardless, also affecting to_json specifically:
)
So the issue is how line 140 of DataTypes.java lists null instead of... anything else.
I actually noticed this when making dump, but left it there because I didn't know if there would be unknown implications to this change (which, in fact, there is/was, since I originally thought the only purpose of that argument was to tell what to print in the GCLI when using ashref, but here, we can see it has an actual impact on functions when called directly from the GCLI).
The issue boils down to this:
See that null? That's the "issue" itself.
Explanation
Now to understand "how" this is the issue:
First, take a look at the expected data type of the dump function:
You'll notice that dump expects "ANY_TYPE". This is because, while there is a way to tell a function to accept "any aggregate", it's not, as far as I know, possible to tell a function to accept "any record".
(Actually, even if it was possible, all this would do is make it so that "the problem doesn't affect dump". The problem is still there regardless, also affecting to_json specifically:
)So the issue is how line 140 of DataTypes.java lists null instead of... anything else.
I actually noticed this when making dump, but left it there because I didn't know if there would be unknown implications to this change (which, in fact, there is/was, since I originally thought the only purpose of that argument was to tell what to print in the GCLI when using ashref, but here, we can see it has an actual impact on functions when called directly from the GCLI).
Rinn
Developer
It looks like none objects like $item[none] are written to data files as [-1]null instead of [-1]none now. I haven't noticed any adverse effects from this but it seems worth reporting because it's probably unintentional and when I mentioned it to gausie and he speculated this was probably caused by r20381.