gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject Re: [RT] Gump 3.0 - Database Model
Date Thu, 09 Dec 2004 13:59:27 GMT

> Since I received no pushback on my proposal, let's move on discussing
> the database model.

I see this model is good enough for certain aspects of the proposed 3.0, but
not for all. We can't store the metadata in it, in order to perform builds
from, there is clearly insufficient information. That said, I am more than
happy to start on a 3.0 break-up by splitting the outputs from the
presentation of those outputs via this model.

That said, I still need more information on the contents of ids (and such),
to verify the model is correct. Here are some initial reactions:

One thing I noticed you mentioned was a desire for this database model to
allow Gump to be distributed. I like that goal. We can't assume one host can
do all builds (although Brutus is doing a fine fine job) so perhaps we could
allow different hosts to build and contribute data for individual aspects.
Maybe this is a goal to work towards, not focus on now, but I beleive that
"project id" including a host are not correct (they ought be independent of
the host) [Q: Are we comfortable with allowing remote hosts to connect to a
center MySQL database, or do we need an intermediary representation and more
secure protocol for such?]

Do we need environment, i.e, kaffe or JDK 1.5 or  whatever? Ought we have
hosts/workspaces as mainly informational, with environment (what ought be
the only differentiator for two builds of the same stuff, at exact time) as
the key to builds?

Do we need to allow "build output" to be optionally outside of the database,
for those of us w/o terrabytes to spare?

I like "dependency" within the database, but do we need more information
(such as optional, etc.) on that?

Also, one key piece of information in the current object model (which is
used to document from) is "cause". We didn't build this thing 'cos X failed
to build. That, along with annotations (we build this, but w/o X 'cos it was
an optional failed dependency), seem important. Personally I like all the
information on this page being available.

Maybe (as a transition) we generate simple pages from the existing object
model, but generate a results database (with history) and migrate more and
more to it over time.

Thanks, both, for putting this together.



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

View raw message