Skip to main content

First bug tracker image

Lately, I took a closer look at the bugtracker, and entered some sample data into the database. Here you can see the current bug detail page: Detail page, 35kb. Hopefully I'll be able to create the enter bug page tomorrow. By the way, ordered a new PSU, hopefully I'll be able to start my new comp next week. Fingers crossed :) The bugtracker is currently designed with the following target plattform in mind: Apache 2.0 (maybe I'll use mod_rewrite to get pretty links like bugtracker/bug/232 instead of bug.php?id=232), PHP5 (as it's quite object oriented, and I plan to use the XML extensions) and PostgreSQL (as it has foreign keys, views and is very reliable). The target browser is Firefox, as it's my primary browser and I hate working around IE's CSS quirks and bugs. It's getting on pretty well, less problems than I expected. There is still a small design problem: All more or less static data like the various priority levels are also stored in the DB and read out every time for example the bug page is called - though they don't change. Their purpose is to serve as foreign key targets, and I think I'll put all those queries (8 by now) into a special cache class that is only updated when the data in the database changes, and otherwise it'll run directly from disk, saving those 8 queries. I'm quite curious to see how much faster it'll get, as the database is very fast. I think I won't cache the various program versions. They also don't change often, too, but they aren't needed in every report page, so it won't be a big deal when they're loaded from time to time. Something interesting I found out in this context: Let's assume you have a table with two columns, id and name and you have a query like that: SELECT * FROM table;. This code does run around half as fast as this one: SELECT id, name FROM table;. The server load is higher, anyway, the result set was returned twice as fast (only 7 rows). This is tested with PostgreSQL 8.0.0 under Windows XP with enough RAM to hold the whole database. Quite strange, but I use the second style anyway for the sake of clarity.