spring-boot: @Column with name attribute not working property on entities
Hi,
I’m using spring-boot-starter-parent and spring-boot-starter-data-jpa (version 1.1.9). I found some strange behaviour on entities. When I specify @Column(name = “myName”) then jpa is generating sql query containing “my_name” column (so it changes the name I provide).
Other examples:
@Column(name = "aa")
-> sql query uses column “aa” -> correct@Column(name = "aA")
-> sql query uses column “aa” -> incorrect@Column(name = "aAa")
-> sql query uses column “a_aa” -> incorrect
When I put spring.jpa.hibernate.naming_strategy=org.hibernate.cfg.EJB3NamingStrategy
into application.properties
, then everything works properly. But I don’t think that the initial behaviour is correct.
Greetings, Kacper86
About this issue
- Original URL
- State: closed
- Created 10 years ago
- Reactions: 6
- Comments: 33 (7 by maintainers)
@philwebb it is totally unacceptable that
@Column(name = "...")
is being ignored, this should always override any naming strategy provided, please re-open this issueI have some problem with Spring-boot-starter-data-jpa 1.5.2. None of the solutions,that are written above not working. Can someone help me with this.
EDIT.
spring.jpa.hibernate.naming.physical-strategy=org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
helped. problem was goneAt spring boot 1.4.1 add those two config will fix this issue:
It worked for me, Thankyou
@alan-czajkowski I’m more than happy to re-open this one if we can find a way to fix it. I’ve raised HIBERNATE-160 to see if there’s anything that the Hibernate team can do for us. Feel free to comment or vote on that issue.
It’s a shame this is still a problem in 2020 😦
I ran into this today, trying to map to an existing schema using obvious “incorrect” naming conventions for one of it’s columns. The issue I have with the solutions provided, is that they change the naming strategy at a global level. This now requires me to adjust all my model classes and add @Table/@Column annotations to each and every field to accommodate that change. I just need this one entry to be case sensitive in the way the schema tells me, not the other way around.
To be fair, the whole idea with the @Column name attribute, it that it should be used as an override, and used as is. That’s what it is there for, to provide an alternative to any existing naming strategy layer. It is clearly stating: when in doubt, use this.
It’s fine if an non-annotated field like “myType” ends up as “my_type”. But when I explicitly annotate this entry with @Column(“myType”), I am giving clear information on what I really want. Which is not “my_type” obv.
This is why we can’t have nice things.
My Problem WITHOUT ImplicitNamingStrategyLegacyJpaImpl property set
@Column(name = “aa”) -> sql query uses column “aa” -> correct
@Column(name = “aA”) -> sql query uses column “aa” -> incorrect
@Column(name = “aAa”) -> sql query uses column “a_aa” -> incorrect
My Problem WITH ImplicitNamingStrategyLegacyJpaImpl property set
My solution only worked after this::
set application.properties like this:
spring.jpa.hibernate.naming.implicit-strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl spring.jpa.hibernate.naming.physical-strategy=org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
… and
@Table("[CamelCaseTable])
on entity classAND
@Column("[camelCaseAttribute]")
on entity class attributeMy Conclusions Only
spring.jpa.hibernate.naming.implicit-strategy=org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyJpaImpl
should be sufficient to respect what @Kacper86 expected. I’ve been debuging ImplicitNamingStrategyLegacyJpaImpl and everything respects the classes and attributes names as it is, without annotation trickies.Spring Boot 2.2.3.RELEASE Database: Postgres 12
@alan-czajkowski
I did try those but it didn’t work, apparently the issue is that Hibernate will only consider either all
@Columns
in properties or all@Columns
in methods, it won’t work if you mix them up in a single class.@langley-agm the complete solution for Spring Boot in your application configuration:
YAML:
Properties:
@philwebb please re-open this issue as there is strong demand to fix this issue, you can imagine the tons of hours (and money) wasted on this issue alone
@philwebb and others,
I find there is no key “spring.jpa.hibernate.naming-strategy”,and use
spring.jpa.hibernate.naming.physical-strategy=org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
is OK.validate on spring boot M2.
I found the issue it is in
ImprovedNamingStrategy
if you want to solve it without details useDefaultNamingStrategy
insteadImprovedNamingStrategy
as belowDetails: There are 2 methods in
NamingStrategy
interfacepropertyToColumnName
andcolumnName
, first one called if you didn’t specify name in@Column
and 2nd one called if you specify name in@Column
.in
ImprovedNamingStrategy
both change the name from camel to_
format while inDefaultNamingStrategy
it is returning name as it is in 2nd method which is from my point of view the correct behavior.@MirosmarOliveira That’s to be expected. Please vote for https://hibernate.atlassian.net/browse/HHH-14584 is you’d like the situation to change.
spring boot 2.4.0 Hibernate ORM core version 5.4.23.Final That worked for me
as of this date, there are only 12 votes for this issue: HIBERNATE-160 come on guys and girls, we can do much better than that
voting ensures that issues get top priority and visibility, please take the time to go to that link and vote (create an account on that JIRA if you have to – it is worth it), please do not be lazy, voting works
thanks is work for me
Is this issue also affecting
@Table(name="...")
and@DiscriminatorColumn(name="...")
and other naming annotations?everybody please vote for HIBERNATE-160
I think the
SpringNamingStrategy
is doing this. We took the approach so that foreign key columns include the referenced column name. See this question on stackoverflow.com for background.You can change back to Hibernates
ImprovedNamingStrategy
by adding this to yourapplication.properties
file:You could also write your own if needed.