Feature #83846
closedAbility to determine own DB naming conventions.
0%
Description
It would be nice to let developers determine which characters they want included in naming their database tables and or fields.
Advantanges:----------------------------------------
- It increases the amount of freedom a TYPO3 developer enjoys in the database creation process since one is now able to define his own rules as opposed to being construed to traditional characters [a-z0-9_]
- Developer is subsequently able to get the most out of working with the database.
- Importance of working with own characters in the database also increases innovation.
----------------------------------------
- Simple reasons: Certain people just like to work that way - varying reasons.
- Complex reasons: Use in partialy or fuly automated Scripts or could even be in inteligent systems where tables are arrange in a systematic fashion and codes are used to determine which tables are accesed next and which ones belong under which tables and so on.
Easy to do
----------------------------------------
To allow users to determine own rules in naming conventions in TYPO3 is really easy. As of version 9.1, only 3 changes to code would need to take place.
First:
In LocalConfiguration file under DB definition block where database name, pasword, etc is provided, an additional key-value pair could be introduced as an option to carry the regex definition. Example block would look as follows
'DB' => [
'Connections' => [
'Default' => [
'driver' => 'mysqli',
'dbname' => 'typo3_database',
'password' => 'typo3',
'host' => '127.0.0.1',
'port' => 3306,
'user' => 'typo3',
'socket' => ''
'charset' => 'utf-8',
'regex' => '[a-z0-9$_][\w$]*'
],
],
],
Second:
In the \TYPO3\CMS\Core\Database\Schema\Parser\Lexer
class inside getCatchablePatterns()
function, the unquoted identifiers pattern '[a-z0-9$_][\w$]*'
would be changed to
(string)$GLOBALS['TYPO3_CONF_VARS']['DB']['Connections'][ConnectionPool::DEFAULT_CONNECTION_NAME]['regex'] ?? '[a-z0-9$_][\w$]*', // unquoted identifiers
. This way, if the regex key is absent in the database definition block, the statement has a fallback to what is commonly used.
Finally:
In the \TYPO3\CMS\Core\Database\Schema\SchemaMigrator
class inside importStaticData()
function, the pattern '/^INSERT\s+INTO\s+`?(\w+)`?(.*)/i'
would be changed to
'/^INSERT\s+INTO\s+`?('. ((string)$GLOBALS['TYPO3_CONF_VARS']['DB']['Connections'][ConnectionPool::DEFAULT_CONNECTION_NAME]['regex'] ?? '\w+') .')`?(.*)/i'
so that the pattern matches that in Lexer file.
That's all that's needed. In fact, the above two lines could be copied and pasted 'as is' in their respective files. Namespace will need to be added in Lexer file since it doesn't already have it. Only takes less than two minutes, then state in the manual that if one want to define own naming rules, one has to add a 'regex' key in the DB definition block and provide pattern. That's it. No changes to Doctrine will need to be done.
Effects of changes
----------------------------------------
The changes only affect patters only. First change will affect ext_tables.sql entries. Second change will affect ext_tables_static+tt.sql file entries - both based on supplied pattern.
Tests
----------------------------------------
I tried the above changes on version 9 LTS. Changes work perfectly. No additional changes required.
Could such a simple change be incorporated in upcoming versions?
Updated by John Miller over 6 years ago
- Related to Bug #83832: Constructing Tables With UTF-8 Special Characters added
Updated by Christian Kuhn over 6 years ago
- Status changed from New to Needs Feedback
Hey John,
as answered in #83832 we think this feature is of little importance and we see no huge additional freedom in allowing arbitrary characters on this level, instead it potentially opens quite a list of possible issues.
If you are really eager to work on this, a patch that would have a chance to make it to the core not only has to change the parts you found already, but also has to make sure that frontend, install tool and backend still work if you rename extension or system tables with having arbitrary characters. An extensive set of additional functional and acceptance tests is needed to verify this really works and is free from side effects. Feel free to work on this and come up with a patch that satisfies these conditions. We then can see the real impact of such a change.
Updated by Riccardo De Contardi over 6 years ago
- Status changed from Needs Feedback to Closed
No feedback since the last 90 days => closing this issue.
Moreover, as Christian Kuhn wrote on his comment, this could lead to a lot of issues (and effort to fix them) compared to the benefits, so we regrettfully reject this one for now.
If you think that this is the wrong decision, please reopen it or open a new issue with a reference to this one.
Thank you and best regards