|
List Info
Thread: Dictionaries in database
|
|
| Dictionaries in database |
|
2006-04-13 17:00:48 |
|
Hello Colin,
I’ve just had a quick read through
your patch, and also discussion in the bug number 6430 – the patch looks reasonable
(depending on performance overload), however you miss uploading the
manage_config_status_page, which will need to deal with a fair bit of logic:
The patch that you have uploaded, adds an
override to lang_get, such that it can do a language lookup from a database
first. And that in a similar way to configR17;s, this can be customised to a
specific user/project. This allows the following string: $s_status_enum_string
=
'10:new,20:feedback,30:acknowledged,40:confirmed,50:assigned,80:resolved,90:closed';
To be stored in the database, allowing per-project customisation.
Therefore, the patch is probably reasonable
to that extent. We will however need to think about this from a performance
point of view – in terms of the number of database queries performed
through lang_get. Etc.
What isn’t included in the patch,
and may exist in your config status page (manage_config_status_page.php
/ manage_config_status_set.php -
not in patch file) is the following:
a) The config file contains a number of $g_status_enum type
values.
b) In the case that you have project specific enumerations, there is
some work to do on the config side:
a. A status code e.g. resolved, should always have a unique ID (across
all projects)
b. The order of status codes is important as we do do >= etc I
believe in the code when performing queries.
c. Should it be possible to renumber status codes etc?
I think that the above will be needed to
avoid a problem that would occur in the following case:
a) for Project A you have “10:new,20:resolved, 30:closed”
b) for Project B you have “10:new,20:testing, 30:resolved,
40:closed”
c) You add 1 bug in Project A, set status to resolved
d) You add 1 bug in project B, set status to testing
e) You then switch view to ‘ALL_PROJECTS’
f)
You view
the bug list of the above 2 bugs
At that point, we need to be careful of
what happens – I can’t recall off hand whether we would just look
for a lang_get response for project id = 0 ‘i.e. all projects’, or
whether the call to lang_get would check what bug the project belonged too, and
still display the correct string.
Colin: what is the current behaviour in
the test case I outline above?
Paul
From:
mantisbt-dev-admin lists.sourceforge.net [mailto:mantisbt-dev-adminlists.sourceforge.net]
On Behalf Of Colin Pitrat
Sent: 13 April 2006 17:23
To: mantisbt-devlists.sourceforge.net
Subject: [Mantisbt-dev] Re:
Dictionaries in database
Hi,
I made it. I also added a page to test it on status. Here is the patch, I also
putted it on the bug page : bug 6430
( http://bugs.mantisbt.org/bug_view_advanced_page.php?bug_id=6430
).
Colin
2006/4/13, Colin Pitrat <gmail.com">colin.pitratgmail.com>:
Hi,
I thinked about it, and the way I see it is that I should modify the two
functions lang_get and lang_exists by adding them parameters ($t_user and
$t_project as for config_get) and check if the value corresponding to the
matching user/project is in the database. If it is, I return it, else I return
the default value.
Now I have the following question : what should I modify to add the table in
the database ? I made the following list, but maybe I'm missing something :
- admin/db_stats.php
- admin/db_table_names_inc.php
- admin/install.php
- admin/schema.php
- admin/upgrades
;- config_defaults_inc.php
- core/config_api.php
Colin
Hello,
as I had some problems with it, I'd like to add dictionaries in the database
for customs enumerations as
explained in bug 6430 (http://bugs.mantisbt.org/bug_view_advanced_page.php?bug_id=6430
).
Does anybody has an advice about it, or an idea of how to do it ? I think it
should look like the configuration
in database stuff.
Regards,
|
| Dictionaries in database |
|
2006-04-14 07:36:58 |
|
2006/4/13, Paul <quakenet.org">paulquakenet.org>:
What isn't included in the patch,
and may exist in your config status page (manage_config_status_page.php
/ manage_config_status_set.php -
not in patch file) is the following:
a)
The config file contains a number of $g_status_enum type
values.
b)
In the case that you have project specific enumerations, there is
some work to do on the config side:
a.
A status code e.g. resolved, should always have a unique ID (across
all projects)
b.
The order of status codes is important as we do do >= etc I
believe in the code when performing queries.
c.
Should it be possible to renumber status codes etc?
In my version, I made it possible to define name, index and color of statuses. My page is quite a simple example, and doesn't even allow to choose the language that is affected (it always affects all languages). It's just that it fits our needs. I didn't check that IDs are unique for a given status or the order of the status. Testing my modifs, I even noticed that I forgot to define the *_bug_title and *_bug_button strings.
I think that the above will be needed to
avoid a problem that would occur in the following case:
a)
for Project A you have "10:new,20:resolved, 30:closed"
b)
for Project B you have "10:new,20:testing, 30:resolved,
40:closed"
c)
You add 1 bug in Project A, set status to resolved
d)
You add 1 bug in project B, set status to testing
e)
You then switch view to 'ALL_PROJECTS'
f)
You view
the bug list of the above 2 bugs
At that point, we need to be careful of
what happens – I can't recall off hand whether we would just look
for a lang_get response for project id = 0 'i.e. all projects', or
whether the call to lang_get would check what bug the project belonged too, and
still display the correct string.
Colin: what is the current behaviour in
the test case I outline above?
I have the default setting for ALL_PROJEC TS, and I overrided it for a
project "Test" (changed the name and colors of existing states,
suppressed an index, added another one). When I list the bugs of all
projects, I see the colors of ALL_PROJECTS even for bugs of Test, and
the bugs in the added state is shown in status 60 (the index of this
state). That means that we call lang_get for project_id = ALL_PROJECTS.
I don't know if it's a lot of work to modify it. I will check it.
Paul
Hi,
I made it. I also added a page to test it on status. Here is the patch, I also
putted it on the bug page : bug 6430
( http://bugs.mantisbt.org/bug_view_advanced_page.php?bug_id=6430
).
Colin
2006/4/13, Colin Pitrat <gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">colin.pitratgmail.com
>:
Hi,
I thinked about it, and the way I see it is that I should modify the two
functions lang_get and lang_exists by adding them parameters ($t_user and
$t_project as for config_get) and check if the value corresponding to the
matching user/project is in the database. If it is, I return it, else I return
the default value.
Now I have the following question : what should I modify to add the table in
the database ? I made the following list, but maybe I'm missing something :
- admin/db_stats.php
- admin/db_table_names_inc.php
- admin/install.php
- admin/schema.php
- admin/upgrades
;- config_defaults_inc.php
- core/config_api.php
Colin
Hello,
as I had some problems with it, I'd like to add dictionaries in the database
for customs enumerations as
explained in bug 6430 (http://bugs.mantisbt.org/bug_view_advanced_page.php?bug_id=6430
).
Does anybody has an advice about it, or an idea of how to do it ? I think it
should look like the configuration
in database stuff.
Regards,
|
[1-2]
|
|