incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <ryan.ol...@wandisco.com>
Subject Re: Datamodel and data consistency
Date Fri, 26 Oct 2012 09:04:48 GMT
On Fri, Oct 26, 2012 at 1:41 AM, Jure Žitnik <jure@digiverse.si> wrote:

> 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.
>

This has been on my mind while working on some ticket, particular:
http://trac.edgewall.org/ticket/4582#comment:6
I've been thinking that I might open a dedicated ticket in the Trac core
after #4582 and #5658 are resolved to deal with the inconsistencies of when
notifications are sent.


> 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).
>

I need to look more closely at the implementation to say for certain that
we don't need to be concerned about this, but I think that BatchNotifyEmail
(1) exists to deal with this situation, as I've utilized in (2) by just
following standard patterns seen in the Trac core. The AnnouncerPlugin
doesn't yet support batch notifications as far as I know, but I haven't
tested it out with Trac 1.0 in which the BatchNotifyEmail class was added.

(1) http://trac.edgewall.org/browser/trunk/trac/ticket/notification.py#L444
(2) http://trac.edgewall.org/attachment/ticket/5658/t5658-r11413-1.patch

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message