Feature #51025
closed
Rewrite of "old-style" string relations
Added by Gabriel Kaufmann / Typoworx NewMedia over 10 years ago.
Updated over 1 year ago.
Category:
DataHandler aka TCEmain
Description
TYPO3 uses a lot of string-relations like "pages_33" ([TABLE]_[UID]) which are not state of modern coding style.
Instead TYPO3-Core could introduce a unified table for relations that is working similar to MM-Tables:
tx_relations
(String) table | (int) uid_local | (int) uid_foreign
Instead of the string-relation the TCA-Field of type "DB" or "Group" currently using this relation type should write a reference-uid to the tx_relations-table.
TYPO3 Core code that is currently using the old explode code to process string-relations should be replaced with a new t3lib-method either solving the relation with an internal query (returning the final result) or building a join-query to extend an existing query prepared for the final result.
- Status changed from New to Needs Feedback
- Priority changed from Should have to Could have
- TYPO3 Version changed from 4.7 to 6.2
How do you expect backwart compatibility to work?
This also needs an upgrade wizard.
You can always propose a patch: http://wiki.typo3.org/CWT
Philipp Gampe wrote:
How do you expect backwart compatibility to work?
This also needs an upgrade wizard.
You can always propose a patch: http://wiki.typo3.org/CWT
Well of course I already thought a lot about backward compatibility. On the one hand we have some places in Core that would have to been fixed. On the other hand there may be some third-party plugins as well that are using hard-coded logic accessing it directly by MySQL.
May be a compatibility wrapper would be an idea that either works on the new-concept or works on the old one. An additional compat-flag could be implemented to give admins and developers time to migrate to a new solution.
Another idea would be too keep the string-relations in their place as well and update the new relation-table from those data to have a 2-way solution to provide a migration-solution working for both ways until developers had enough time to fix it by adding a version-flag in their extensions (f.e.).
Migrating existing data-sets from string to table should not be the problem.
I just wanted to initiate this idea here in hope somebody else may have other ideas as well. But I will anyway keep that in mind trying to find a solution.
- Status changed from Needs Feedback to New
- Target version set to 8 LTS
- Target version changed from 8 LTS to 9.0
- Target version deleted (
9.0)
- Category set to DataHandler aka TCEmain
- Status changed from New to Closed
Closing here for now: The 'csv' relations are still used in a couple of core places (eg. be_users->be_groups) and won't vanish anytime soon. Extensions have the opportunities to use inline relations without 'csv', and group can do proper MM. In case 'csv' is abandoned, this will be done with fresh issues.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by