[Yum-devel] clean up sooner

[seth vidal]

> I don't think there's anything wrong with using a sqlite DB, but it
> might be simpler to just use flat files: before actually starting the
> transaction, write out what needs to be done into a file in a format
> that is convenient to parse back in. 

xml. No point in maintaining N file formats just for fun, if we don't
have to.


> As each step of the transaction is
> completed, append an entry to the file that says that the corresponding
> element actually completed. Of course, you need to make sure that the
> file is appropriately flushed after each write.

Which means you have to read through the whole file and match them back
and forth. This is why I thought a little db would be nicer if only b/c
we could either:
1. delete the finished entry
2. update the entry to mark its state as complete.
3. query for incomplete entries at startup time.


> The point here is that recovering a failed transaction is rare, and can
> be made a little more expensive, and just appending to a file makes
> writing these logs very cheap.

sadly I think it is not as rare as we might think.
I'm curious if writing out an sqlite db is that much less cheap for this
little an amount of data.



> If you use one file per transaction, you could even keep them around as
> an audit log of what yum did on a given system, and people could simply
> truncate the logs with an appropriate tmpwatch job. That kinda thing is
> a little more hairy if you use a DB.

You can do the same with a sqlite db per transaction, too.

-sv