On Thu, Oct 25, 2012 at 12:16 AM, Ryan Ollos <[email protected]>wrote:
> 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 That code for milestone update (reference 3) is ok (given the datamodel). However in bloodhound_multiproduct/multiproduct/model.py Product._update_relations() you can find this: for t in Product.get_tickets(self._env, old_name): ticket = Ticket(self._env, t['id'], db) ticket['product'] = new_name ticket.save_changes(author, comment, now) Not sure if it is single transaction or not, but it is N SQL updates for sure. If you have 10000 tickets in a product, that will be 10000 roundtrips to the SQL server. Peter
