| Author |
Message
|
| MatthewDCampbell |
 Posted: Thu May 20, 2021 11:25 pm Post subject: Order members in message tree (OutputRoot) |
 |
|
Novice
Joined: 29 Sep 2020
Posts: 21
|
The documentation is explicit on the serialization of JSON from the message tree:
| Quote: |
| JSON objects are modeled in the integration node message tree as a sequence of NameValue elements. The parser builds the message tree in the order in which it encounters the members in the bit stream. The serializer writes the object members into the bit stream in the tree order. |
What I would like to find in the documentation (i.e. documentation == guarantee of expected behavior) is how the order of members in message tree is established if at all. For example, if one defines:
| Code: |
OutputRoot.JSON.Data.Element1 = 'gary'
OutputRoot.JSON.Data.Element2 = 'mo'
|
then the resulting logical message tree is always:
| Code: |
(Object): JSON = ( ['json' :
(Object): Data = (
(NameValue): Element1 = 'gary' (CHARACTER)
(NameValue): Element2 = 'mo' (CHARACTER)
)
)
|
i.e. Element2 is never positioned before Element1 which implies that the code operations (set) determine the tree element order. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri May 21, 2021 1:17 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The documentation is right.
However there is no limit to you manipulating the message tree, think of create as last/first child, next / previous sibling etc...
So the order of creation of the element does not guarantee the order of placement in the tree. The tree will be what it is at serialization after you are done manipulating it... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| timber |
| Posted: Fri May 21, 2021 1:39 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
As fjb_saper correctly pointed out, SET statements are not the only way to populate OutputRoot (or any other message tree).
If you need to control the sequence of elements, restricting yourself to using SET statements can force you into unnatural contortions. That's why the CREATE statement exists (with its AS clause). |
|
| Back to top |
|
|
| MatthewDCampbell |
| Posted: Fri May 21, 2021 3:32 am Post subject: |
|
|
Novice
Joined: 29 Sep 2020
Posts: 21
|
Then one ought to be able to regard the CREATE [url href="https://www.ibm.com/docs/en/integration-bus/9.0.0?topic=statements-create-statement"]documentation[/url] as a guarantee of field placement as is stated:
| Quote: |
| A CREATE statement with one of these clauses always creates a new field, and places it in the specified position. |
Using a set of CREATE statements to generate a message tree those operations should be idempotent.
Thanks @timber + @fjb_saper for feedback. |
|
| Back to top |
|
|
| timber |
| Posted: Fri May 21, 2021 4:56 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
| Quote: |
| Using a set of CREATE statements to generate a message tree those operations should be idempotent. |
I'm being picky here, but I disagree. Idempotent means 'can be repeated without changing the result'. A sequence of CREATE statements is not idempotent because every CREATE statement will add a new node into the message tree. |
|
| Back to top |
|
|
| MatthewDCampbell |
| Posted: Fri May 21, 2021 5:31 am Post subject: |
|
|
Novice
Joined: 29 Sep 2020
Posts: 21
|
| Quote: |
| Using a set of CREATE statements to generate a message tree those operations should be idempotent. |
i.e. the ordered set of CREATE statements should always generated the exact same tree structure. The nodes may have different object identifications but the overall structure should be idempotent (as in the sense of making a deep clone).[/quote] |
|
| Back to top |
|
|
| timber |
| Posted: Fri May 21, 2021 6:14 am Post subject: |
|
|
Grand Master
Joined: 25 Aug 2015
Posts: 1292
|
Agreed. An ordered sequence of CREATE statements will always generate the same message tree.
The same is true for an ordered sequence of SET statements, if you start with the same message tree every time. SET does not produce a randomly-ordered tree. SET performs an UPSERT - if the path already exists then the value is modified, else a new node is added at the end of the path. |
|
| Back to top |
|
|
| rekarm01 |
| Posted: Fri May 21, 2021 3:07 pm Post subject: Re: Order members in message tree (OutputRoot) |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 1415
|
| MatthewDCampbell wrote: |
| What I would like to find in the documentation (i.e. documentation == guarantee of expected behavior) is how the order of members in message tree is established if at all. |
The CREATE statement has qualifiers (CREATE ... OF...), to specify where to put a new field, relative to an existing location.
Otherwise, the documentation does not state precisely where either the CREATE or SET statement puts any new fields, relative to any existing siblings. This also includes any intermediate fields they create along the way, when navigating to the target field. In those cases, it looks like:
- if any siblings with the same name already exist, then the new field is placed as the next sibling of the last field with the same name
- otherwise, the new field is placed as the last child of its parent field
For any further clarification, consult with IBM.
| MatthewDCampbell wrote: |
| Using a set of CREATE statements to generate a message tree those operations should be idempotent. |
SET/CREATE statements are deterministic, in that their behavior is predictable. |
|
| Back to top |
|
|
|
|
