[hibernate-issues] [JIRA] (HBX-2015) Allow custom reverse engineering strategy to enrich table/column metaattributes provided by hibernate.reveng.xml

[Jordi Hernández (JIRA)]

Jordi Hernández ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%3A8b2d9ba9-0164-469f-9b41-4c27ade9ba4e ) *commented* on HBX-2015 ( https://hibernate.atlassian.net/browse/HBX-2015?atlOrigin=eyJpIjoiNjE1ZGJlMjMzODg2NDhjMWI4NmQzMDcxYTNiYjY3YjciLCJwIjoiaiJ9 )

Re: Allow custom reverse engineering strategy to enrich table/column metaattributes provided by hibernate.reveng.xml ( https://hibernate.atlassian.net/browse/HBX-2015?atlOrigin=eyJpIjoiNjE1ZGJlMjMzODg2NDhjMWI4NmQzMDcxYTNiYjY3YjciLCJwIjoiaiJ9 )

I’m short with time and making a test would probably be very time consuming, so excuse me for trying to explain first.

In my project I’m generating entities using a hibernate.reveng.xml file for general purpose customization, alongside a RevengStrategy implementation to perform further custom actions. For instance, all my PKs are a single column named [table specific prefix]_ID. My RevengStrategy changes the generated property name to just ‘id’, as opposed to the default which would be tableSpecificPrefixId.

Now, as well as that I am dealing with the MetaAttributes for certain tasks. For instance, I developed a way to grab the column comment and assign it to the ' field-description ' MetaAttribute. What I achieve by doing that is that the attribute comment in the generated entity property is whatever the column comment is. That’s nice because our column comments describe what the field represents, so later it’s easy to work with the entities' attributes even without full knowledge of the schema. (BTW, this might be a nice PR in and of itself, as now there is nothing like this and it might make sense as the default behavior).

That’s not the only thing I’m doing with MetaAttributes, but I think this is a prime example of the issues I’m having: as much as I tried, my RevengStrategy implementation didn’t result in the fields having the proper comment. And then I found out that the OverrideRepository class that is instantiated whenever there is a hibernate.reveng file in the configuration is bypassing my custom implementation of columnToMetaAttributes.

I have found a very ugly way to get around this, by creating a class in the same package as OverrideRepository (to gain access to its protected methods), manually creating an instance of it and then twisting the thing until it did what I needed. But obviously this should not be the way to go about this (especially when the docs never mention this shortcoming and you need to reverse engineer the whole thing if you really need to generate custom MetaAttributes).

Another example: for the @Generated annotation I have added to the entitites, I’m adding my own custom MetaAttribute ' bbdd-version ' to reference the schema version that the entities were generated from (my custom templates read this property afterwards to generate the annotation). Again, if you try overriding tableToMetaAttributes in your RevengStrategy for this purpose you will find it is never invoked.

So here’s my case for this PR, please let me know what you think. Thanks a lot in advance.

( https://hibernate.atlassian.net/browse/HBX-2015#add-comment?atlOrigin=eyJpIjoiNjE1ZGJlMjMzODg2NDhjMWI4NmQzMDcxYTNiYjY3YjciLCJwIjoiaiJ9 ) Add Comment ( https://hibernate.atlassian.net/browse/HBX-2015#add-comment?atlOrigin=eyJpIjoiNjE1ZGJlMjMzODg2NDhjMWI4NmQzMDcxYTNiYjY3YjciLCJwIjoiaiJ9 )

Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.core&referrer=utm_source%3DNotificationLink%26utm_medium%3DEmail ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailNotificationLink&mt=8 ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100124- sha1:fb83546 )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-issues/attachments/20200415/d56b48e1/attachment.html