I’m looking for guidance on implementing a mechanism for conditional column mapping in my entities.
My Use Case: I’m building an application that will be deployed in different environments. In some environments (e.g., production), I need specific audit columns (like created_by, creation_date) on certain tables. In other environments (e.g., development, testing), these columns might not exist in the schema, and Hibernate shouldn’t expect them.
The Goal: I want to be able to enable or disable the mapping of specific entity fields (annotated with @Column) based on an external configuration (e.g., a property file value, system property, or environment variable). Conceptually, I’m looking for something like an @OptionalColumn annotation.
Question: Is there a built-in feature in Hibernate (or JPA standard) that supports this kind of conditional mapping?
If not, what would be the recommended approach? Could this be achieved through:
Configuration properties?
Bytecode manipulation or interceptors?
Using Java Reflection during the metadata building phase?
Leveraging annotation processors somehow?
I want Hibernate to completely ignore the field-to-column mapping if the corresponding feature (e.g., auditing) is disabled in the configuration, thus avoiding errors if the column doesn’t exist in the database.
Any pointers, best practices, or examples would be highly appreciated!
What’s the big deal if you add these columns also in your development schema? You really should run the same schema in development that you use in production, otherwise you’re at risk of missing out on something.
You could use orm.xml to mark some attributes as transient, but you really shouldn’t need this.
First of all, thank you for your time. The dev/production was just an example. In reality we have different production environment and based on some regulations, we need to enable/disable these fields on some entities . We also always want the possibility to disable a feature because prod can’t wait for us to release a new version, but they need to disable a feature with just a configuration and an application reboot.
I know what you suggest is optimal but it can’t be applied in my case. So do you suggest to do this kind of custom config through the orm.xml and maybe load a different orm.xml based on a configuration ? would that work?
So do you suggest to do this kind of custom config through the orm.xml and maybe load a different orm.xml based on a configuration ? would that work?
If you really have to, I guess that is the only way, but like I wrote before, I would suggest you to not do this and instead figure out a way to always use the same schema in dev and prod.
Why can’t you just make the new schema version backwards compatible so that it can also function if a feature is not enabled? This can be done by making columns nullable even though they might not logically be nullable. You can cleanup the schema once you decide to permanently activate a feature.
Thank you a lot for your support @beikov, I manged to find a solution that works thank to you. I had to go with the orm.xml solution unfortunately I don’t get to decide
unfortunately I don’t get to decide