On Wed, Oct 24, 2012 at 5:29 AM, Peter Koželj <[email protected]> wrote:
> Jure and I have been looking at the datamodel to see what would it take to > implement some of the enhancements that we have in mind. > Here are a couple of observations that pop up: > > 1. Parent/child relationships are not model by permanent ids but by names > (like version, milestone, product... name) that can be changed by user > through admin interface. A bit unusual but simple and eliminates the need > for joins when no additional data from the other entity is needed. > > On the other side, renames of versions, milestones, products... (which are > indeed rare) require update of related tickets. > I imagine that renaming a product which has tens of thousands of tickets > could be a bit problematic. Much more worrying is that at least some of > these renames update tickets individually instead of as a single > SQL statement. At least this should be fixed. > Could you point out some code examples of these individual updates so I can better understand what you are referring to? I've been working on a patch to deal with the lack of milestone change history when tickets are re-targeted as a milestone is closed (1, 2). In the course of this, I'm starting to understand (barely), how these multiple statements can be executed within a single transaction. I think that is related to what you are referring to. When milestone, component and version are updated, the updates to the milestone/component/version table and tickets table occur in a single transaction (3), per my limited understanding. Priority and Severity are less fortunate, as the definitions of these fields are stored in trac.ini, and changes to the values will not result in any ticket updates. (1) http://trac.edgewall.org/ticket/10925 (2) http://trac.edgewall.org/ticket/5658 (3) http://trac.edgewall.org/browser/trunk/trac/ticket/model.py?marks=1061,1064-1069,1075-1076&rev=11359#L1051
