Re: [Debian-sf-devel] Database Model and components

[James Michael DuPont]

--- Roland Mas <address@hidden> wrote:
> James Michael DuPont (2002-11-15 03:28:56 -0800) :
> 
> > Dear all,
> > I have taken my lunch break to do a reverse engineering of the
> > sf database model. 
> 
>   That's cool.  Coincidentally, I was starting to ask the same thing
> from a co-worker :-)

Well, I would like to feed the database model into the introspector,
then from there we can do all types of transformations on it.

> 
> > I have taken the file : sourceforge/db/SourceForge_2_5.sql (Does
> > anyone have a fully patched model, I will updated)
> 
>   Well, there's deb-specific/sf-2.6-complete.sql, but it is still not
> the fully current schema, since db-upgrade.pl changes the schema
> afterwards.  Your best bet would be to connect Powerdesigner to a
> running database (I'm told it can do that).
OK, well I just got the powercables for the old netfinity 3000 and
picked up a old Dec Alpha with Nt today. One of those will be the new
server.


> > I also have a perl script somewhere for extracting all types of
> data
> > from the PDM model, and producing a clean xml.  from there we can
> > generate all types of nice code...
> 
>   The most useful use I can think of would be to generate either a
> nice Postscript detailing all tables and their relations, or
> something
> like the output of Doxygen, with hyperlinks from table to table where
> integrity constraints are available. 

Yes. That is an important goal.
This comes down to the data type level, I think sf via the introspector
will support describing a programs API and not just the package
structure.

One of the interesting things about this for me is to get a handle on
the FRS, the Groups and the bugs and tasks.
These are important for understanding software.

Then the data model from the introspector, with meta-data xml feeds
from the gcc, make, autoconf and even dpkg will give tons of raw data
about a project

The data has to be sliced into views, fed to the layout tool vcg, and
then it can displayed as UML graphs via DIA. The transformations into
other languages is then easier, and java doc can be used on it.

For example, an node type would be outputted like this:
http://introspector.sourceforge.net/introspector-node-types/node_enumeral_type.html

> I like what's currently
> available, but everything in one big page is rather unreadable.

Errr, Well yes.

I broke it down into packages, each package has one page.
They are somewhat usefull. The diagrams are almost readable.

For example the FRS is here: 
http://introspector.sourceforge.net/sf/html/Sour12.htm#53

But if you click on a node, it does jump to a huge page.
This is not good. I aggree. 

To be honest, we need to break this thing down into isolated
components,
I dont care about most of the tables and features right now, what if
the FRS was factored out into a stand-alone debian module?

Here the bugs module 
http://introspector.sourceforge.net/sf/html/Sour6.htm#29

Here the Patches module
http://introspector.sourceforge.net/sf/html/Sour10.htm#45

>   Some other use would be to somehow grep for unused tables and/or
> fields in the sources.  I'm convinced there are unused tables or
> columns that we could drop.

Yes, the singletons packages is a list of them. 
There are lots of temp tables.

> 
> > Hope you like this, More to come. 
> 
>   You bet I like it :-)  Thanks a lot, keep it up!
> 

I think the next step is to create an UML model of the tables
and generate java or c++ for the tables, then you can use doxygen on
them.

The whole thing is to just first concentrate on the core problem,
the FRS, patches, bugs, and users. The rest comes afterwards?

mike



=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com