Skip to content

Conversation

@OleksiiChumak
Copy link

No description provided.

@OleksiiChumak
Copy link
Author

https://hibernate.atlassian.net/browse/HHH-7913

@gsmet
Copy link
Member

gsmet commented Sep 27, 2018

@gbadner I think it makes a lot of sense but could you take a quick look?

@jwgmeligmeyling
Copy link
Contributor

If we want to allow this, this seems the correct way to do is. Given that at least three people voted for it on Jira, i’d say this change is fine!

@gbadner
Copy link
Contributor

gbadner commented Oct 4, 2018

I just pushed a commit with a failing test that maps the entities to a non-default schema. It fails because the placeholder is substituted with the default schema instead of the mapped schema.

After pushing that commit, I realized that the user guide says that "{h-schema} resolves the current hibernate.default_schema configuration property value" [1], so maybe a different placeholder should be used if we want to allow a mapped, non-default schema.

The Table#schema for the subselect has the correct schema name, so the information is there. The solution should take into account what is mapped, rather than just assuming the default should be used.

[1] http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single/Hibernate_User_Guide.html#sql-global-catalog-schema

@OleksiiChumak
Copy link
Author

Pushed a change. As was proposed If schema is configured on the entity level, the implementation chooses it instead of the default.

@gbadner
Copy link
Contributor

gbadner commented Oct 4, 2018

In 17.11. Resolving global catalog and schema in native SQL queries, the documentation explicitly says:

"{h-schema}
resolves the current hibernate.default_schema configuration property value."

Documentation for 2.5.8. Mapping the entity to a SQL query should be updated in a similar way, but mentioning that if a schema is mapped for the entity, then it will be used instead.

@gbadner
Copy link
Contributor

gbadner commented Oct 4, 2018

If adding support for substituting {h-schema} is added, support for {h-catalog} and {h-domain} should probably be added as well.

@OleksiiChumak
Copy link
Author

Actually, the method that resolves {h-schema} also resolves {h-catalog} and {h-domain}. So they are supported.
To be consistent with the previous commit I can implement the same behavior as for {h-schema} (first look at Table, if nothing is specified there than resolve placeholders against global settings)
But does it make sense to use @Subselect with @Table ?

@OleksiiChumak
Copy link
Author

OleksiiChumak commented Oct 5, 2018

Added same support for {h-catalog} and {h-domain} as for {h-schema}. Changed documentation

@OleksiiChumak OleksiiChumak reopened this Oct 5, 2018
@gsmet gsmet added the 5.4 label Oct 24, 2018
Base automatically changed from master to main March 19, 2021 16:00
@sebersole
Copy link
Member

See #9293

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants