Way back in 2006, I spent a week or so trying to use ORM in a project I was working on, only to discover that rather than making my life easier, it constantly prevented me from doing what I wanted to do. I spent an inordinate amount of time trying to convert SQL queries into ORM, but I kept ending up with slower, more complicated messes. And since this particular project required me to pull information out of very large databases very quickly, I was never completely comfortable trusting an abstraction layer to optimize SQL queries as well as I could.
It’s been a few years since I’ve developed software full-time, but since I still encounter articles about how great ORM is, I figured that either the situation has improved since then, or maybe I was just too stupid to harness the power of ORM. But then I found someone who has come to the same conclusions I did way back in 2006, and has written about them a lot more eloquently than I did in my original rant. At least I’m not alone anymore!
The xen-vm-autosnapshot.py script has been updated with an important new option: –snapshot-tag. I still can’t believe I made such a silly oversight, but previous versions of this script had no way of differentiating between snapshots created automatically and those that were created manually. So if you happened to have some old manual snapshots lying around, the snapshot-rotate routine would have rotated them along with all the rest.
The –snapshot-tag option fixes this by allowing you to “tag” each snapshot as it’s created. Then the snapshot-rotate routine will only consider snapshots with the correct “tag.” This also allows for more advanced snapshot/rotation schedules.
Thanks to Adam Adamou at NJEDge.Net for his input.
I’ve just updated NagiosPluginsNT for the first time in a long time. I don’t really get to spend much time on this project anymore, since my current employer has moved away from Nagios.
A bug fix version of SMTP Tester has been released.
The xen-vm-autosnapshot.py script has been updated. It can now accept strings for –log-level (e.g. –log-level=debug), and the –test option has been renamed to –dry-run (since that’s the convention everyone else in the world seems to be used to).
Some of you have been asking about the problem where snapshots get locked and can’t be deleted from NetApp volumes. Unfortunately, this appears to be related to the way the XenServer API interacts with NetApp’s DATA OnTap API. Unless someone out there can enlighten me, I don’t think there’s much we can do, other than wait for Citrix to fix their API. =(