How to contribute to the Hibernate Tools

artem · **Joined:** Fri Feb 09, 2007 6:51 pm **Posts:** 16

Hi guys,

I've done some changes in hibernate tools for my organization and would like to contribute some of them back to Hibernate.
How I can get credentials to do it?
What person I have to contact to discuss EJB3 pojo/dao generation I'd like to contribute?

Artem.

max · **Posted:** Sat Feb 10, 2007 8:35 am

you start by supplying patches through jira; and i'm the one to discuss with ;)

artem · **Joined:** Fri Feb 09, 2007 6:51 pm **Posts:** 16

Hi Max,

What do you think about next things:
1) I'd like to separate packages for entity classes, DAO, and Seam classes;
I can do it in generation code/templates (I already tested it), but I'm sure the best way is to ask user for 3 packages instead of 1;
2) I think it worth to add serialVersionUID to entity pojos;
3) I think it worth to add equals/hashCode to entity pojos every time and change algorithm to compare Ids in equals and return id.hashCode() in hashCode();
4) Seam code generation has a number of bugs and I can fix code there.

Artem.

max · **Posted:** Sun Feb 11, 2007 1:10 pm

artem wrote:

Hi Max,

What do you think about next things:
1) I'd like to separate packages for entity classes, DAO, and Seam classes;
I can do it in generation code/templates (I already tested it), but I'm sure the best way is to ask user for 3 packages instead of 1;

ask user for 3 packages ? where ? are you talking seamgen ?

note there already is a jira task for making this package control better...feel free to provide patches to that one.

Quote:

2) I think it worth to add serialVersionUID to entity pojos;

no - it is not. One should not commit to a specfic serialVersionUID value unless you actual plan to use it for ensuring serializability compability. Generating a "random" one is hurtfull.

Do you have any particular reason for wanting it ? (besides removing eclipses annoying default warning about it)

Quote:

3) I think it worth to add equals/hashCode to entity pojos every time and change algorithm to compare Ids in equals and return id.hashCode() in hashCode();

definitly not. See http://www.hibernate.org/109.html

Quote:

4) Seam code generation has a number of bugs and I can fix code there.

Are we talking the seam templates in hibernate tools or seamgen ?

The former will be deprecated/removed soon now that seamgen has reached usefullnes.

artem · **Joined:** Fri Feb 09, 2007 6:51 pm **Posts:** 16

Hi Max,
Thanks for your answer! It turned my attention to problems I missed in my previous post. But it is still possible to do it all. What do you think?
(I apologize for my slow response)

Quote:

ask user for 3 packages ? where ? are you talking seamgen ?

note there already is a jira task for making this package control better...feel free to provide patches to that one.

Yes, I talking about asking user for 3 separate packages (3 edits).
Is it OK?

Quote:

no - it is not. One should not commit to a specfic serialVersionUID value unless you actual plan to use it for ensuring serializability compability. Generating a "random" one is hurtfull.

Do you have any particular reason for wanting it ? (besides removing eclipses annoying default warning about it)

OK, let me explain. Usually after DB schema was changed, HibTools users will not change domain code manually. They could simply regenerate it from the schema, replacing prevous domain code. And, this code most possibly work in cluster environment, so it need to be serialized/deserialized then live in distributed cache.

Hibernate Tools could use function based on datatypes/variable's name. It could be, for instance:
(type1.hashCode*2^16+var1.hashCode) +
(type2.hashCode*2^16+var2.hashCode) + ... +
(typeN.hashCode*2^16+varN.hashCode)

Quote:

3) I think it worth to add equals/hashCode to entity pojos every time and change algorithm to compare Ids in equals and return id.hashCode() in hashCode();

definitly not. See http://www.hibernate.org/109.html

Please, consider this solution (using inner classes): http://art-of-dev.blogspot.com/2007/02/ ... oblem.html
I could implement it.

Quote:

4) Seam code generation has a number of bugs and I can fix code there.

Are we talking the seam templates in hibernate tools or seamgen ?

The former will be deprecated/removed soon now that seamgen has reached usefullnes.

Do you mean beta9 version or next one?

max · **Posted:** Tue Feb 13, 2007 4:54 pm

artem wrote:

Hi Max,
Thanks for your answer! It turned my attention to problems I missed in my previous post. But it is still possible to do it all. What do you think?
(I apologize for my slow response)

Quote:

ask user for 3 packages ? where ? are you talking seamgen ?

note there already is a jira task for making this package control better...feel free to provide patches to that one.

Yes, I talking about asking user for 3 separate packages (3 edits).
Is it OK?

sure; it needs fixing but you just need 1 package per exporter...

Quote:

no - it is not. One should not commit to a specfic serialVersionUID value unless you actual plan to use it for ensuring serializability compability. Generating a "random" one is hurtfull.

Do you have any particular reason for wanting it ? (besides removing eclipses annoying default warning about it)

OK, let me explain. Usually after DB schema was changed, HibTools users will not change domain code manually. They could simply regenerate it from the schema, replacing prevous domain code. And, this code most possibly work in cluster environment, so it need to be serialized/deserialized then live in distributed cache.

you don't need a serial version uid for that(unless you are talking about letting the cached objects outlive new classes + application redeployments)

Quote:

Hibernate Tools could use function based on datatypes/variable's name. It could be, for instance:
(type1.hashCode*2^16+var1.hashCode) +
(type2.hashCode*2^16+var2.hashCode) + ... +
(typeN.hashCode*2^16+varN.hashCode)

