Re: XML for databases?!?! Is it just me or is the rest of the world nutz?

[Dr. Mu]

in reply to XML for databases?!?! Is it just me or is the rest of the world nutz?

My own timid excursion into XML was made for two reasons:

1. Tied hashes between two systems (e.g. my hosted website and my local mirror) can be incompatible, depending on the db engines employed.
2. Tied hashes normally encompass only one level. Hashes containing arrays and other hashes can be cumbersome to implement.

What I was hoping to achieve was a portable, readable file capable of containing a complex Perl data structure, that I could slurp into memory, manipulate, and write back out.

XML::Simple is the putative answer to these goals. It was pretty simple, but not brain-dead simple. Some of the arrays embedded in my hash have only one element. Apparently XML, by itself, is unable to distinguish between a single-element array and a scalar, so there is no a priori one-to-one correspondence between plain XML and a Perl data structure. XML::Simple gives you a way to force certain elements to be arrays when the XML file is read, but this amount of finagling was contrary to my objectives.

Would I use XML again? Probably not as a general-purpose embodiment of a Perl data structure. For that, I would look around for another format, another module -- or write my own. But my mind is still open for other applications. With this much smoke and heat, there's gotta be a fire somewhere!

[mt2k]

I can't really say much about XML, since I don't know very much about it, but I *will* say that Data::Dunper has served me well for what you are talking about Dr. Mu.

Yes of course, updating the "database" can be a heck of a time, especiallly via a web server (ie: CGI script). Only one process can update the file at a time, otherwise you get scrambled files, race conditions appear, etc. etc.

This means that you must lock a "lock file" before dealing with the data file, so that only one process can access the script at a time. This works great for low-traffic sites, but have more than one access to the script every second, and serving time slows down big time, as each new request has to "get in line" to have access to the database.