Project

General

Profile

Actions

Bug #27961

closed

Field mapping incorrect in DBAL

Added by Jigal van Hemert over 13 years ago. Updated almost 10 years ago.

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

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

A call like:

$GLOBALS['TYPO3_DB']->exec_SELECTgetRows(
  'tx_projectfiles_projects.number, tx_projectfiles_projects.title, tx_projectfiles_projects.owner, tx_projectfiles_user.uid',
  'tx_projectfiles_projects INNER JOIN tx_projectfiles_projects_user ' .
    'ON tx_projectfiles_projects_user.uid_foreign=tx_projectfiles_projects.uid ' .
    'INNER JOIN tx_projectfiles_user ' .
    'ON tx_projectfiles_user.uid=tx_projectfiles_projects_user.uid_local',
  'tx_projectfiles_user.username=\'myusername\''
);

is correctly translated to the corresponding fields in the actual database, but when returning the results only the fields from tx_projectfiles_projects are mapped back.

in map_assocArray() it turns out that the $tables array only contains the first table and the other joined tables are present as additional information:

array( 0 => array (
  'table' => 'tx_projectfiles_projects',
  'JOIN' => array (
    0 => array (
      'type' => 'INNER JOIN',
      'withTable' => 'tx_projectfiles_projects_user',
      'ON' => array (
        0 => array (
          'operator' => '',
          'left' => array (
            'table' => 'tx_projectfiles_projects_user',
            'field' => 'uid_foreign'
          ),
          'comparator' => '=',
          'right' => array (
            'table' => 'tx_projectfiles_projects',
            'field' => 'uid'
          )
        )
      )
    ),
    1 => array (
      'type' => 'INNER JOIN',
...
)

Before reverse mapping the field names are:
projectnr, projectname, ownerid, userid (like in the "remote" database)
, after mapping we have:
number, title, owner and userid

The last one should refer to tx_projectfiles_user.uid (on the TYPO3 side) and should have been labelled as 'uid'. For some reason not all tables involved in the query are sent to map_assocArray().

The source states that there is a problem when fields have the same name in different tables, but since we should use in such a case <table.column> it should not be a problem if there are no duplicate names (even without table name) in the list of columns in the SELECT part of the query.

I thought about executing the query with the special mm_query function, but this is only a shell which constructs the joins and DBAL only kicks in after that. It doesn't make any difference for this problem.

Actions #1

Updated by Xavier Perseguers over 13 years ago

Could it be possible a unit test for DBAL to reproduce the bug? Would then be easier to make it work while ensuring to do it right.

Actions #2

Updated by Alexander Opitz about 10 years ago

  • Status changed from New to Needs Feedback
  • Is Regression set to No

Hi,

as this issue is very old. Does the problem still exists within newer versions of TYPO3 CMS (6.2.4)?

Actions #3

Updated by Alexander Opitz almost 10 years ago

  • Status changed from Needs Feedback to Closed

No feedback within the last 90 days => closing this issue.

If you think that this is the wrong decision or experience this issue again, then please write to the mailing list typo3.teams.bugs with issue number and an explanation or open a new ticket and add a relation to this ticket number.

Actions

Also available in: Atom PDF