[sf-perl] Some well-formed XML?

Garth Webb garth at perijove.com
Thu Sep 22 09:13:59 PDT 2005


Why not use an empty element for NULL values?

  <ColumnA>stuff</ColumnA><ColumnB /><ColumnC>stuff</ColumnC>

Garth

On Thu, 2005-09-22 at 08:38 -0700, Andrew Sigmund wrote:
> Every value for every NULLable column consists of two parts: A flag
> indicating whether or not a value is present, and the value itself.
> Although this seems like overkill when you actually have values (if you
> have a value, then it's obviously there (not NULL)), it is just the
> thing for distinguishing between absent values (NULLs) and "empty"
> strings.
> 
> 
> Alternatively, I suppose you could simply not include anything about the
> column in rows in which the value is null.
> 
> Example:
> ColumnB is not null and not empty:
> <ColumnA>123</ColumnA><ColumnB>MyString</ColumnB><ColumnC>456</ColumnC>
> 
> ColumnB is not null, but is an empty string:
> <ColumnA>123</ColumnA><ColumnB></ColumnB><ColumnC>456</ColumnC>
> 
> ColumnB is null:
> <ColumnA>123</ColumnA><ColumnC>456</ColumnC>
> 
> -----Original Message-----
> From: sanfrancisco-pm-bounces at pm.org
> [mailto:sanfrancisco-pm-bounces at pm.org] On Behalf Of Joseph Brenner
> Sent: Tuesday, September 20, 2005 15:57
> To: San Francisco Perl Mongers User Group
> Subject: Re: [sf-perl] Some well-formed XML?
> 
> 
> Andrew Sigmund <ASIGMUND at altera.com> wrote:
> 
> > Joseph Brenner wrote: 
> > > 
> > > Rich Morin <rdm at cfcl.com> wrote:
> > > 
> > > >      So, it's fairly straightforward to serialize a set of RDBMS
> > > >      tables as XML and load them back into another database.  The
> > > >      rules for the (de-)serialization, however, will probably be
> > > >      hard-coded into your dumping and loading code.
> > > 
> > > Funny, I was just in the process of doing just this sort of thing.
> > > 
> > > In particular I'm noodling around how to preserve NULLs. 
> > > 
> > > NULLs can be mapped to undefs in perl, which usually get mapped to
> > > empty strings when written to some text format, but then that leaves
> > > you with no way to distinguish between those and fields that started
> > > out as empty (but non-NULL) VARCHARs.
> > > 
> > > So, you hack in code to translate the NULL/undefs to a string
> "NULL"? 
> > > Perhaps with additional hackery to preserve any odd ball strings 
> > > containing "NULL" to start with? 
> 
> > It might help to think of NULLs as the DBMS thinks of them, that is,
> not
> > as values themselves, but as the absence of a value in a column that
> > doesn't require a value.  NULLability is an attribute of the column,
> and
> > a column of any data-type (VARCHAR, INT, DATETIME, etc.) may have this
> > attribute, and therefore not have a value, that is, "have a NULL
> value".
> 
> But how exactly does that help?  My problem is convincing the filesystem
> 
> to think of them the same way the DB does.
> 
> What I want to do is to perfectly preserve some table state by dumping
> the contents to files.  I want to be able to run tests on some existing
> code, then reset the tables the code uses to a known state, and then
> re-run the tests.
> 
> My presumption is that somewhere in the code something may care that 
> a field is NULL rather than empty: that's why I'm worrying about 
> preserving NULLs.
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm
> 
> 
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm



More information about the SanFrancisco-pm mailing list