bug(tree-entity): schema-qualified closure table path passed to innerJoin() breaks TreeRepository.findAncestors / findDescendants

Issue description

TreeRepository.findAncestors() and findDescendants() fail when providing schema explicitly to entity or dataSource

Expected Behavior

Prior to 0.3.29, you could use TreeRepository methods while passing in any entity in the hierarchy and it would generate the correct query

Actual Behavior

When using @Tree("closure-table") in a Postgres database configured with a global schema (e.g. schema: "public" in DataSource options) or as an option to the Entity decorator, TreeRepository.findAncestors() and findDescendants() fail with: TypeORMError: "public" alias was not found. Maybe you forgot to join it?

This is caused by TreeRepository.createAncestorsQueryBuilder() passing a schema-qualified closure table path (e.g. "public.zone_closure") into SelectQueryBuilder.innerJoin(). This change was introduced in typeorm 0.3.29 via MR #12110 as an attempt to fix issue #10263.

SelectQueryBuilder interprets dotted identifiers as alias.property, causing the schema name (public) to be treated as a query alias.

The issue went unnoticed since the tests added specifically for the issue #10263 only test the relation metadata and don't run any queries against the testing databases.

Steps to reproduce

Pass "schema" to the dataSource options (e.g. schema: "public" in ormconfig.json for tests) or in the @Entity decorator of a @Tree entity, then use TreeRepository methods findAncestors() or findDescendants(). This results in thrown TypeORMError: Exception has occurred: TypeORMError: "public" alias was not found. Maybe you forgot to join it?

Both methods of reproducing the issue have been verified and added to the reproduction repository (will link in tomorrow after dealing with formatOnSave annoyances in the editor)

My Environment

Dependency	Version
Operating System	W11 25H2
Node.js version	22.15.0
Typescript version	5.7.2 / 6.0.0
TypeORM version	0.3.29 / 1.0.0

Additional Context

Before the changes https://github.com/typeorm/typeorm/pull/12110/changes, unqualified tableName was used and the query would be generated by looking for the junction table in the default schema. I would not just revert #12110 as that would re-introduce the issue #10263 but rather follow a similar path to #10743 and continue on the effort from @pkuczynski to move tests from specific issues to functional tests of the JunctionEntityMetadataBuilder/TreeRepository as in #12259 and #12260 . I also noticed that TreeRepository find methods still use the "string-based" path instead of the relations object, so maybe it's an area to review?

Relevant Database Driver(s)

• postgres
• cockroachdb
• spanner
• sqlserver
• sap
• oracle
• aurora-mysql
• aurora-postgres
• better-sqlite3
• capacitor
• cordova
• expo
• mongodb
• mysql
• nativescript
• react-native
• sqlite
• sqljs

Are you willing to resolve this issue by submitting a Pull Request?

Yes, I have the time, and I know how to start.