| Author |
Message
|
| lokeshraghuram |
 Posted: Wed Feb 05, 2014 2:18 am Post subject: Delete repeating childs of a parent |
 |
|
Novice
Joined: 10 Dec 2013
Posts: 14
|
Hello,
Is it possible to delete all the repeating child of a parent using one DELETE statement. For example consider the parent tag as Person and the repeating childs are Tasks.
Note : Parent tag will have fields other than the repeating childs and those should not be deleted
Sample file
<Person>
<Name>ABC</Name>
<Age>10</Age>
<Task>
<Time>1</Time>
<Place>A</Place>
<Task>
<Task>
<Time>2</Time>
<Place>B</Place>
<Task>
<Task>
<Time>3</Time>
<Place>C</Place>
<Task>
</Person>
After the delete statement output should be in the below format
<Person>
<Name>ABC</Name>
<Age>10</Age>
</Person>
Please suggest the possibilities |
|
| Back to top |
|
 |
| dogorsy |
| Posted: Wed Feb 05, 2014 2:43 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
try delete field ....task[*] and see if it gives you the desired result
and, never done it, (probably not supported), but try:
| Code: |
delete from InputRoot.XMLNSC.blah.blah AS A WHERE FIELDNAME(A) = 'Task'; |
Good one for mgk if it does not work !
Please let us know if any of these options work.
Well, looking at the DELETE FROM syntax, it is not possible to delete from a message.... but you can always do a
| Code: |
| SELECT FROM message where fieldname(a) <> 'Task'; |
and that will copy only the fields you want |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 05, 2014 5:28 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If I may, you need to change your design
You should have
| Code: |
<person>
<name>abc</name>
<age>30</age>
<tasklist>
<task occurs= "0 to n">
<time>1</time>
<place>A</place>
</task>
</tasklist>
</person> |
This way you'd just wipe out the tasklist...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| dogorsy |
| Posted: Wed Feb 05, 2014 5:36 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| fjb_saper wrote: |
If I may, you need to change your design
You should have
| Code: |
<person>
<name>abc</name>
<age>30</age>
<tasklist>
<task occurs= "0 to n">
<time>1</time>
<place>A</place>
</task>
</tasklist>
</person> |
This way you'd just wipe out the tasklist...
Have fun |
Yes, If the OP was in control of the input message then why build the tasklist at all when not needed ?! |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 05, 2014 6:15 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| dogorsy wrote: |
Yes, If the OP was in control of the input message then why build the tasklist at all when not needed ?! |
Because it optimizes the "add task" process on the business object by providing an existing anchor on the business object.
Otherwise, for each invocation of the addTask method you would need to check for the taskList's existence and create it if missing...
It also avoids having to "sift" through the object to find a specific task. Now all you need to do is search in the task list...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 05, 2014 6:17 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You shouldn't ship business objects across the wire.
You should send messages.
Messages should include the necessary information for them to be processed by the receiver, regardless of whether they know anything about any of the business objects that the data may have come from.
Or, why CORBA is still a bad idea. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 05, 2014 6:21 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
You shouldn't ship business objects across the wire.
You should send messages.
Messages should include the necessary information for them to be processed by the receiver, regardless of whether they know anything about any of the business objects that the data may have come from.
Or, why CORBA is still a bad idea. |
Sure but isn't your business object design going to influence the way you build your XML representation of the BO, of for that matter the content of your message?
Better design all around will make processing tasks easier all around...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 05, 2014 6:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| mqjeff wrote: |
You shouldn't ship business objects across the wire.
You should send messages.
Messages should include the necessary information for them to be processed by the receiver, regardless of whether they know anything about any of the business objects that the data may have come from.
Or, why CORBA is still a bad idea. |
Sure but isn't your business object design going to influence the way you build your XML representation of the BO, of for that matter the content of your message?
Better design all around will make processing tasks easier all around... |
No. The business object model should be entirely separate.
The message should be structured and designed based on what is necessary to process the data in it. Start and end of story. It's a message. This extends to Web Services. Each operation is associated with one or more messages. They should be designed as MESSAGES, not as Business Objects.
Business objects are usually much too complicated to be easily processed. What's worse is when they are highly normalized. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Wed Feb 05, 2014 6:42 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| fjb_saper wrote: |
| dogorsy wrote: |
Yes, If the OP was in control of the input message then why build the tasklist at all when not needed ?! |
Because it optimizes the "add task" process on the business object by providing an existing anchor on the business object.
Otherwise, for each invocation of the addTask method you would need to check for the taskList's existence and create it if missing...
It also avoids having to "sift" through the object to find a specific task. Now all you need to do is search in the task list...
|
you still have not explained why build the tasklist to then delete it.
Anyway, the OP asked an interesting question, you have not provided anything helpful to solve the problem. Of course, changing the inputs changes the problem, but that is not has been asked, and the question being asked is very relevant and could happen in many situations.
It seems to me you were suggesting to build a tasklist to make it easier to delete it in the broker. Great advice !!!.... |
|
| Back to top |
|
|
| lokeshraghuram |
| Posted: Fri Feb 07, 2014 11:05 am Post subject: |
|
|
Novice
Joined: 10 Dec 2013
Posts: 14
|
Thanks guys for your suggestions..I have thought of this 'tasklist' solution but that changes the XML structure which is completely wrong
DELETE FROM is working only for database queries or infact ROW variables and not for Message Tree..Looks like there is no such option is esql
Thank you everyone  |
|
| Back to top |
|
|
| Gralgrathor |
| Posted: Mon Feb 10, 2014 2:44 am Post subject: |
|
|
Master
Joined: 23 Jul 2009
Posts: 297
|
| Indeed, odd that such a construction is not possible in ESQL. One might of course write a utility function "deleteRepeatingElements(IN firstElement REFERENCE)" to do this, but it'd still contain a loop of some kind. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Mon Feb 10, 2014 2:51 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| Gralgrathor wrote: |
| Indeed, odd that such a construction is not possible in ESQL. One might of course write a utility function "deleteRepeatingElements(IN firstElement REFERENCE)" to do this, but it'd still contain a loop of some kind. |
Yes there is, and I have already said that: use a SELECT statement. |
|
| Back to top |
|
|
| Gralgrathor |
| Posted: Mon Feb 10, 2014 2:56 am Post subject: |
|
|
Master
Joined: 23 Jul 2009
Posts: 297
|
[quote="dogorsy"]
| Gralgrathor wrote: |
| Yes there is, and I have already said that: use a SELECT statement. |
Not always a convenient option. Consider a complex structure that is copied almost entirely from input to output, except for a particular recurring element.
The easiest would be to CopyEntireMessage and then delete the offending list in a single statement. But since this option doesn't exist, one now has to either build up the complex structure in the Output while omitting the list, or CopyEntireMessage and then loop-delete while offending elements remain.
It's no biggie. I just think it's odd that the option to DELETE recurring elements doesn't exist. |
|
| Back to top |
|
|
| dogorsy |
| Posted: Mon Feb 10, 2014 2:58 am Post subject: |
|
|
Knight
Joined: 13 Mar 2013
Posts: 553
Location: Home Office
|
| Gralgrathor wrote: |
| dogorsy wrote: |
| Gralgrathor wrote: |
| Yes there is, and I have already said that: use a SELECT statement. |
Not always a convenient option. |
|
Yes, it is a convenient option. A lot more convenient than your proposal of writing a function and loop through all the elements.
| Gralgrathor wrote: |
The easiest would be to CopyEntireMessage and then delete the offending list in a single statement
|
Easiest does not mean BEST |
|
| Back to top |
|
|
| Gralgrathor |
| Posted: Mon Feb 10, 2014 3:07 am Post subject: |
|
|
Master
Joined: 23 Jul 2009
Posts: 297
|
| dogorsy wrote: |
| Yes, it is a convenient option. |
No, it's not. It requires building up a complex structure layer by layer. In stead of a subtree-copy action and a delete, you'd get any number of copy actions, depending on the depth of the first offending element. Even a looped-delete would be better.
| dogorsy wrote: |
| Easiest does not mean BEST |
Yes, it does. Easiest usually means the code is optimized at machine level, which increases performance. |
|
| Back to top |
|
|
|
|
