gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject Re: Gump Database
Date Tue, 02 Mar 2004 02:59:46 GMT
This can wait a while, and certainly until after your demo.

I'll try to move it to the Wiki so folks can read/contribute as their time
allows, and not struggle to decipher (Adam English)/comprehend/respond
whilst surviving a day's inbox overload...

regards

Adam
----- Original Message ----- 
From: "Stefano Mazzocchi" <stefano@apache.org>
To: "Gump code and data" <general@gump.apache.org>
Sent: Monday, March 01, 2004 7:47 PM
Subject: Re: Gump Database


> Adam R. B. Jack wrote:
>
> > Stefano wrote:
> >
> >
> >>While the question that you should be asking yourself is: what does the
> >>data look like? how stuctured is it?
> >>
> >> From where I stand, the gump metadata is highly structured and can be
> >>perfectly mapped in to a relational structure with reasonable effort.
> >>Also, given its structure, can be indexed precisely and thus queried
> >>very efficiently.
> >
> >
> > So the fact that I can visualize this it into a huge rats nest in my
head
> > (especially when wired into objects) doesn't help me make a case for it
> > being unstructured? ;-) ;-)
> >
> > Ok, I hear you -- and stepping back, looking at the main (named)
entities as
> > entries in tables, I can see a relational schema with relationships as
names
> > with or without RI. What I can't see (though) is what helps me with the
time
> > aspect --- i.e. when a dependency is dropped, what do I compare against?
>
> nonono wait a second. What are you talking about? I was talking about
> putting the historical data into the system, not the gump metadata.
>
> > I guess the data I'm interested in right now is (somehow) relationships
over
> > time. One projects relationship to it's repository, to it's peers, to
> > communities (of users). How that looks, I'm not sure, but I'll try to
answer
> > that in my head before I continue.
>
> I have an email in my draft folder about how we can do perfect nagging
> with gump... but I need to understand the graph complexity before I can
> go on and I don't have much time ATM since we are delivering the first
> demo of our project next week.
>
> >>At that point, once you have the data in the database, you can start
> >>thinking about what to do with it. Dependency graph visualization,
> >>history of dependencies, FoG estimation, all of these are problems that
> >>will result in particular queries and particular use of the result set.
> >
> >
> > I like XML as the human (community) editable interface, and converting
it to
> > relational for each run really doesn't appeal to me.
>
> Of course!! Nonono, I don't want to move from XML descriptors to
> relational data, that would be stupid without an GUI or a webapp to
> guide people, but I wouldn't use it anyway.
>
> > Even if I do, comparing
> > as I load, and detecting changes -- also sounds like work. It also
sounds
> > similar to the XML to Object work that Gumpy is doing, and I was hoping
> > something could help out here w/o me doing it myself in pedestrian
steps.
>
> I am *NOT* proposing to change the way gump loads metadata but the way
> gump stores history information
>
> > I need to do more thinking, but thanks for the direct feedback, I
appreciate
> > that. Another persons clarity helps.
> >
> > BTW: So say we want MySQL [for results and maybe more], how do we set
that
> > up? Do we install, or leverage an existing MySQL install at Apache?
>
> good question, but too early now, let's focus on what we want to do and
> how, the infrastructural details will come after that.
>
> -- 
> Stefano.
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message