|
From: Ben C. <php...@be...> - 2002-05-25 21:18:22
|
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 |