View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0020168 | mantisbt | db schema | public | 2015-10-02 18:28 | 2017-05-20 16:10 |
Reporter | cproensa | Assigned To | dregad | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.3.0-beta.3 | ||||
Target Version | 1.3.11 | Fixed in Version | 1.3.11 | ||
Summary | 0020168: Use of 'mantis' as plugin table prefix prevents plugin's installation | ||||
Description | If configuration option for plugin table prefix starts with the string "mantis" table names are not formed correctly, because it detects that is passing a legacy style 'mantis_XXX_table' to db_get_table function (database_api.php) my proposed table name would be: the function is returning | ||||
Additional Information | This is the checking code
| ||||
Tags | No tags attached. | ||||
Attached Files | |||||
has duplicate | 0022715 | closed | dregad | Use of 'mantis' as plugin table prefix prevents plugin's installation |
has duplicate | 0022811 | closed | dregad | useing Source Control Integration 2.0.0 update error |
related to | 0022851 | closed | dregad | Installer should display sample table names based on table prefix/suffix settings |
Is this a real-life scenario, or just academic ? Using 'mantis_plugin' as a plugin table prefix sounds a bit silly. Who would truly want their plugin tables to be called 'mantis_mantis_plugin_MYTABLE_table' (assuming $g_db_table_prefix is left to default value 'mantis') ? I would be tempted to address this by adding an admin check to notify the administrator that this setting is not valid. |
|
yes, I actually put this configuration... The proper thing would be to make it check for string starting with 'mantis_' AND ending with '_table'
My confussion came from not seeing clear that "plugin prefix" is added after "table prefix", and thinking they were independent. |
|
OK, easy enough to do.
Makes sense, too. |
|
Considering this is a legacy naming convention from... 1.2? |
|
Indeed that's a good point. |
|
Something like this ? |
|
That would imply to modify the sample dynamically from user input... Maybe relevant: |
|
That was my idea actually, easy to do with a few lines of JavaScript. Although I'll concede it's a bit overkill ;-)
Impossible to do an actual check in real life, since 1. we can't control what plugins authors do, and 2. do not know which plugins the admin will install. So the warning could only be a generic text. |
|
Sure. My point is to make clear that to the user, before the damage is done. I had the experience of having a plugin creating tables that exceeded the length limit. Renaming the database tables after installation was a real pita...
about time. The express version that is available for development is 11g, i think |
|
I know people don't read it, but it's quite well documented in admin guide ;-) Anyway, I guess it does not cost much to add this extra warning.
Correct, 12c XE has not yet been announced even though Oracle apparently said that it's planned. I found some musings about dates in https://oracle-base.com/blog/2016/01/07/oracle-xe-12c/; 12.2 is out, but not 12.2.0.2 yet, I don't think we'll see XE 12 before end of 2017, probably even later. |
|
Changing summary to make it more descriptive of the actual problem (copied from 0022715) |
|
See 0022851 for follow up on 0020168:0051598:
|
|
MantisBT: master 4917320b 2017-04-12 04:29 Details Diff |
db_get_table() also check suffix for legacy-style names If $db_table_plugin_prefix contains 'mantis', db_get_table() function will incorrectly process a plugin's tables as if they were legacy tables (i.e. 'Mantis 1.2 style', with a 'mantis_' prefix). If $db_table_suffix also is not set to '_table', then the generated table name will be incorrect (e.g. with the Source Integration plugin, changeset table will be generated as 'mantis_Source_ch_suffix' instead of 'mantis_mantis_Source_changeset_suffix'), causing the installation by plugin_upgrade() to fail and invalid tables to be created. We now use a regex to check for legacy tables, verifying that it ends with '_table' in addition to beginning with 'mantis_'. This basically reverts commit 38bc02483eb58a3708e4f419bfa7c02b6c6900db (issue 0016038). Note on performance: while preg_match() is slower than strpos(), it is actually more efficient to use that, considering that we would need a second function call to check for the suffix, as well as a substr() call to extract the table name, while preg_match() does it all at once. Fixes 0020168 |
Affected Issues 0016038, 0020168 |
|
mod - core/database_api.php | Diff File | ||
MantisBT: master-1.3.x b933abcb 2017-04-12 04:29 Details Diff |
db_get_table() also check suffix for legacy-style names If $db_table_plugin_prefix contains 'mantis', db_get_table() function will incorrectly process a plugin's tables as if they were legacy tables (i.e. 'Mantis 1.2 style', with a 'mantis_' prefix). If $db_table_suffix also is not set to '_table', then the generated table name will be incorrect (e.g. with the Source Integration plugin, changeset table will be generated as 'mantis_Source_ch_suffix' instead of 'mantis_mantis_Source_changeset_suffix'), causing the installation by plugin_upgrade() to fail and invalid tables to be created. We now use a regex to check for legacy tables, verifying that it ends with '_table' in addition to beginning with 'mantis_'. This basically reverts commit 38bc02483eb58a3708e4f419bfa7c02b6c6900db (issue 0016038). Note on performance: while preg_match() is slower than strpos(), it is actually more efficient to use that, considering that we would need a second function call to check for the suffix, as well as a substr() call to extract the table name, while preg_match() does it all at once. Fixes 0020168 Backported from master 4917320b2067f5797aa87e5772a820e6b5a177cc. |
Affected Issues 0016038, 0020168 |
|
mod - core/database_api.php | Diff File |