it could be an option - I don't belive in adding it blindly.

Quote:

3) I think it worth to add equals/hashCode to entity pojos every time and change algorithm to compare Ids in equals and return id.hashCode() in hashCode();

definitly not. See http://www.hibernate.org/109.html

Please, consider this solution (using inner classes): http://art-of-dev.blogspot.com/2007/02/ ... oblem.html
I could implement it.

I'm sorry but i simply cannot understand what that solution helps...you still can't put the entities in a mapped hash based set.

Quote:

4) Seam code generation has a number of bugs and I can fix code there.

Are we talking the seam templates in hibernate tools or seamgen ?

The former will be deprecated/removed soon now that seamgen has reached usefullnes.

Do you mean beta9 version or next one?

[/quote]

I should have removed it in b9.

seamgen is where new things for seam generation occur. (it uses hibernate tools to do its thing though)

artem · **Joined:** Fri Feb 09, 2007 6:51 pm **Posts:** 16

Quote:

no - it is not. One should not commit to a specfic serialVersionUID value unless you actual plan to use it for ensuring serializability compability. Generating a "random" one is hurtfull.

Do you have any particular reason for wanting it ? (besides removing eclipses annoying default warning about it)

OK, let me explain. Usually after DB schema was changed, HibTools users will not change domain code manually. They could simply regenerate it from the schema, replacing prevous domain code. And, this code most possibly work in cluster environment, so it need to be serialized/deserialized then live in distributed cache.

you don't need a serial version uid for that(unless you are talking about letting the cached objects outlive new classes + application redeployments)

Hibernate Tools could use function based on datatypes/variable's name. It could be, for instance:
(type1.hashCode*2^16+var1.hashCode) +
(type2.hashCode*2^16+var2.hashCode) + ... +
(typeN.hashCode*2^16+varN.hashCode)

it could be an option - I don't belive in adding it blindly.

So, OK to do such option?

Quote:

3) I think it worth to add equals/hashCode to entity pojos every time and change algorithm to compare Ids in equals and return id.hashCode() in hashCode();

definitly not. See http://www.hibernate.org/109.html
Please, consider this solution (using inner classes): http://art-of-dev.blogspot.com/2007/02/ ... oblem.html
I could implement it.

I'm sorry but i simply cannot understand what that solution helps...you still can't put the entities in a mapped hash based set.

The main idea is that, sure, you will be not able to put entities into hash set before saving them, but after saving you can put innerClass objects in hash set (not entity objects itselfs), which have already equals and hashCode implemented and link to underlying entity. The problem is that you can not have such equals/hashCode in the entity class.

If I become more clear I could do it as an option too.

max · **Posted:** Tue Feb 13, 2007 5:51 pm

serialVersionUID is ok as option IFF you can find a stable way of generating the number.

the equals/hashcode I see no usage for. Who says you can't have an equals/hashcode on an entity ? It just cannot use *id* as it way to compare things.

artem · **Joined:** Fri Feb 09, 2007 6:51 pm **Posts:** 16

max wrote:

serialVersionUID is ok as option IFF you can find a stable way of generating the number.

I could suggest the next way:
If we have next n fields:
typeName_1 fieldName_1;
typeName_2 fieldName_2;
...
typeName_n fieldName_n;

we could calculate
serialVersionUID =
(fieldName_1.hashCode()*2^32+typeName_1.hashCode()) +
(fieldName_2.hashCode()*2^32+typeName_2.hashCode()) + ... +
(fieldName_n.hashCode()*2^32+typeName_n.hashCode())

where fieldName_i.hashCode() is hashCode() of fieldName_i string
(for int id; it will be "id".hashCode())
and typeName_i.hashCode() is hashCode() of typeName_i string
(for int id; it will be "int".hashCode())

so, we will be independent from
1) JVM
2) fields order
and depend on
1) field types
2) field names

Is this way OK?

max · **Posted:** Tue Feb 13, 2007 7:05 pm

order is important in serialization - aint it ?

artem · **Joined:** Fri Feb 09, 2007 6:51 pm **Posts:** 16

max wrote:

order is important in serialization - aint it ?

ops...

serialVersionUID =
(fieldName_1.hashCode() XOR typeName_1.hashCode()) * 31^0+
(fieldName_2.hashCode() XOR typeName_2.hashCode()) * 31^1 + ... +
(fieldName_n.hashCode() XOR typeName_n.hashCode()) * 31^n

now it is dependent on fields order

greenbee · **Joined:** Mon Mar 17, 2008 2:50 pm **Posts:** 24

I guess not, as 1.5 years gone by and this did not make it to the current releases.
BTW, I have done some changes in this area as well.
I created PojoSerialUID.ftl file with the following content:

Code:

<#macro uid bean>
    <#local b = 31>
    <#assign c = 1>
    <#foreach field in bean.getAllPropertiesIterator()>
        <#assign c = (c + field.name.hashCode() * field.propertyAccessorName.hashCode())*b>
    </#foreach>
${(c%1000000000000000000)?string("###########0")}L;
</#macro>
    /**
     * The serial version UID of this class. Needed for serialization.
     */
    private static final long serialVersionUID = <@uid bean=pojo/>

I then modified Pojo.ftl to include this template file and it works for me like a charm. Feel free to use it as well

max · **Posted:** Wed Aug 13, 2008 6:25 pm

Serialversion should not be done by default; that is why it is not included in the codebase.