Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

belongsTo a different connection doesn't get picked up automatically #17586

Open
mehov opened this issue Feb 15, 2024 · 7 comments
Open

belongsTo a different connection doesn't get picked up automatically #17586

mehov opened this issue Feb 15, 2024 · 7 comments

Comments

@mehov
Copy link
Contributor

mehov commented Feb 15, 2024

Description

What do I have

I have a table that uses a non-default connection. To make it worse, the connection name is a variable and is configured.

    $table = $tableLocator->get($tableName);
    $connection = \Cake\Datasource\ConnectionManager::get($tableDatasourceName);
    $table->setConnection($connection);

That table belongsTo another table in the same database. But neither table has the connection defined in the table class - because again, the connection name varies.

What do I do

$table->find('all', ['contain' => ['AnotherTable']])->first();

What I expect to happen

If the select strategy is join (the default), the other table is looked up within whatever datasource is set for the original table at the moment. (The original table is initialised with a default connection, which gets updated later using setConnection().)

What actually happens

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'default_datasource_database.another_table' doesn't exist

Related

CakePHP Version

3.10

PHP Version

5.6

@mehov mehov added the defect label Feb 15, 2024
@mehov
Copy link
Contributor Author

mehov commented Feb 15, 2024

I do realise I'm reporting this for 3.10 which receives security updates only. Let me know if this got fixed in the newer versions?

@mehov
Copy link
Contributor Author

mehov commented Feb 15, 2024

A workaround to get going:

foreach ($table->associations() as $association) {
    $association->setConnection($association->getSource()->getConnection());
}

@markstory markstory added this to the 5.0.6 milestone Feb 15, 2024
@markstory
Copy link
Member

Let me know if this got fixed in the newer versions?

This has not been fixed to my knowledge.

If the select strategy is join (the default), the other table is looked up within whatever datasource is set for the original table at the moment. (The original table is initialised with a default connection, which gets updated later using setConnection().)

Are you expecting that the ORM will detect that the connection is not joinable and change the load strategy when the connection is defined at runtime?

@mehov
Copy link
Contributor Author

mehov commented Feb 16, 2024

Are you expecting that the ORM will detect that the connection is not joinable and change the load strategy when the connection is defined at runtime?

No no, that sounds too complicated, or I'm not understanding. Sorry about the confusion. Let me try to clarify.

  1. Posts belongsTo Users, both tables in the same datasource that is not default

  2. $posts = $tableLocator->get('Posts');
    $connection = \Cake\Datasource\ConnectionManager::get('custom_datasource');
    $posts->setConnection($connection);
    
  3. $posts->find('all', ['contain' => 'Users']):

    • Reality: errors out because Users are looked up in the default datasource
    • Expectations: because Posts are in custom_datasource, and belong to Users, ORM looks up Users in the datasource of Posts

@markstory
Copy link
Member

Expectations: because Posts are in custom_datasource, and belong to Users, ORM looks up Users in the datasource of Posts

So are you expecting that the ORM will cascade setConnection() calls to all related models?

@mehov
Copy link
Contributor Author

mehov commented Feb 19, 2024

So are you expecting that the ORM will cascade setConnection() calls to all related models?

Only if and when it makes sense?

Meaning:

  • the select strategy would have been join
  • the association type is belongsTo
  • the benefit outweighs the risk

@markstory markstory modified the milestones: 5.0.6, 5.0.7 Mar 9, 2024
@markstory markstory modified the milestones: 5.0.7, 5.0.8 Apr 6, 2024
@markstory markstory modified the milestones: 5.0.8, 5.1.0 May 11, 2024
Copy link

github-actions bot commented Sep 9, 2024

This issue is stale because it has been open for 120 days with no activity. Remove the stale label or comment or this will be closed in 15 days

@github-actions github-actions bot added the stale label Sep 9, 2024
@markstory markstory modified the milestones: 5.1.0, 5.2.0 Sep 14, 2024
@github-actions github-actions bot removed the stale label Sep 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants