bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: Datamodel and data consistency
Date Mon, 29 Oct 2012 18:03:17 GMT
On 10/29/12, Gary Martin <> 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 [...]


> 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



Blog ES:
Blog EN:

Featured article:

View raw message