Project

General

Profile

Actions

Feature #83846

closed

Ability to determine own DB naming conventions.

Added by John Miller almost 7 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Database API (Doctrine DBAL)
Target version:
Start date:
2018-02-11
Due date:
% Done:

0%

Estimated time:
PHP Version:
7.1
Tags:
Complexity:
easy
Sprint Focus:

Description

It would be nice to let developers determine which characters they want included in naming their database tables and or fields.

Advantanges:
----------------------------------------
  1. 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_]
  2. Developer is subsequently able to get the most out of working with the database.
  3. Importance of working with own characters in the database also increases innovation.
Reasons (Examples)
----------------------------------------
  1. Simple reasons: Certain people just like to work that way - varying reasons.
  2. 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?


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #83832: Constructing Tables With UTF-8 Special CharactersRejected2018-02-09

Actions
Actions #1

Updated by John Miller almost 7 years ago

  • Related to Bug #83832: Constructing Tables With UTF-8 Special Characters added
Actions #2

Updated by John Miller almost 7 years ago

  • Description updated (diff)
Actions #3

Updated by John Miller almost 7 years ago

  • Description updated (diff)
Actions #4

Updated by John Miller almost 7 years ago

  • Description updated (diff)
Actions #5

Updated by Christian Kuhn almost 7 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.

Actions #6

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

Actions

Also available in: Atom PDF