Empty string in MV for XML projections

[Jason Warner]

Due to the way that Cache projects XML, we have the need to put an empty
string into a property so that the XML will project like:

<tag></tag>

instead of

<tag xsi:nil="true" />

The problem I'm having is that setting the class like so:

class->Property = ""

actually sets the property to null which causes the second tag. So, all
you MV geniuses out there, how can I set the property to an empty string
to get the first projection?

Jason

[Ed Clark]

Just a guess: If it's consistent with SQL then setting it to an empty string sets it to NULL (as you see) but setting it to char(0) sets it to empty. The obvious downside to that is that you now have char(0) in your mv data instead of an empty string, but the projection should come out as you want it.

> --
> You received this message because you are subscribed to the Google Groups "InterSystems: MV Community" group.
> To post to this group, send email to Cac...@googlegroups.com
> To unsubscribe from this group, send email to CacheMV-u...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/CacheMV?hl=en

[Emily Haggstrom]

Hi Jason,

There's a class parameter XMLIGNORENULL which, if set to 1, will cause the XML generator to export whatever's in the properties, even if they're null. Try that, it should get you the output you're looking for.

Parameter XMLIGNORENULL = 1;

Regards,
Emily

[Jason Warner]

Emily,

That is correct, but the problem is that I need properties in the same
class to have either empty tags or xsi:nil="true" in them. This is the
frustration we are dealing with. You can either have empty tags or
xsi:nil tags, but not both.

Jason

[Jason Warner]

Ed,

This works. If you set your property to char(0), then it will project as
empty tags. Thank you.

Jason

[Ed Clark]

what are you going to do about the unexpected char(0) in your data though?

[Jason Warner]

This is only used in a class used to transport our data for a web
service. We don't actually store the char(0) anywhere it will matter.
If we had to store it, then this wouldn't work either. I've asked for
an enhancement to allow us to have both xsi:nil and empty tags in the
same class. Until that happens, this will work.

[Dawn Wolthuis]

I am not going to think hard enough to figure out if this is relevant,
but I sure would like our MV empty values to be treated like actual
values by SQL so that we can stick with 2-valued-logic. We have
already had issues with null-handling in SQL. It seems such a shame
for MV developers to start working with 3VL in 2012, at a point where
almost everyone agrees that 3VL is highly developer-error prone. For
this reason alone, I would like to back Zen components with CMQL at
times so that when a developers knows how to get the collection with
CMQL they do not have SQL nulls to contend with. If both XML and SQL
treated MV empty as if it were char(0), perhaps as a setting, that
might solve a bunch of issues (or perhaps I'm really not catching on
as I have turned my brain off for the dinner hour). cheers! --dawn

Dawn M. Wolthuis

Take and give some delight today

[Jason Warner]

Dawn,

I am a transplant to the MV world, so I actually like 3VL. With that
disclosure, I would argue against changing MV's "" to char(0) in SQL.
The problem is that null and an empty string are really two different
things. There are places in my code that rely on that fact. Granted,
most of my code is not pure MV, but a mixture of object code and MV so
this doesn't hurt us, but removing the distinction would break some of
my code.

In your example above, changing MV's "" to char(0) would make it
impossible to output my xsi:nil="true" tags since there would no longer
be a way to tell XML that this field was null. This would again break
the XML DTD and cause more hair-pulling.

Jason

[Dawn Wolthuis]

OK, you have unleashed me (yup, it is all your fault, Jason), but I
just realized I can point to something I wrote a while back and then
just supplement it by saying that the reason "" and null are different
is because someone decided to make them so. Different flavors of MV
handle things differently, but I wrote the following to explain how ""
can be a value and we can skip having a SQL-type null in data
altogether. That is one of the reasons I want to use MV, so it is
distressing when we find a bug in a query related to SQL nulls WHEN WE
ARE NOT PLACING ANY in our data. We are just trying to put the empty
set there. Almost everything is simplified by working with "" to be a
value that is a "null set" rather than treating it as an SQL-type
null.

http://www.tincat-group.com/mewsings/2006/03/better-to-have-no-values.html

Whew, we got away with relatively few words in this response. smiles. --dawn