incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: Datamodel and data consistency
Date Sat, 27 Oct 2012 03:33:47 GMT
On Fri, Oct 26, 2012 at 9:36 PM, Olemis Lang <olemis@gmail.com> wrote:

> On 10/26/12, Ryan Ollos <ryan.ollos@wandisco.com> wrote:
> > 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.
> >
>
> What you are doing over there seems to be exactly like batch
> modifications . isn't it better to reuse batch modification code in
> query module and make the whole thing to look exactly like if logged
> in user had selected target tickets , set product=new_product and
> comment field set to something like «Renaming product XXX to YYY »?
>
> Besides there is a way to control whether notifications are sent or
> not . Take a look at the functions in TicketRPC class [1]_
>
> IMO _update_relations is not ok , and that's been my opinion since
> long time ago . The right way to go should be to use (immutable)
>

+1 for immutable, but I would go even further and used immutable generated
id so that we have an option open to have mutable product prefix in the
future (not necessarily a good idea but having the option is always better
than not having one)


> product prefix rather than its name for all these sort of relations ,
> as stated in #110 . Modifying product prefix would be a more unlikely
> operation thus scripts for admin tasks would be ok to handle this .
> Nonetheless product names are more pretty and currently element value
> is always the same as element text.
>
> Q:
>
>   - Is there any trac hack to include id & value in select ticket fields ?
>
> .. [1] TicketRPC exported methods - from line 68 down to line 325
>         (
> http://trac-hacks.org/browser/xmlrpcplugin/trunk/tracrpc/ticket.py)
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>

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