ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Altering InputRoot fields indirectly via REFERENCE

Post new topic  Reply to topic
 Altering InputRoot fields indirectly via REFERENCE « View previous topic :: View next topic » 
Author Message
Sandman
PostPosted: Tue Mar 08, 2011 8:03 am    Post subject: Altering InputRoot fields indirectly via REFERENCE Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Tue Mar 08, 2011 8:45 am    Post subject: Reply with quote

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
View user's profile Send private message
Sandman
PostPosted: Tue Mar 08, 2011 8:48 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Tue Mar 08, 2011 8:55 am    Post subject: Reply with quote

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
View user's profile Send private message
Sandman
PostPosted: Tue Mar 08, 2011 9:02 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Tue Mar 08, 2011 9:14 am    Post subject: Reply with quote

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
View user's profile Send private message
Sandman
PostPosted: Tue Mar 08, 2011 9:20 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail
mqjeff
PostPosted: Tue Mar 08, 2011 9:37 am    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Altering InputRoot fields indirectly via REFERENCE
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.