Unlocking XML Database problems A

Unlocking XML Database problems

A while back I was lamenting the problems of locking parts of an xml file. As I didn’t have 500 euro to spend on a cool XML database like X-Hive or Tamino that handle locking I decided to rethink things. I decided to break my single XML document with 78 link entries into 78 separate XML files. This gave me the granularity to operate on a single link that I needed.

Over the weekend I installed eXist. It’s a Java based open-source XML database and it’s pretty fast too. It has a convenient XML-RPC API and I commenced stuffing my 78 individual XML files into it. This was mostly due to my faith that putting the links in a database was the “right thing” rather than thinking the problem through. At any rate, it gave me a nice way to easily access any individual link and update it. Since it has an XML-RPC interface I could update the links from any Internet connected machine. The problem comes in reassembling the 78 links into a big document again. That means either 78 queries or one big query with a lot of OR statements.

Is this a compromise I have to make? One big file gives me great convenience, lots of smaller files gives me reliability. Can I combine these two things somehow? Perhaps I should make one big file that does an XInclude of the little files in eXist? What would really rock is if I could stuff the one big file into eXist with the XIncludes in it. Then when I retrieved it I could tell eXist to resolve the XIncludes before sending me the results.