Hi *,
I have a document with some fields lets say doc with doc/Field
I fill the field from the database and the Field can be NULL.
Than I convert the document with the NULL-Field to XMLString with “documentToXMLString” and I save the xmlstring to a database. When I get back the xmlstring to a document with:
xmlStringToXMLNode and xmlNodeToDocument I get a different document.
doc/Field is not NULL but doc/Field is empty.
How can I solve this problem that I can get back the same document.
Hello,
Do you need the field to exist as null in the node if you pull it as null from the initial source database. What is the real real ramification of having anything blank or null to mean the same thing? I was also wondering, is the field not null as soon as you pull it back out of the database and into the xmlstring or only when you pass xmlstring to xmlStringToXMLNode or at the final step when you do xmlNodeToDocument? You may just need to use a slightly different parsing technique if it only happens at the last step.
Hi,
thank you for your reply.
My Goal is to store documents into a database in order to restart them later.
So I want to convert a document to an xmlstring, store taht xmlstring into a database and later I weant to recover that xmlstring into a document and publish that document.
But the documents are not equal. Fields that contain NULL-Values in the document(, because thy were NULL in a source-database) become empty-Fields in the document, when I recover the xmlstring.
My problem is, that in futher coding I have BRANCHES where I ask if a documents field != $null , that BRANCH does not work any more if the field is in the document but is empty.
Hello,
I don’t use XML so your situation somewhat puzzles me.
if you don’t save the XML string to the database and instead directly encode and /decode it, do you get exactly what you want?
Are you saying that you are writing a simple text string to a database field and when you pull it back later to contents have been modified by the database manager?
Have you tried to do other encoding like storing the string as base64 after making it an XML string or packing it as binary?
Knowing this stuff may help me understand the situation better and help you look at possible alternatives.
Good day.
Hi,
thanks for your reply.
My problem does not belong to the database and not to encoding.
My problem is, that the document looks like this:
doc/FieldA=‘anyString’
doc/FieldB=*null
doc/FieldC=‘anyString’
When I convert the doc to xmlstring and back to document I get a document like this
doc/FieldA=‘anyString’
doc/FieldB=‘’
doc/FieldC=‘anyString’
where doc/FieldB is an empty Field but not $null
To me, this seems pretty normal. Indeed, let’s consider on the two sides (xml and wM document) what the possibilities are :
In webMethods, a string field in a document can be :
not present
present and null
present and empty
present and not null and not empty
which makes 4 different cases.
On the xml side, a string field can be :
not present
present and empty
present and not empty
which makes 3 different cases.
So for sure, documentToXML and XMLToDocument can not be exactly reverse.
I guess webMethods made the choice to say that :
present and null in wM -> present and empty in XML
present and empty in wM -> present and empty in XML
and on the other way round
present and empty in XML -> present and empty in wM
which explains what you have as a behavior.
Sorry, but I think even theoritically, there is no solution to your problem
Hello,
Cedric made the most excellent eval. So Ralf, if you look at the required data for that field, you may be able to put a magic null there. Something like a value of ‘null’ which would never occur. Then you replace all real nulls with this string and save the encoding. On the reverse, when you retrieve the data, you can make a quick first scan and reverse the operation by find ‘null’ with a null string. Remember I gave an EXAMPLE magic string to use, you may find others more appropriate.
The end of this is that it is a work around and a way of practically over coming the hurdle.
Hi all,
tahnk you for your help. The explanation of Cedric is very clear to me now.
Do you have an alorithm to walk through a complex document in order to find out a *null value ?
Because I have deep tree-like documenst with about 100-fields and any of the field can be NULL.
The best way to do this is probably a Java function in which you create an IDataCursor and make that move over every element in the IData object.
public void handleNullValues (IData myIData){
//move to the first entry in the record
cur.first();
while(cur.hasMoreData()){
Object obj = cur.getValue();
if(obj == null){
//handle null objects here
}
else{
if(obj instanceof com.wm.data.IData){
//recursive
handleNullValues((IData)obj);
}
}
//go to next element in document
cur.next();
}
//we have not handled the last element yet
Object obj = cur.getValue();
if(obj == null){
//handle null objects here
}
else{
if(obj instanceof com.wm.data.IData){
//recursive
handleNullValues((IData)obj);
}
}
}
Well, you could do it just a bit easier than Koen’s way.
Here it is :
public void handleNullValues (IData myIData){
//move to the first entry in the record
cur.first();
do {
Object obj = cur.getValue();
if(obj == null){
//handle null objects here
}
else{
if(obj instanceof com.wm.data.IData){
//recursive
handleNullValues((IData)obj);
}
}
} while (cur.next()); //go to next element in document
That way you do not need anything special for the last element.
Best regards,
There is a source code example in WmSamples, walkAnIData method, hidden in sample.idata folder shared code section. It handles DocumentLists (IData) and some other types that are not IData, but can be converted to IData, which may not be interesting in your case.
