]
Max Rydahl Andersen commented on HBX-716:
-----------------------------------------
sorry for the late answer; but yes this needs to be a seperate exporter/set of templates
that generates a interface that you can use in your code to get better HQL typesafety.
If your classes needs to implement this interface they can do so by adding <meta
attribute="interface">IApplicationProperties</meta> assuming you
configured the template to generate via the pattern "I${class-name}Properties"
Trick to help maintenance of HQL query.
---------------------------------------
Key: HBX-716
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HBX-716
Project: Hibernate Tools
Issue Type: Patch
Components: hbm2java
Affects Versions: 3.2beta6
Reporter: Francois Jean
Priority: Minor
Attachments: patch.txt
I'm just sending a modification I made to a FreeMarket template in Hibernate Tools
(hbm2java) to help us maintaining our HQL.
We are using a large database with more the 300 tables and we often do a
reverse-engineering of the database to keep our Java entities in synch and sometimes we
have to deal with column names change. After the reverse-engineering process, the compiler
will show errors for all the getter/setter that have change name. But it will not show any
errors in HQL using "old" attribute names.
For example if we have a table "Application" with a column
"Version_num", we would get a Class "Application" with an attribute
"versionNum" and its own getter and setter. If the column
"Version_num" change its name for "App_version_num", the new attribute
name will be "appVersionNum" with its new getter/setter. And the compiler will
show errors for old code using the getter "getVersionNum". But will not show any
errors for HQL like: "from " +Application.class.getName() + " where
versionNum = 3"
Solution:
We modify the generation of the entity to include a constant string for each attribute
name, by using these constants the compiler can flag error in HQL. The new HQL would be:
"from " +Application.class.getName() + " where "+
Application.VERSIONNUM + " = 3"
For now, we always generate these constants but it could be possible to trigger the
constants generation by using a parameter in the ant task when asking Hibernate Tools to
generate Java entities.
Template that was modified: PojoFields.ftl
// Fields name constant
<#foreach field in pojo.getAllPropertiesIterator()><#if
pojo.getMetaAttribAsBool(field, "gen-property", true)>
public static final String ${field.name?upper_case} = "${field.name}";
</#if>
</#foreach>
// Fields
<#foreach field in pojo.getAllPropertiesIterator()><#if
pojo.getMetaAttribAsBool(field, "gen-property", true)> <#if
pojo.hasMetaAttribute(field, "field-description")> /**
${pojo.getFieldJavaDoc(field, 0)}
*/
</#if> ${pojo.getFieldModifiers(field)} ${pojo.getJavaTypeName(field, jdk5)}
${field.name}<#if pojo.hasFieldInitializor(field, jdk5)> =
${pojo.getFieldInitialization(field, jdk5)}</#if>;
</#if>
</#foreach>
PS: This solution is not perfect, a better approach would be something that would also
validate at compilation time the type of association. For example, the association
"person.address.city" present in a HQL statement will only be validated when
this HQL will be executed.
François J.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: