Forum OpenACS Development: Bugtracker Redesign Decisions Questions

I was looking at the redesigned bugtracker, and I am curious about some of the design decisions. Most packages use the content repository in slightly different ways so I am wondering how it was designed. Specifically:

1) How did you decide to subtype cr_items and what fields went into the bt_bugs table.

2) How did you determine it was necessary to denormalize the several fields from cr_items etc...

3) Related to 1) how did you determine what fields belong in bt_bug_revisions as a subtype of cr_revisions.

Thanks!!

Collapse
Posted by Lars Pind on
Dave,

We were faced with complaints that the previous version of bug-tracker on openacs.org was too slow, so we wanted to do everything we could to make sure it was fast.

One of the things we decided to do was to denormalize the latest version of data in the bt_bugs table, and then use that as the item_subtype.

We had to do an item_subtype anyway, because we needed a place to store the bug_number with a unique constraint.

So basically we put everything we possibly could into bt_bugs (the item subtype), and everything that needs to be versioned into bt_bug_revision.

Does that make sense?

/Lars

Collapse
Posted by Dave Bauer on
Lars,

Great! :) I am just trying to get as much information as possible about content repository because so few people have a good understanding of it.

I can see from the content repostiory docs that you _rarely_ would subtype cr_items, but if you have non-versioned attributes, that is exactly what you should do.

Did you actually test the speed difference between the denormalized version and a normalized version of bt_bugs? I am just curious.

Thanks.

Collapse
Posted by Lars Pind on
To some extent. Actually setting up different solutions and testing is expensive, you have to implement things twice, but we did have a normalized version first, and then we started optimizing that. One of the optimizations was this.