BUGtrack Blog: BUGtrack 3.5 interim release

For the next BUGtrack version we have planned the implementation of aggressive caching. What does it mean?

In order to display the page BUGtrack should perform many preparation steps. First of all, it should validate URL parameters. Is the bug specified in URL, is it accessible by the user? Does the project exist and accessible? Next, BUGtrack requests the data for various lists and items: what is current user's name? What projects current user has access to? And so on, and so on. However, this information does not change frequently, and most likely all subsequent checks and queries return same results - unless you modify your license settings.

What do we do now? On the first access to the license we load all its settings from the database into the object model that is cached in the server's memory. For all the information we need, we do query the object model, rather than the database. This way it works faster, much faster. And when you make changes in the license's settings, all the changes made in the cache are dumped to a database immediately, so even in a case of an unexpected failure everything will be saved and synchronized.

Beside of performance, the object model approach improves project's manageability. Not everything could be done easily on the database level; the code was split between the application and the database server. Now business logic resides in one place.

You may ask: “Alright, improving performance and manageability is great, but what are the improvements for us, end-users?”

In order to use an object model we’ve done changes in almost every part of BUGtrack. We have not planned much usability changes for this release, that’s why, despite of a major internal restructuring, we still consider it as a minor release and number it 3.5. There is one feature we plan to introduce though – we are going to get rid of license setup URL.

As you know, to setup a license, the user must visit license setup URL at least once. The license identifier is stored on user’s computer in browser cookies. This is a good approach, but sometimes it leads to problems: the user must follow setup URL again when cookies were cleared or when using another computer; also the user can access one license at the time; though Project Sharing feature allows overcoming latter limitation.

Here we are going to make a change. Each license will be associated with a sub-domain of bugtrack.net, such as foresoft.bugtrack.net for example. This URL will fully identify the license and would be much easier to remember that a former license setup URL containing the sequence of 32 digits and letter. The project sharing won’t be needed anymore.

BUGtrack 3.5 development is almost finished. Next month we are going to run through series of regression tests to ensure that everything works perfectly.