Is there a way to control the case for the generated code and mapping files? For a column named FirstName, the Hibernate code generation will produce a field called firstname and two methods getFirstname and setFirstname.

I would prefer
firstName, getFirstName, setFirstName

I know that this is a petty concern, since the code works either way. It's just a style preference. I could manually change it, but I would like to prefer not to change generated code. Once I do that, I feel obligated to write some JUnit tests.

Thank you in advance.

This is a valid concern, currently the mapper respects the more common underscore notation: "first_name" and converts it to FirstName, but doesn't respect camel case in the names now, this should be fixed in 4.0.

I just tried this in 4.0 M3, and am sorry to report that DB tables like e.g. AccountStatus, still result in generating Accountstatus.hbm.xml and Accountstatus.java.... :(

keb wrote:

I just tried this in 4.0 M3, and am sorry to report that DB tables like e.g. AccountStatus, still result in generating Accountstatus.hbm.xml and Accountstatus.java.... :(

Is there by the way any way that I can modify a template or code generation class myself to adjust this?

Quote:

Is there by the way any way that I can modify a template or code generation class myself to adjust this?

I'm sorry keb not at this time, the generation code is internal. I will push internally to see if I can get anything into 4, although the chances are slim.

support-rkalla wrote:

Quote: Is there by the way any way that I can modify a template or code generation class myself to adjust this? I'm sorry keb not at this time, the generation code is internal. I will push internally to see if I can get anything into 4, although the chances are slim.

It would be a VERY nice feature if I could modify/write my own templates, and access the metadata from the database explorer there.
Then I could easily write templates that in addition to generating the Hibernate mapping, could also generate Dao classes, detail and list JSP's etc.

At the very least, I would like to be able to add xdoclet comments so I can hook the POJOs up to Appfuse.

But keb's suggestion is spot on. I could elimate using Appfuse entirely if there was a good template to generate the support classes.

Quote:

At the very least, I would like to be able to add xdoclet comments so I can hook the POJOs up to Appfuse.

You can add these by hand now, did you mean something else? Our editor is XDoclet-aware and will even help with autocomplete and such.

support-rkalla wrote:

Quote: Is there by the way any way that I can modify a template or code generation class myself to adjust this? I'm sorry keb not at this time, the generation code is internal. I will push internally to see if I can get anything into 4, although the chances are slim.

How about a way to change the class name and mapping file name? Our naming convention has prefixes for table names based on the type of table. This is causing ugly class names, like "Tblsessiontracking" and "Tlkpreferraltype". I'd like to drop the prefix.

Until our visual hibernate mapper makes it into MyEclipse, if your needs for customization vastly outweigh the helpfulness of the current mapping facilities, you can fall back on using XDoclet temporarily to maintain your hbm.xml files based on the Java classes you write for your tables.

Or you can do a single generation then use those files as a template and change them how you need?

The table naming isn't a big deal, I can make an "adapter" subclass with the correct name. Respecting of camel case for fields IS important though, is that still scheduled for 4.0 final release?

support-rkalla wrote:

Until our visual hibernate mapper makes it into MyEclipse, if your needs for customization vastly outweigh the helpfulness of the current mapping facilities, you can fall back on using XDoclet temporarily to maintain your hbm.xml files based on the Java classes you write for your tables. Or you can do a single generation then use those files as a template and change them how you need?

Yes, but if you develop the other way around, starting with the database, you don't even have that option...


In my current project we maintain a homegrown application that reads the database metadata, and using those metada generates a whole set of other stuff, like e.g. Struts Action classes, Struts form definitions, Dao classes, JSP's for lists and detail pages, Hibernate mapping files, Hibernate (domain) Java classes etc....

The main reason I would like to have access to these code generation templates is that I could then happily throw away this homegrown app and generate all this 'out of the box'.


I have tried out this 'generate hibernate mapping' functionality in ME, and it could happily replace at least parts of the homegrown stuff with this ME functionality, if I could just access/modify the templates. The problem is that I *REALLY* need to be able to re-run the generation each time the database changes....

tbasile,
I'm not finding the issue referring to correct camel-case generation as closed for 4.0, if you are using 4.0 M3 and it is not fixed in that release then it likely won't be fixed in GA. There was just too much critical work we needed to get into 4.0, but now we've got planned a long stage of spinning back and polishing up existing features with a dedicated team (after 4 ships). We've had a bit of tunnel vision w.r.t. to this 4.0 release and the features in it, so after it ships we are all going to breath a little and start massaging everything so it flows better.

support-rkalla wrote:

Quote: At the very least, I would like to be able to add xdoclet comments so I can hook the POJOs up to Appfuse. You can add these by hand now, did you mean something else? Our editor is XDoclet-aware and will even help with autocomplete and such.

i meant having the xdoclet added during the POJO generation phase. that would be very useful for my current appfuse environment.

Quote:

For a column named FirstName, the Hibernate code generation will produce a field called firstname and two methods getFirstname and setFirstname. I would prefer firstName, getFirstName, setFirstName

Maybe my vote makes this request, getting a bit higher prio :)
I would like to see this feature too.


Greetings.