Project

General

Profile

Actions

Feature #51025

closed

Rewrite of "old-style" string relations

Added by Gabriel Kaufmann / Typoworx NewMedia over 11 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Could have
Assignee:
-
Category:
DataHandler aka TCEmain
Target version:
-
Start date:
2013-08-12
Due date:
% Done:

0%

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

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.

Actions #1

Updated by Philipp Gampe over 11 years ago

  • 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

Actions #2

Updated by Gabriel Kaufmann / Typoworx NewMedia over 11 years ago

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.

Actions #3

Updated by Alexander Opitz almost 11 years ago

  • Status changed from Needs Feedback to New
Actions #4

Updated by Mathias Schreiber almost 10 years ago

  • Target version set to 8 LTS
Actions #5

Updated by Riccardo De Contardi over 7 years ago

  • Target version changed from 8 LTS to 9.0
Actions #6

Updated by Susanne Moog almost 7 years ago

  • Target version deleted (9.0)
Actions #7

Updated by Susanne Moog over 4 years ago

  • Category set to DataHandler aka TCEmain
Actions #8

Updated by Christian Kuhn almost 2 years ago

  • 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.

Actions

Also available in: Atom PDF