| Author |
Message
|
| Sandman |
 Posted: Tue Mar 08, 2011 8:03 am Post subject: Altering InputRoot fields indirectly via REFERENCE |
 |
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Why is it that you can't even compile ESQL with a SET statement that attempts to directly alter the InputRoot, but it works fine if you do an "end around" via referencing???
For example, given this input message:
| Code: |
<?xml version="1.0" encoding="UTF-8"?>
<Message><x>1</x></Message> |
This statement:
| Code: |
| SET InputRoot.Message.x = ''; |
... calls this compilation error:
| Quote: |
| Input correlation name "InputRoot" cannot be changed. |
But this code updates it just fine:
| Code: |
DECLARE messageRef REFERENCE TO InputRoot.XMLNSC.Message;
SET messageRef.x = ''; |
|
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Mar 08, 2011 8:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Because InputRoot can't be changed!
Unless you misuse features of ESQL references to allow you to alter what is designed and documented as an immutable tree.
Why are you *trying* to change InputRoot? You shouldn't! |
|
| Back to top |
|
|
| Sandman |
| Posted: Tue Mar 08, 2011 8:48 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
I'M actually not trying to do this; it's in some of our production code though (and working fine  ). I just was concerned if perhaps it's a bug and might be fixed in a later release, breaking our code.
Or if not a "bug", is it just that the compiler can't know where our references might point at runtime, so it can't call a compile error. But why does this work at runtime? Under the hood, doesn't the broker realize that the InputRoot is being modified (indirectly)? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 08, 2011 8:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Sandman wrote: |
I'M actually not trying to do this; it's in some of our production code though (and working fine ). I just was concerned if perhaps it's a bug and might be fixed in a later release, breaking our code.
Or if not a "bug", is it just that the compiler can't know where our references might point at runtime, so it can't call a compile error. But why does this work at runtime? Under the hood, doesn't the broker realize that the InputRoot is being modified (indirectly)? |
There's some old discussion by mgk on this...
But yes, the Toolkit can't guarantee that a reference points anywhere in particular, so it can't throw a compiler error at development time. Some extra effort could be made either at development or deploy time to discover this - but it would be at the expense of performance either during development or deployment.
And under the hood, a Reference just points to a CciElement, and it's only the parent CciElement of InputRoot that is immutable, technically.
Whoever wrote the code you have in production should be forced to defend it in front of a code review board. |
|
| Back to top |
|
|
| Sandman |
| Posted: Tue Mar 08, 2011 9:02 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
Might be a quick defense trial...
"Uh, your honor... it's been working in production for several years. The broker calls all kinds of other deployment and runtime errors; why not this one?" |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 08, 2011 9:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Right. But as you said, it's not *documented* to work this way, and it *might* break at any change.
So, again, "working for several years" is not the same thing as "reliable" or "should be done".
Past performance is no guarantee of future success...
In general, any deviation from the normal way of doing things requires some justification. What is the purpose of modifying InputRoot in this code? Is it to avoid doing expensive tree copies? Is it to use a Filter node to do Transformation? |
|
| Back to top |
|
|
| Sandman |
| Posted: Tue Mar 08, 2011 9:20 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2001
Posts: 134
Location: Lincoln, RI
|
| No, I don't think either of those reasons apply here. The Compute node is already copying most of the input tree because shortly after it modifies the InputRoot, it creates an OutputRoot, then SETs it = to a child of the InputRoot (which happens to contain the data that was already altered via the InputRoot reference). |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Mar 08, 2011 9:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So it's changing InputRoot, and then changing OutputRoot and then copying InputRoot into a subtree of OutputRoot?
That's even less efficient than doing a straightforward map of the necessary changes to InputRoot as you copy them to OutputRoot.
This is just bad code. |
|
| Back to top |
|
|
|
|
