|
Derar Novice
Joined: 09 Sep 2006 Posts: 44
|
Posted: Sat Aug 07, 2010 3:58 am
[3.22] @db.key as arg breaks %item |
Passing @db.key as a parameter to an alias or function breaks %item if the parameter is not a list.
In this circumstance, %item will always return the parameter, regardless of what index you look for. %db(@db, key) does not cause this, nor does passing any other kind of value, really.
It's only when a @db.key has a non-list value.
Observe:
Code: |
<var name="TestVar" type="Record" id="8">
<value>Test=4|Test2="4|5"</value>
<json>{"Test2":[4,5],"Test":4}</json>
</var>
<func name="_TestFunc" id="9">
<value>
#IF (%item($list, 3)) {
#ECHO %item($list, 3)
} {
#ECHO "No list item."
}
</value>
<arglist>$list</arglist>
</func>
<alias name="TestAlias" id="10">
<value>
#IF (%item($list, 3)) {
#ECHO %item($list, 3)
} {
#ECHO "No list item."
}
</value>
<arglist>$list</arglist>
</alias>
|
Try:
Code: |
#CALL @_TestFunc(@TestVar.Test)
#CALL @_TestFunc(@TestVar.Test2)
#CALL @_TestFunc(%db(@TestVar, Test))
#CALL @_TestFunc(5)
#CALL @_TestFunc({5|4})
TestAlias @TestVar.Test
TestAlias @TestVar.Test2
|
Outputs:
Code: |
4
No list item.
No list item.
No list item.
No list item.
4
No list item.
|
|
|
|
|
Anaristos Sorcerer
Joined: 17 Jul 2007 Posts: 821 Location: California
|
Posted: Sun Aug 08, 2010 12:21 am |
Perhaps I don't understand what you are trying to do, but it seems you are attempting to fetch the 3rd key of a db record that only has 2 keys.
The JSON record clearly indicates that this is a db record:
Code: |
{"Test2":[4,5],"Test":4}
|
so when %item is applied to this variable it will return the value from the nth key in the record.
For instance:
Code: |
#PRINT %item(%item(@TestVar,1),1) //Access item 1 from key 1.
#PRINT %item(%item(@TestVar,1),2) //Access item 2 from key 1.
|
Will output 4 and 5 respectively.
Likewise:
Code: |
#PRINT %item(%item(@TestVar,2),1) //Access item 1 from key 2.
#PRINT %item(%item(@TestVar,2),2) //Access item 2 from key 2.
|
Will output 4 and null respectively.
And finally:
Code: |
#PRINT %item(@TestVar,1) //Access key 1.
#PRINT %item(@TestVar,2) //Access key 2.
|
Will output 4|5 and 4 respectively.
An index of 3 will always return null for this variable. Whether the attempt is to retrieve the 3rd key or the 3rd item from a value. They don't exist.
This is what I've understood from your post. |
|
_________________ Sic itur ad astra. |
|
|
|
Derar Novice
Joined: 09 Sep 2006 Posts: 44
|
Posted: Mon Aug 09, 2010 1:59 am |
Right, the problem is that it is not returning null, it's returning the value (which is a non-list) as if it were that index.
Any other circumstance it behaves as expected; you get a null value.
If you pass @db.key as the argument, and then use %item on that argument within the function, you get the value itself, not null, which is what you should get (and what you do get if you pass %db(@var, key) instead).
Edit: To clarify, yes, in the example I am deliberately looking for a non-existent 3rd list item, to show the problem. If you look at the example code I provided, the 1st & 3rd function calls should output the same - Not in a List, but they don't. The 2nd function call, which is passed an actual list, works properly as well. It's only when the value of @db.key is a non-list.
In practical terms this comes up for me in a package I have to work with time values. Specifically, to rebuild a seconds tally into a timestamp - I pass the seconds into the function either just as the seconds, or as a 2-item list, in which the first item is the seconds tally, and the second item is the number of leap years to account for. Since there's not always a leap year to factor in, the function checks to see if it needs to do anything with "#IF (!%null(%item($list, 2)))..." This is a problem if I pass in, say, 179 seconds, and get a boatload of days added on for my trouble. |
|
|
|
Zugg MASTER
Joined: 25 Sep 2000 Posts: 23379 Location: Colorado, USA
|
Posted: Mon Aug 09, 2010 4:36 pm |
Yes, Derar is correct on this. The %item($list,3) should be returning null in all of his test cases. So the two cases that output "4" show the bug where null isn't being returned somehow.
Not sure what's causing the problem, but it's definitely a bug and I've added it to the bug list. Thanks for the clear procedure for reproducing this weird one! |
|
|
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|