phpbt-dev

[phpBT-dev] MODULES FOR 0.9.0

[Jirka P. <fi...@us...>]

I want to add table for modules, where will stay project_id as primary key =
and columns for use_oses, use_databases, use_environments. These columns wi=
ll stay as options when creating a project.

Maybe it will be better to have only four columns (except primary key) (in =
two tables): project_id, module, module_table_name and module_key_name. We =
will then check every row with corresponing project_id and use modules in t=
hese rows. I'm not sure now, but I think it will be better for future, if w=
e want users to easily create their's own modules. It's easier to add a row=
 than a column to table (and table doesn't have to be off-line when adding =
a row).

Porbably it should be per component not per project, I'm not sure now. I ca=
n easily imagine sombody, who only wants database and environment tracking =
for one component and OS and environment tracking for second component. Wha=
t do you think?

I will give one simple example of TBL_MODULE_OPTIONS and TBL_MODULE:

TBL_MODULE_OPTIONS
------------------
module id; module name; where string
1; 'OS tracking'; '(TBL_OS.os_id =3D TBL_BUG.os_id)'
2; 'Environemnt tracking'; '(TBL_ENVIRONMENT.environment_id =3D TBL_BUG.env=
ironment_id)'
3; Database tracking; '(TBL_DATABASE.database_id =3D TBL_BUG.database_id)'

TBL_MODULE
----------
primary key; component id; module used
1; 4; 1
2; 4; 2
3; 6; 1
4; 6; 3

When we will have table like this one, we will then add at least these chec=
ks:
1. When adding component
2. When editing component
3. When submitting bug
4. When printing out bug list
5. When searching through bugs

We will also need to create an interface for creating new tables with avail=
able value for module and adding rows to TBL_MODULE_OPTIONS.

Imagine that admin will have checkboxes for all of these modules, so (s)he =
will check e.g. use_oses only, when adding a project. Then each bug submitt=
ed by user for this project will have to have OS filled. Otherwise not. And=
 admin will be also able to add new module by simply adding one table (fill=
ed with available values) and one row to TBL_MODULE_OPTIONS.

I don't know if my idea can be realized with templates and if it can be, I =
don't know exactly how. Most probably, I will need your helping hand, Ben, =
because we will probably need to create an ultimate interface, eh ...

Please, think about it deeply, imagine it everything thoroughly and tell me=
 if I'm "too forward thinking" or if we can do it some other way, because I=
'm sometimes thinking at least two steps prior to the Epoch.

Jirka

P.S.: Sorry for my english, it's not good, but I'm working on learning it b=
etter. Please tell me when I'm saying something wrong.

Re: [phpBT-dev] MODULES FOR 0.9.0

[John W. <jp...@us...>]

Jirka Pech wrote:
>I want to add table for modules, where will stay project_id as primary key 
 >and columns for use_oses, use_databases, use_environments. These columns
 >will stay as options when creating a project.
>Maybe it will be better to have only four columns (except primary key) 
 >(in two tables): project_id, module, module_table_name and 
module_key_name.
 >We will then check every row with corresponing project_id and use 
modules in
 >these rows. I'm not sure now, but I think it will be better for 
future, if
 >we want users to easily create their's own modules. It's easier to add 
a row
 >than a column to table (and table doesn't have to be off-line when 
adding a row).

I've been thinking the same about adding the user selection of
templates - adding a column for each item is 'quick' to develop but not
as flexible as the 'row' method that I think you are talking of.

The point about not having to take the db off line is a good one -
adding a row to an existing table is really easy because you are simply 
manipulating data in the table whilst adding a column to an existing 
table is slightly more 'risky' as you're altering the structure.
I can't see there's much difference for a new installation, but where an
existing install is being upgraded the row 'method' has to be better...

 From the work I've been doing on the user-based template selection, the
'row' method requires significantly more coding & logic than the
'column' method but once that's done I think it's a more elegant
solution.

> 
> Jirka
> 
> P.S.: Sorry for my english, it's not good, but I'm working on learning it better. 
>Please tell me when I'm saying something wrong.

Hey, no need to apologise... Your English is far far better than my 
Czech.... (or any other European language other than English)

> 
> _______________________________________________________________
> 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
> 

Re: [phpBT-dev] MODULES FOR 0.9.0

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

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?

On Sun, May 19, 2002 at 02:39:29PM -0000, Jirka Pech wrote:
> I want to add table for modules, where will stay project_id as primary key and columns for use_oses, use_databases, use_environments. These columns will stay as options when creating a project.
[snip]

Re: [phpBT-dev] MODULES FOR 0.9.0

[Jirka P. <fi...@us...>]

> 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 st=
art.

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 underst=
and the smarty templates logic now. I will need your helping hand when I wi=
ll start. And I will never start before everything will be 100% understood.

Is it clearer now?

Jirka

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