camelCase entity columns not mapped correctly

I’m trying to use micronaut-data with entities that are mapped to a legacy database. The DB contains tables with columns that are defined with camelCase names and the entities have a corresponding javax.persistence @Column(name="camelColumn") annotation. But these columns are still mapped to the default snake_case format.

Task List

• Steps to reproduce provided
• Stacktrace (if present) provided
• Full description of the issue provided

Steps to Reproduce

1. Add an entity mapped to an existing table with camelCase column names. Add a column that has a corresponding annotation like @Column(name="lastUpdated")
2. Enable schema validation with hbm2ddl.auto = validate to display errors on startup
3. Start the Micronaut app

Expected Behaviour

The @Column mapping should be honored and the lastUpdated name should be used.

Actual Behaviour

The column is mapped to snake_case instead, causing access to the database to fail. It seems as if the annotated camelCase column name is not used verbatim but processed by the standard field name parser or similar.

Example

Entity column mapping:

    @Column(name = "lastUpdated")
    private Date lastUpdated;

Validation exception:

Caused by: org.hibernate.tool.schema.spi.SchemaManagementException: Schema-validation: missing column [last_updated] in table [test_table]
        at org.hibernate.tool.schema.internal.AbstractSchemaValidator.validateTable(AbstractSchemaValidator.java:136)
        at org.hibernate.tool.schema.internal.GroupedSchemaValidatorImpl.validateTables(GroupedSchemaValidatorImpl.java:42)
        at org.hibernate.tool.schema.internal.AbstractSchemaValidator.performValidation(AbstractSchemaValidator.java:89)
        at org.hibernate.tool.schema.internal.AbstractSchemaValidator.doValidation(AbstractSchemaValidator.java:68)
        at org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator.performDatabaseAction(SchemaManagementToolCoordinator.java:192)
        at org.hibernate.tool.schema.spi.SchemaManagementToolCoordinator.process(SchemaManagementToolCoordinator.java:73)
        at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:320)
        at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:462)
        at io.micronaut.configuration.hibernate.jpa.EntityManagerFactoryBean.hibernateSessionFactory(EntityManagerFactoryBean.java:170)
        at io.micronaut.configuration.hibernate.jpa.$EntityManagerFactoryBean$HibernateSessionFactory3Definition.build(Unknown Source)
        at io.micronaut.context.BeanDefinitionDelegate.build(BeanDefinitionDelegate.java:113)
        at io.micronaut.context.DefaultBeanContext.doCreateBean(DefaultBeanContext.java:1598)

Workaround

If the database is not actually case-sensitive, the camelCase column names can be mapped to lowercase instead (e.g. lastupdated) in which case they will be applied verbatim.

Environment Information

• Micronaut Version: 1.2.6 and micronaut-data 1.0.0.M5
• JDK Version: 8

[artisom]

Hello. It is Micronaut issue and not Hibernate. When column name is provided in @Column annotation you must use it as is but instead you are modifying it. Bug is reproduced in micronaut 2. The issue is with io.micronaut.data.hibernate.naming.DefaultPhysicalNamingStrategy

@esocode To fix it in the application you can use default hibernate strategy:

 jpa:
  default:
    properties:
      hibernate:
        physical_naming_strategy: "org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl"

[davidgiga1993]

I’m facing the same issue with micronaut 2.5.4.

@Entity
@Table(name = "AppUser")
public class AppUser {
...
}

AppUser user = new AppUser();
user.setEmail("[e-mail]");
userRepository.save(user);

Table "APP_USER" not found; SQL statement:
insert into app_user (id, email, gid, role) values (null, ?, ?, ?) [42102-199]

Shouldn’t micronaut honor the @Table annotation? In another project I’m using micronaut 2.1.4 and it’s working as expected. Therefore I would categorize this as a bug. @graemerocher Can you reopen the issue?