gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Gump 3.0 - Database Model
Date Thu, 16 Dec 2004 03:40:28 GMT wrote:
> Stefano:
> See my responses below.
> Stefano Mazzocchi <> wrote on 12/10/2004 02:21:48 PM:
>> wrote:
>>>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
>>Can you elaborate more on this?
> Yes, it is a many-to-many relation between the Project and Group tables.
> Thus, I can define one group which is all "mainline" builds (we have
> several release streams managed by separate branches), regardless of
> platforms build on.  Another group would be all Windows/2003 builds.  It
> is merely a way of seeing a limited set of project names, though when
> presented on the web page, I do also display some project attributes for
> each project displayed, like the lable & link of the current build as 
> well as the "last good" build.

Ok, I see.

What I was thinking is that this (and other of your suggestions) adds a 
"meta-metadata" layer and I'm not sure if I want to add this complexity 
at this point (given that the model is complex enough already).

I agree that this meta-metadata layer will be very useful (for 
annotation, grouping and further user interaction around the collected 
data) but this is something we can add incrementally later on.

>>> - the general notion of "attributes" associated with each:
>>>    - build (instance)
>>>    - project
>>>    - group
>>>    - the whole system
>>"attributes" as in "annotations" or as in "related data"?
> I'm not sure what is the difference between annotations (like added
> noted, do you mean?) and "related data".  But what these tables do
> is, basically to allow one to add new fields to the associated table
> without a schema change.  They are name/value pairs, with the added
> key (foreign key) of the id of the table to which they relate.  Thus,
> for the Project table:
>   Project Attributes:
>     - proj_id (foreign key)
>     - name (string, key)
>     - value (blob)
>   Project:
>     - proj_id (key)
>     - ... etc ...
> In the case of the system wide attributes table, there is no "id"
> field.  That table I use for stuff like debug on/off/level, motd,
> and so far little else.

Ok, this is again another meta-metadata layer but this is something that 
I'm not sure I like. It smells of overdesign and at this point I want to 
keep features that are just critical for having the system working. "the 
simplest thing that can possibly work".

>>>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.
>>I like the concept of allowing bugzilla-style communication to happen 
>>without requiring people to subscribe to various mail lists, like a 
>>common ground for communication to happen.
>>But I don't want this to be too global, because I want gump-related 
>>discussions to happen on the mail list.
> You could tie-in email notification when this table is updated.  We
> don't do that, but it's not a bad idea.  Bugzilla of course does this.

Good suggestion. Again, this applies to the meta-metadata layer but it 
strikes me as a very useful feature to have right away. What do others 

>>>Like the notes table, I have separate tables for (references to) 
>>yes, the artifact table is missing, that's a good point.
> I use the notion of an external Artifact Repository and refer into
> that with this table.  The artifacts themselves are not stored in
> the database nor on the database server.  Just wanted to be clear
> about that.
> The notion of an Artifact Repository: ah, well, I have my idea of
> what I want, and then there's the reality that we don't have much
> more (at present) than a web-based storage mechanism, organized
> hierarchically within the file system.  Thus "version information"
> is exposed in the file-path name space, and 3rd party artifacts
> are managed in yet another system.  My notion of an Artifact
> Repository would be a place to store any 3rd party artifact that
> any build could depend on.  Build themselves would be producers,
> but could also be consumers.  One of the main points of this is:
> that I separate, architecturally, the Artifact Repository, as a
> separate service, from the build system itself.

Keep in mind that we DO NOT WANT gump to build anything that anybody 
would start use for their own stuff. It is critical, socially and 
politically and for the security ecosystem that gump's artifact 
repository is not used for anything else rather than distributed gumping 
and fallback scenarios.

Consider it a cache, a repository of "precomputed calculations" rather 
than anything else.

This is true for executables: for javadocs and docs, this is a different 
story but we should not attack too many problems at the same time.

>>>and another for results, to support any arbitrary number of 
>>>to a given build-instance. 
>>Good point.
>>So, things missing are:
>>  1) bugzilla like comments (on build results only? or what else?)
>>  2) artifact table / artifact type table
>>Anything else you guys see missing?
> Note: The results per build table (to support an arbirary number
> of results per build) was a separate table from the artifact table.
> In fact, at present in my schema, for a single build table entry,
> there can be:
>  - any number of notes
>  - any number of artifacts
>  - any number of results

This is interesting. How can you have different numbers of results if 
you have only one output signal for a given build?

[snip color coding]

> Thanks for including me in the discussion.  I look forward to more.

me too! :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message