Re: [phpBT-dev] MODULES FOR 0.9.0

[Ben C. <php...@be...>]

Ok, I've reread the original email a couple of times now, and the
impression that have is that this might be an endeavor more suitable for
after 1.0.  The reason I asked about the means you would use for
avoiding altering the bug table is that I don't think it was completely
addressed in the original post.  For example, let's say that I take the
current schema and want to add a new module for tracking: Language.

Language lookup table:
lang_id, lang_name
1, 'English'
2, 'French'
3, 'Czech'

Then I add Language to my list of modules:
module_id, module_name
1, 'Language'

Now I want language tracking of component 2 which is associated with
project 12 (component -> module table):
component_id, module_id
2, 1

Now when I create a new bug for component 2 and select the French
language I need to store the bug_id -> module_id somewhere.  Currently that 
would be done by adding module_id to the bug table.  However, to avoid making 
changes to the bug table we need to use a separate table with the information:
bug_id, module_id, module_value
33, 1, 2

Now, this level of table joining (bug -> component_module -> language,
db, environment, etc.) becomes a problem when trying to show a list of
bugs that are using all, some, or none of these modules.  All of a sudden
there are a lot more queries to get that columnar information when
before only one was required.  That is why I'm thinking this may need to
wait a while, and why this may not be the best approach (though it may
turn out to be).  Thoughts?

On Mon, May 20, 2002 at 07:14:27AM -0000, Jirka Pech wrote:
> > This sounds like a great start to a good idea.  It would definitely be
> > nice to enable the admin to choose which options will be used (and yes,
> > by component makes sense to me -- especially when considering large
> > projects/products).  The only thing I didn't understand clearly from
> > your email was if there was a way to avoid having to add columns to the
> > bug table for each link (database_id, os_id, etc.).  Did I just miss it,
> > or do we need to come up with a way?
> 
> There is a way to avoid having to add columns. It's described in an e-mail you are responding to. I tryied to explain, what I'm prepared to do (create some tables and so) and I've requested comments and ideas before I will start.
> 
> John wrote it's a good idea, but with lot of template work. I know it and I asked if you are ready for this work, because I'm not 100% able to understand the smarty templates logic now. I will need your helping hand when I will start. And I will never start before everything will be 100% understood.
> 
> Is it clearer now?
> 
> Jirka
> 
> _______________________________________________________________
> Hundreds of nodes, one monster rendering program.
> Now that's a super model! Visit http://clustering.foundries.sf.net/
> 
> _______________________________________________
> phpbt-dev mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpbt-dev