I'm not sure there is a good enough general case there to warrant writing it. Most of the time once you get to SQL you are going to use more than one table. Factor in dependencies, one to many lookups and such and I don't know if there is a way to do that without it being specific to the data and application.
Now for individual tables and views on select you might be able to make some fancy inroads. You get back a table like:
keyfield field1 field2 =========+========+============== Data1 f1data f2data Data2 x1data NULL
and you want out
<dbxml> <row> <col> <field>keyfield</field> <value>Data1</value> </col> ...
or would you expect
<dbxml> <row> <keyfield>Data1</keyfield> <field1>f1data</field1> <field2>f2data</field2> </row> ...
The first is pretty flexible since you don't have to deal with anything but a single DTD that describes the general layout. The second way you have to DTD every table so that your parser knows what to expect. And we haven't even dealt with CDATA yet or other madness. Basically, XML is super pimped up CSV in these cases. You use the power of XML to express the relationships between multiple tables and I can't even try to think about how it would be automatable so that you could pass it straight to SQL.
Thanks, now my brain hurts again. =)
--
$you = new YOU;
honk() if $you->love(perl)
In reply to Re: XML to DBI
by extremely
in thread XML to DBI
by markwild
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |