bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Žitnik <>
Subject Re: Datamodel and data consistency
Date Fri, 26 Oct 2012 08:41:15 GMT
On 10/25/12 8:57 PM, Olemis Lang wrote:
> [...]
>>> 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.

Actually, resolution, priority and severity update corresponding ticket 
fields within a transaction 

as they all derive from Abstract enum.

>> That code for milestone update (reference 3) is ok (given the datamodel).
>> However in bloodhound_multiproduct/multiproduct/
>> 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,
> it does not seem so

It's a single transaction, it's established in the update() method 
before this code gets called.

>> If you have 10000 tickets in a product, that will be 10000 roundtrips to
>> the SQL server.
> yes ... we are the ones who have to improve that code snippet and use
> transactions and/or something more efficient .

I agree that the update part needs to be improved, I would suggest we go 
with the same approach as it's used in trac core for component update, 
but I suspect that the current implementation was chosen to enable 
notifications for ticket product update (change notifications)... so, I 
guess the problem is a bit wider..

What we should keep in mind when discussing data model and data 
consistency is the dependencies that rely upon ticket changes and 
related structures, namely ticket change notifications (upon which many 
plugins depend, announcer plugin being one example). Looking at 
ITicketChangeListener extension point, currently updates (renames) to 
various related structures (component, milestone, version, product...) 
produce inconsistent results. Renaming a product for example would 
trigger ticket change listeners, most of the other changes (resolution, 
priority, severity...) wouldn't. Milestone change is special case as it 
even defines it's own extension point for milestone changes (not really 
sure why).

I think we need a consistent 'notification strategy' which is basically 
deciding whether changes to structures related to tickets (products, 
milestones...) actually result in ticket notifications or not. If we 
choose that the change of related structure actually triggers ticket 
change we should keep in mind that even if we optimize the actual 
structure update, we'd still have to do ticket change notifications for 
all related tickets (which would result in huge database queries to 
fetch all affected tickets anyway).


Jure Žitnik
skype: jzitnik
mobile: +386 41 378 597

Digiverse d.o.o.
Dolenjska cesta 318
1291 Škofljica

View raw message