Public Repos and Bug Attributes

Bugdar 2 is now sufficiently far along that I’m comfortable posting the git repository. The Phalanx repository has been public from the beginning (albeit unnanounced) at Github: http://github.com/rsesek/phalanx. Bugdar 2’s repository is now also available there: http://github.com/rsesek/Bugdar2. At the same time, they will be availiable at their canonical home in https://bluestatic.org/git/. The Github mirrors are just easier for most people.

Development of Bugdar 2 is still moving fast. In the past few days I’ve laid down the core of the search system and added support for resubmitting a POST request after login (don’t lose your work if you’re not logged in). There’s two more major milestones before I consider us past the ‘first alpha’ stage: usergroup permissions and bug attributes. What are bug attributes?

In Bugdar 1, there were a set of fields that Bugdar compelled you to use: product, version, status, resolution, priority, severity, and assignment. If you didn’t want to use one of these fields, you couldn’t remove it — you just had to ignore it. There were also custom fields, but the architecture under them was always shaky. By having all these required fields, we were defining a bug as so:

CREATE TABLE bug (
	bugid int unsigned NOT NULL AUTO_INCREMENT
	userid int unsigned NOT NULL
	dateline bigint unsigned NOT NULL
	product int unsigned NOT NULL
	component int unsigned NOT NULL
	version int unsigned NOT NULL
	summary varchar(255) NOT NULL
	priority int unsigned NOT NULL
	severity int unsigned NOT NULL
	status int unsigned NOT NULL
	resolution int unsigned NOT NULL
	assignedto int unsigned NOT NULL
	duplicateof int unsigned NOT NULL
	dependency text NOT NULL
	hidden smallint unsigned NOT NULL
	initialreport int unsigned NOT NULL
	-- [A lot of other cache information here]
);

That’s a lot of data! If a bug isn’t going to use one of those fields, it’s still going to carry around all that weight. In Bugdar 2, this is how we define a bug:

CREATE TABLE bugs (
	bug_id int NOT NULL PRIMARY KEY AUTO_INCREMENT,
	title varchar(250) NOT NULL DEFAULT '',
	reporting_user_id int NOT NULL DEFAULT 0,
	reporting_date int NOT NULL DEFAULT 0,
	hidden boolean NOT NULL DEFAULT 0,
	first_comment_id int NOT NULL DEFAULT 0
);

That’s a huge difference. You’ll notice all the attributes — the metadata — are not stored on the bug itself anymore. Instead, that’s done through a tuple:

CREATE TABLE bug_attributes (
	bug_id int NOT NULL DEFAULT 0,
	attribute_title varchar(50) NOT NULL DEFAULT '',
	value varchar(250),
	PRIMARY KEY (bug_id, attribute_title)
);

The implications of this are that an single (unique), arbitrary attribute can be attached to a bug at the user’s will. The requirement of data is now imposed by the administrator rather than the developer. It also helps to normalize the database schema. So how do attributes work?

Attributes can be defined formally in an administrative panel, or they can be defined ad-hoc while editing bugs. Attributes can be titled to create a field, or they can just be values, which will be represented as tags. The goal with this system is to create a highly flexible data model in which all the stock Bugdar 1 fields could be represented as attributes.

Formally defined attributes can be one of five types: text, boolean, list, date, or user. Text fields are self explanatory. Booleans are interesting because they don’t necessarily have binary value; they have ternary value: true, false, and unset — but that’s more of a semantic detail. Lists are a set of selectable, pre-defined options. The last two types are new since Bugdar 1. Date fields will have a calendar selection widget. Finally, user fields allow the bug to be attached to some user in Bugdar’s system; this is how assignments work.

This is a rendering of how attributes will be arranged on the bug display:

That same information takes up more than half the page in Bugdar 1. That’s all for now.

Comments

Comment by Todd on 2010-04-01 14:29:04 +0000

When i install bugdar2 im getting this error

Warning: Unexpected character in input: ‘’ (ASCII=92) state=1 in /var/www/bugdar2/index.php on line 30

Parse error: syntax error, unexpected T_STRING in /var/www/bugdar2/index.php on line 30

Here is the line in question

$dispatcher = new phalanx\events\HTTPDispatcher();

I good at php but no expert. But i have never seen this before.

I did add the phalanx to bugdar2 so the files are there.

I loved bugdar1 and am very excited to get this working.

Comment by Robert on 2010-04-01 14:38:41 +0000

Bugdar2 (and phalanx — its underlying framework) makes extensive use of PHP 5.3 features, so PHP 5.3 is required. Based on current trends, by the time Bugdar2 hits final release, this shouldn’t be a problem for most users.

Comment by Todd on 2010-04-01 14:46:09 +0000

Thanks im going to try it out. I was so close with php 5.2.4

Comment by Todd on 2010-04-02 11:57:34 +0000

Are you ok with me asking questions here? I realize that this is not a stable release but i like to play. I installed php5.3.2 but now i get this error

Fatal error: Uncaught exception ‘phalanx\events\HTTPDispatcherException’ with message ‘Cannot determine event name in phalanx\events\HTTPDispatcher::_GetEventName’ in /var/www/phalanx/events/http_dispatcher.php:88 Stack trace: #0 /var/www/phalanx/events/dispatcher.php(35): phalanx\events\HTTPDispatcher->_GetEventName() #1 /var/www/phalanx/events/http_dispatcher.php(46): phalanx\events\Dispatcher->Start() #2 /var/www/index.php(79): phalanx\events\HTTPDispatcher->Start() #3 {main} thrown in /var/www/phalanx/events/http_dispatcher.php on line 88

Thanks,

Comment by Robert on 2010-04-02 12:05:04 +0000

Try going to /home instead. Would you mind moving this discussion into the forum? Other interested users are more likely to check there than a blog post.