XML Pack 2 bug

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
mchaves
Participant
Posts: 50
Joined: Mon Aug 08, 2005 9:59 pm
Location: Sydney
Contact:

XML Pack 2 bug

Post by mchaves »

Hi Folks,

We are encontering a problem with xml files that contain nested records (repeating groups). Datastage is pretty much fabricating data for fields that don't appear accross all the records of a repeating group.

For example, the file below contains 2 addresses for the customer 55000. The second address doesn't contain the zip attribute, so if you process this file using the XML input stage in order to extract the 2 addresses (key=address id) into a sequencial file, you will end up with 2 records, and the second record will have the zip attribute added and the content will be the same as the last one's. I would've expected to see the attribute created with null, but that's not the case. Interestingly, we have datastage v6.0 here with xml pack1.0, and it works ok, I mean the attribute gets created with null content. Not sure if this issue wast introduced by xml pack 2 or by datastage 8.5.

Any thoughts?


<?xml version="1.0"?>
<customers>
<customer id="55000">
<name>Charter Group</name>
<address id="1">
<street>100 Main</street>
<city>Framingham</city>
<state>MA</state>
<zip>01701</zip>
</address>
<address id="2">
<street>720 Prospect</street>
<city>Framingham</city>
<state>MA</state>
<zip>01701</zip>
</address>
<address>
<street>120 Ridge</street>
<state>MA</state>
</address>
</customer>
</customers>
A bad fishing day is much better than a great day at work
ray.wurlod
Participant
Posts: 54607
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

Is "nil" support defined the same way in both environments?
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
eostic
Premium Member
Premium Member
Posts: 3838
Joined: Mon Oct 17, 2005 9:34 am

Post by eostic »

hard to say, but indeed, normal behavior for this would be for you to receive nulls for elements that don't exist in that lower node....

...but carefully check which column on the output link has your "repeating element" (key = yes). That may have sometihng to do with it. It should be one of the address elements that you expect will always exist....

Ernie
Ernie Ostic

blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
mchaves
Participant
Posts: 50
Joined: Mon Aug 08, 2005 9:59 pm
Location: Sydney
Contact:

Post by mchaves »

Hi Ernie,

The address id is set as the key for the repeating group. The issue is not with the repeating group, it's with the absence of attributes. In ds 6.0, it worked fine, absent attributes are created with null content, in version 8.5 columns are created too and random values put in them. We raised the issue to IBM support but they don't have a clue either.
A bad fishing day is much better than a great day at work
eostic
Premium Member
Premium Member
Posts: 3838
Joined: Mon Oct 17, 2005 9:34 am

Post by eostic »

I haven't seen this fail, so my suggestion would be, using your tiny document sample, to play with some possibilities:

a) move the repeating element. right now you have it on an attribute....usually that works, but who knows. Make it "street" and see if/how the behavior changes for the missing zip.

b) add another column, for the "whole" address. (have the xpath just end at .../address/ ....make that the key. See if/how the behavior changes.

c) using your test document, add a containing element that surrounds addresses (something like <all_addresses> and </all_addresses>. See if/how the behavior changes.

Ernie
Ernie Ostic

blogit!
<a href="https://dsrealtime.wordpress.com/2015/0 ... ere/">Open IGC is Here!</a>
Post Reply