Sutekh ramblings

(Sutekh is, of course, the python Vampire card management app Simon Cross and I have been working on)

Conceptually, the app is fairly simple, and I've been largely using it as a learning bed for pygtk. Consequently, it does things by hand, rather than the often recommended "use glade" approach. Personally, for something that now as a number of dynamic aspects to the gui (ability to rearrange panes, and so on), I think glade would have become quite painful, and straight pygtk coding is fairly easy once you wrap your head around the whole container paradigm. As an vehicle for learning pygtk, it has been pretty good.

But what has surprised me is it's ability to uncover database oddities. We have to date, discovered two issues with sqlobject (both fixed), had to work around sqlite's query optimiser by throwing in extra joins, triggered a segfault in sqlite (fixed in more recent sqlite's fortunately) and hit a bug in mysql query optimiser that makes certain queries run extremely slowly. WE ahven't triggered any postgresql bugs yet (although there have been a few weirdness's with certain versions of sqlobject talking to postgresql), but have had to fix several bugs in Sutekh's code because of postgres's much more stringent SQL implementation. For not a teribly complex database app, it's quite a impressive list.

So, do other people not trigger these bugs? Are we stretching corners of the databases that many other apps just don't hit (Sutekh has a number of tables, and can involve some quite complex joins)? Do other people just stick to one db, and work around it's quirks?

I dunno, but on the other hand, it's quite pleasing to see how some of this bugs have disappeared during Sutekh's lifetime, which is always one of the strengths of FOSS.