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 Thu, 25 Oct 2012 09:56:19 GMT
On Thu, Oct 25, 2012 at 12:16 AM, Ryan Ollos <ryan.ollos@wandisco.com>wrote:

> On Wed, Oct 24, 2012 at 5:29 AM, Peter Koželj <peter@digiverse.si> 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.
>
> (1) http://trac.edgewall.org/ticket/10925
> (2) http://trac.edgewall.org/ticket/5658
> (3)
>
> http://trac.edgewall.org/browser/trunk/trac/ticket/model.py?marks=1061,1064-1069,1075-1076&rev=11359#L1051


That code for milestone update (reference 3) is ok (given the datamodel).
However in bloodhound_multiproduct/multiproduct/model.py
Product._update_relations() you can find this:

for t in Product.get_tickets(self._env, old_name):

                ticket = Ticket(self._env, t['id'], db)

                ticket['product'] = new_name

                ticket.save_changes(author, comment, now)


Not sure if it is single transaction or not, but it is N SQL updates for
sure.

If you have 10000 tickets in a product, that will be 10000 roundtrips to
the SQL server.


Peter

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