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 Tue, 30 Oct 2012 05:52:20 GMT
On Mon, Oct 29, 2012 at 7:03 PM, Olemis Lang <olemis@gmail.com> wrote:

> On 10/29/12, Gary Martin <gary.martin@wandisco.com> wrote:
> >
> [...]
> > I don't want to be moving away from Trac [...]
> >
>
> +1 ... though I'd really like to see some gradual transition onto an
> ORM in the middle handling DB access e.g. like SqlAlchemyIntegration
> [1]_ .
>
> > It would certainly be difficult for plugin authors to support multiple
> > plugin models.
> >
> [...]
> >
> > To make that
> > work we would probably need to make sure that changes are generally
> > transparent and always easy to convert [...]
> >
>
> +1
>
> > Going back to the problem with multiproduct, I'm happy to see us
> > swapping to using the immutable product prefix. I am not yet convinced
> > of the argument of providing an extra field for the convenience of
> > allowing us to easily make the prefix mutable.
>
> The prefix must not be mutable if it will be used to identify product
> resources . Notice that in Trac there are other relations outside DB
> schema , the most notorious being TracLinks .
>
> > Withholding the ability
> > to change the prefix will be simplifying for the users of the system so
> > that they do not have to get used to referring to tickets through a new
> > prefix on the whim of another user. While we could provide the ability
> > for the old prefix to continue to be usable for identifying the
> > appropriate resource under the new prefix, the potential confusion in
> > discussions of tickets just seems unwarranted. The workaround exists of
> > creating a new product and moving the tickets into it.
> >
>
> +1 . Changes to product prefix should be an admin task carried out
> using external scripts , trac-admin commands or alike ...
>
> > As for the question of notifications, I agree that we don't want
> > multiple emails associated with a a change of product but I think it
> > would be nice for resources that were associated at the time of the
> > change to be able to report that the event has happened. On the other
> > hand, the activity feed should really only show one event at any given
> > scope.
>
> At present batch modifications contribute a single event to the timeline .
>
> > I am not convinced that that the bulk modify apparatus is the
> > correct approach for this in the long term.
> >
>
> It looks handy to reuse existing batch modifications .
>
> .. [1] Trac SQLAlchemy Bridge
>         (http://trac-hacks.org/wiki/TracSqlAlchemyBridgeIntegration)
>
> --
> Regards,
>
> Olemis.
>
> Blog ES: http://simelo-es.blogspot.com/
> Blog EN: http://simelo-en.blogspot.com/
>
> Featured article:
>

Ok, I think we agree on most points. I do no see going away from Trac in
short term compelling either. It is just something to think about.

For products we have a couple of enhancements in mind; I would defer the
discussion until then (next week hopefully).

Peter

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