gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [RT] Gump 3.0 - Database Model
Date Thu, 09 Dec 2004 17:53:37 GMT
This is cool.  FWIW, here's some bits from my experience, implemeting
something similar in a MySQL database.

In my Build Results system, I have a schema that also includes a few
additional things:

 - abritrary groupings of projects, which helps in organizaing various
    forms of the presentation of the data

 - the general notion of "attributes" associated with each:
    - build (instance)
    - project
    - group
    - the whole system

And since my system is focused on creating interaction between people
about given built baselines, I have the notion of a notes history 
with any given build, in a similar spirit as the comment history of a 
"bug" in bugzilla.

Like the notes table, I have separate tables for (references to) 
and another for results, to support any arbitrary number of 
to a given build-instance.  This could be hidden in your diagram inside 
"builds" entity/table, but wasn't explicit.

I've built a lot of generality into my schema, since I need to support 
inputs into this database, from various (new and old) build systems.  Thus
things like the result table is kept very general within the database. One
area that is not very well thought out (in my case) are how results and/or
build instances depend on each other, a core requirement for Gump, as
it seems.

Hope this helps.  Comments?


Stefano Mazzocchi <> wrote on 12/08/2004 06:32:34 PM:

> Since I received no pushback on my proposal, let's move on discussing 
> the database model.
> I think the first step is to identify the entities that we want to 
> model, their relationships and their respective cardinality.
> Here is what Leo and I came up with so far (attached as PDF).
> Comments/criticism/questions appreciated.
> -- 
> Stefano.

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