All of my domain model POJOs should extend a common base class. There are common single-field (different column names though) primary keys and auditing information in every table, so this obviously makes sense. What I am curious about, is how are people accomplishing this functionality when reverse engineering/pojo generating, since there are a few ways to do this.

1. Override PojoTypeDeclaration.ftl to explicitly set the extends phrase.
2. Override id.hbm.ftl and/or property.hbm.ftl to add <meta attribute="gen-property">false</meta> to the hbm.xml files.
3. Manually add meta attributes to the hbm.xml files after reverse engineering.
4. Using some sort of inheritance mapping.

Option #3 is not possible because there are over 430 tables in this application. At the moment, I am using option #2, but did originally use option #1. I have not yet looked at option #4, but that could be a possibility since there are lots of places in the templates where a pojo.isSubclass() is a conditional.

An ancilliary question is: how to properly generate the constructors. Of course, I can do this by modifying yet another template (PojoConstructors.ftl), but it still seems as if I am overlooking something fundamental. Thanks in advance for your input.

Whoops, forgot to mention #5, using a custom ReverseEngineeringStrategy and overriding the tableToMetaAttributes and columnToMetaAttributes methods. I am in the middle of trying this one out to see how it feels.

#6 use latest svn and put meta attributes in reveng.xml or a custom reverse engineering strategy.

Very odd that I just happened to check out the latest svn yesterday and coincidentally there exists two sparkly new methods in the ReverseEngineeringStrategy for me to use for just this purpose (hence the inital follow up post). You better cut that out, you're giving me the heebie-jeebies with that extra-sensory perception!

A quick follow-up question/request.

Before you make another release, would you be amenable to changing the method signatures of at least the two methods concerning meta attributes in the ReverseEngineeringStrategy interface? It would potentially be more helpful to have the org.hibernate.mapping.Table object as the passed-in parameter instead of the org.hibernate.cfg.reveng.TableIdentifier. The data in the TableIdentifier is contained in the Table class. This would allow, for instance, the generation of specific meta attributes with conditionals based on primary keys only, especially when the primary key name cannot be determined by the table name alone. Another example of a potential benefit of this change is to allow the developer to generate a 'class-description' meta attribute whose value could be the based on the Table.getComment().

There may be problems with this change in that I have not done any impact analysis on tightly integrated parts of the system (using the xml file instead of the class override, any potential plugin problems, etc.) There may, of course, be other reasons you did not pass the Table object, memory leaks, speed issues. Note that the isManyToManyTable method already passes the Table object, so this is not unprecendented.

I can easily make the necessary code changes if you point me in the direction of how to go about doing so. Thanks in advance.

I thought long and hard before i added Table directly into the isManyToMany method.

the issue is that alot of the methods of revengstrategy is used when the configuration object is beeing built and thus it is not complete and not safe to access.

In the case of manytomany it will only be used after all tables are created so not so big an issue here.

I will have to see if that goes for the metaattribute methods too.

For now I have a workaround by overriding the isManyToManyTable and storing the passed Table object in an instance variable in my ReverseEngineeringStrategy. Then I use the stored instance of the Table to find the primary key matches in the overridden columnToMetaAttributes. This will work primarily because isManyToManyTable is the first method called in the JDBCBinder's createPersistentClasses, so it is guaranteed to be called before columnToMetaAttributes.

Note, however, that the tables that I am working with are first normal form, with no many-to-many relationships and single field primary keys (the DBAs have been working on this schema for about 1.5 years now).

Could you please send me or point me to an example? I am a little bit overwhelmed, still confused about what I must change in order to accomplish this...

1) Inheriting from a base class using a ReverseEngineeringStrategy:



If you need more info, lemme know.

Is there a place where i can find these attributes?

thanks

yes, in the docs.

Ok, I found it, was very easy... My fault being so lazy...

About the docs, I downloaded the 3.2.0b9 and could not found neither the source or javadoc for the hibernate tools itself. Is really difficult for me to know what each method is expected to do, and what which parameter means without the javadoc. Is there a different place where I could download the code/javadoc?
Inside the doc.zip folder, which is where I thought I would find it, ther is only the Hibernate doc, not the tools. I can't find, for instance, the JavaDoc of the DelegatingReverseEngineeringStrategy class...

I thought that maybe it would be in the doc folder within hibernate-tools.jar, but it is not

I am not being lazy this time, I have traversed the whole zip file and have not found it...

Checkout HibernateExt from the SVN repository. See http://hibernate.org/268.html for the basics, but use to checkout the code instead of what it says on 268.

I have the same structure than you, all my entity classes are inherited from a base class, which has 4 base properties, one for the primary key, two for auditing and one for description.

Anyway, I've succesfully renamed the ordinary columns for my super properties, but I could only change the name of the properties, I would like to change the method itself, making it return super.dosomething(). Is it doable via a custom reverse engineering strategy?

Is it also possible to supress the setter methods for these properties (I need the getters because that's where the annotations go, but the setters are the same as the super.

Also, I would like that all the represented PK's on the classes (ids) would have its property renamed to "id" (without the setters again, since they're all the same type and it's already on the super class), even though there are differente column names. You've mentioned it on your early posts, but how did you do it? AS told before, I've managed to do it to regular columns via the columnToPropertyName, but didn't figure out how to do it to the primary keys.

Any lead would be useful. Thanks a lot!

ok.



no, that is not the job of the reverse engineering but the job of the code generation. And thus you will need to customize the templates used to create the pojos so that they contain the super call or simply is not generated. (the last part should actually be possible by putting a <meta attribute="gen-property">false</meta> in reveng.xml or similar in a custom reveng strategy)



see above.



columnToPropertyName shoud definitly also work for primary keys. which version are you using ?

Could you show the table layout, reveng.xml and the generated result if it does not work in the latest version.