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
(http://trac.edgewall.org/browser/trunk/trac/ticket/model.py?marks=793,808-812&rev=11359#L790)
as they all derive from Abstract enum.
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,
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).
Cheers,
Jure
--
Jure Žitnik
email: [email protected]
skype: jzitnik
mobile: +386 41 378 597
Digiverse d.o.o.
Dolenjska cesta 318
1291 Škofljica
www.digiverse.si
