Pseudo appending XML using safe-perl

[causer1984]

Does anyone know how to append to an XML file while still enclosing it in a <master tag>?

<entries>
<entry1 />
<entry2 />
</entries>

becomes

<entries>
<entry1 />
<entry2 />
<entry3 />
</entries>

Because it is safe-perl, I cannot include modules. I would know the exact length of the closing tag (</entries>) and so it would be a case of just appending to the XML file then seeking backwards a set number of bytes. The function fseek might be the function I need, but I cannot figure out how to use it.

Any help appreciated

 

[stevexff]

If the file is of a reasonable size (i.e. not 100MB), read it into an array, insert a new array member in the correct place, and write the whole file back out again. Then you can easily check for </entries> and insert before it. Note: in your input file <entries/> would be a legitimate tag for an empty <entries></entries> pair, so you might need to check for that too. In this case you'd need to delete the <entries/> and replace it with <entries><entry /></entries>, in which case the array method would be way easier than messing about with fseek.

As you can't use modules, hopefully this is a one-off deal, rather than you want a generic solution that works with any XML file.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[causer1984]

Thanks Steve,

This is indeed a one off project, so any filthy hard-coded perl would be fine. The downside is that the XML file has the potential to be of non-negligible size (~25MB) and so I wasn't keen on the Reading and Writing method (I apologize that I forgot to write that into my original post.)

As you might have guessed from me using safe-perl, this is a CGI-script. It is actually to add an entry into an address book. Databasing it is out of the question due to web-server restrictions.

 

[stevexff]

OK. Having spent most of my working life on financial transaction systems, I always balk at update-in-place on a sequential file from an online system, just because there are so many things that could go wrong, leaving you with a corrupt file.

How many updates a day are you expecting? Also, while we are on the subject of non-trivial overheads, when you need to look up an address you've still got to read the whole file. Given that you'd expect a read/write ratio of at least 90/10 with lookups outnumbering the updates, then the write overhead isn't really the issue, is it?

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[causer1984]

Thank you Steve.

Looking at it like that, I guess the array option might be the only sensible way of doing it.

I'm not happy about the update-in-place system here either. It is however backed up regularly. Do you reckon a separate file for each XML entry would be better then?

 

[stevexff]

One per entry won't help you too much, as you'll still have a massive directory of files to process. Maybe a compromise - you say they are addresses, split them up alphabetically into address_A.xml, address_B.xml, etc. If you only have to open the smaller files, searching will be quicker, and the array writeback method will be fine.

But you should still look at a databse on the server - sqlite3 is a real lightweight SQL implementation that doesn't use a server.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]