[sf-perl] Some well-formed XML?
doom at kzsu.stanford.edu
Tue Sep 20 15:56:55 PDT 2005
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
More information about the SanFrancisco-pm