Author |
Message
|
MikeOliverAZ |
Posted: Sun Nov 24, 2013 8:53 pm Post subject: Is this the fastest way to check a value and set default? |
|
|
 Apprentice
Joined: 10 Jul 2013 Posts: 47
|
I have a compute node that I need to check an incoming message for a value and if it doesn't exist, to set a default value.
Here is the ESQL?
Code: |
DECLARE iAtomicServiceQ REFERENCE TO OutputRoot.XMLNSC.doc:UDTO.doc:MessageVariables.doc:AtomicServiceQ;
IF LASTMOVE(iAtomicServiceQ) = FALSE THEN
SET OutputRoot.XMLNSC.doc:UDTO.doc:MessageVariables.doc:AtomicServiceQ = 'DEFAULT';
END IF;
|
This seems like a heavy cost, but I can't find a better way.
MO |
|
Back to top |
|
 |
Simbu |
Posted: Sun Nov 24, 2013 10:40 pm Post subject: Re: Is this the fastest way to check a value and set default |
|
|
 Master
Joined: 17 Jun 2011 Posts: 289 Location: Tamil Nadu, India
|
MikeOliverAZ wrote: |
I have a compute node that I need to check an incoming message for a value and if it doesn't exist, to set a default value.
|
Your code says that you are checking the output message(not an incoming message for a value!)
MikeOliverAZ wrote: |
Code: |
DECLARE iAtomicServiceQ REFERENCE TO OutputRoot.XMLNSC.doc:UDTO.doc:MessageVariables.doc:AtomicServiceQ;
IF LASTMOVE(iAtomicServiceQ) = FALSE THEN
SET OutputRoot.XMLNSC.doc:UDTO.doc:MessageVariables.doc:AtomicServiceQ = 'DEFAULT';
END IF;
|
|
Also you are check for the existence of the tree structure "OutputRoot.XMLNSC.doc:UDTO.doc:MessageVariables.doc:AtomicServiceQ" but not the value of the field "doc:AtomicServiceQ".
Please make your requirement clear. |
|
Back to top |
|
 |
Esa |
Posted: Sun Nov 24, 2013 10:50 pm Post subject: |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
Quote: |
Post subject: Is this the fastest way to check a value and set default? |
Fastest do develop or fastest performing in runtime? These two can be totally different.
I would say that fastest method in runtime is not to copy the whole InputRoot into OutputRoot and then try to inject the default values for the missing fields.
A faster way is to make your code copy the message recursively with one input reference and one output reference and add the default values for mandatory fields as you go. Then you can simplify the code with COALESCE function, too. That way it's also easier to ensure that the injected default values end up in the correct place, if it matters. Your example code will always create the default value in a field that is the LASTCHILD of the parent. If you had a more complicated message with reoccurring structures, your example code would probably totally mess up the structure. |
|
Back to top |
|
 |
MikeOliverAZ |
Posted: Mon Nov 25, 2013 5:04 pm Post subject: Re: Is this the fastest way to check a value and set default |
|
|
 Apprentice
Joined: 10 Jul 2013 Posts: 47
|
Simbu wrote: |
MikeOliverAZ wrote: |
I have a compute node that I need to check an incoming message for a value and if it doesn't exist, to set a default value.
|
Your code says that you are checking the output message(not an incoming message for a value!)
Also you are check for the existence of the tree structure "OutputRoot.XMLNSC.doc:UDTO.doc:MessageVariables.doc:AtomicServiceQ" but not the value of the field "doc:AtomicServiceQ".
Please make your requirement clear. |
If the structure of the output does not include the element, create it and set a default value. If it exists, then whatever the value is doesn't matter. |
|
Back to top |
|
 |
MikeOliverAZ |
Posted: Mon Nov 25, 2013 5:11 pm Post subject: fastest runtime |
|
|
 Apprentice
Joined: 10 Jul 2013 Posts: 47
|
Esa wrote: |
Quote: |
Post subject: Is this the fastest way to check a value and set default? |
Fastest do develop or fastest performing in runtime? These two can be totally different.
I would say that fastest method in runtime is not to copy the whole InputRoot into OutputRoot and then try to inject the default values for the missing fields.
A faster way is to make your code copy the message recursively with one input reference and one output reference and add the default values for mandatory fields as you go. Then you can simplify the code with COALESCE function, too. That way it's also easier to ensure that the injected default values end up in the correct place, if it matters. Your example code will always create the default value in a field that is the LASTCHILD of the parent. If you had a more complicated message with reoccurring structures, your example code would probably totally mess up the structure. |
Thanks, but in our case the structure is a high level schema with 5 required elements with "any" inside each. The only structure we enforce is a name/value pair content under the doc:MessageVariables with required elements there. Walking the tree is slower as the other elements may have many children we don't really care about at this stage, so testing each one has a cost.
I assume then that this technique is otherwise as good as any others for a specific location in a structured message. |
|
Back to top |
|
 |
Simbu |
Posted: Mon Nov 25, 2013 8:59 pm Post subject: |
|
|
 Master
Joined: 17 Jun 2011 Posts: 289 Location: Tamil Nadu, India
|
MikeOliverAZ, have you tried to simplify your code with COALESCE function as Esa suggested?
This is the better approach(1 line) than you code(4 lines) to achieve your result. |
|
Back to top |
|
 |
Esa |
Posted: Mon Nov 25, 2013 10:42 pm Post subject: Re: Is this the fastest way to check a value and set default |
|
|
 Grand Master
Joined: 22 May 2008 Posts: 1387 Location: Finland
|
MikeOliverAZ wrote: |
The only structure we enforce is a name/value pair content under the doc:MessageVariables with required elements there. |
OK.
In general you can make any code perform better by using references, but only if you use them correctly. The idea is to keep the paths as short as possible, like this:
Code: |
DECLARE refMV REFERENCE TO OutputRoot.XMLNSC.doc:UDTO.doc:MessageVariables;
SET refMV.doc:AtomicServiceQ = COALESCE(refMV.doc:AtomicServiceQ,'DEFAULT');
SET refMV.doc:SomeOtherVariable = COALESCE(refMV.doc:SomeOtherVariable,'DEFAULT');
-- etc
|
I left the LASTMOVE test out because I supposed doc:MessageVariables is always present. That may not always be the case, though. At least if wrong messages start getting routed to your flow, which is why you should always have at least one test to verify that the message is of correct type. |
|
Back to top |
|
 |
|