bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ollos <>
Subject Re: Datamodel and data consistency
Date Wed, 24 Oct 2012 22:16:50 GMT
On Wed, Oct 24, 2012 at 5:29 AM, Peter Koželj <> wrote:

> Jure and I have been looking at the datamodel to see what would it take to
> implement some of the enhancements that we have in mind.
> Here are a couple of observations that pop up:
> 1. Parent/child relationships are not model by permanent ids but by names
> (like version, milestone, product... name) that can be changed by user
> through admin interface. A bit unusual but simple and eliminates the need
> for joins when no additional data from the other entity is needed.
> On the other side, renames of versions, milestones, products... (which are
> indeed rare) require update of related tickets.
> I imagine that renaming a product which has tens of thousands of tickets
> could be a bit problematic. Much more worrying is that at least some of
> these renames update tickets individually instead of as a single
> SQL statement. At least this should be fixed.

Could you point out some code examples of these individual updates so I can
better understand what you are referring to? I've been working on a patch
to deal with the lack of milestone change history when tickets are
re-targeted as a milestone is closed (1, 2). In the course of this, I'm
starting to understand (barely), how these multiple statements can be
executed within a single transaction. I think that is related to what you
are referring to.

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.


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