-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
HHH-7913 Placeholders substitution in subselect #2543
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
Conversation
|
@gbadner I think it makes a lot of sense but could you take a quick look? |
|
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! |
|
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 |
|
Pushed a change. As was proposed If schema is configured on the entity level, the implementation chooses it instead of the default. |
|
In 17.11. Resolving global catalog and schema in native SQL queries, the documentation explicitly says: "{h-schema} 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. |
|
If adding support for substituting {h-schema} is added, support for {h-catalog} and {h-domain} should probably be added as well. |
|
Actually, the method that resolves {h-schema} also resolves {h-catalog} and {h-domain}. So they are supported. |
|
Added same support for {h-catalog} and {h-domain} as for {h-schema}. Changed documentation |
|
See #9293 |
No description provided.