I am getting the following warnings when running Middlegen 2.1:

[hbm2java] (hbm2java.ClassMapping 693 ) Could not find UserType: com.bmgch.cars.model.CostActual. Using the type 'com.bmgch.cars.model.CostActual' directly instead. (java.lang.ClassNotFoundException: com.bmgch.cars.model.CostActual)

[hbm2java] (hbm2java.ClassMapping 693 ) Could not find UserType: com.bmgch.cars.model.Budget. Using the type 'com.bmgch.cars.model.Budget' directly instead. (java.lang.ClassNotFoundException: com.bmgch.cars.model.Budget)

The files seem to get generated fine, though. What does this message mean?

Gene

Its likely a Classpath issue for HBM2Java trying to fine those types to get the Java type from the class. Its backup is to use the User type class name.

Thanks a lot David.

Perhaps you could answer two other related questions, while we are at it :-)

1. What does plainCompoundKeys property in the Hibernate plugin do (and perhaps, how does it work together with the genIntegratedCompositeKeys property)? I saw the description in the doc, " If this is true, the classes will have plain compound keys enabled", but I don't think I understand that. Could you elaborate?

2. Is the version of the Hibernate plugin that is included in the Middlegen 2.1 distribution the latest? Or is there a newer version (somewhere in CVS, perhaps) that I would be better off using? And if so, where can I get it?

Thanks.

Gene

1) (a) plainCompoundKeys means it will generate the compound keys as pure property only objects, eg, there is no key-many-to-one properties as a part of the key. This is the best approach.

(b) genIntegratedCompositeKeys means they Compound key is a part of the parent domain object, eg, no separate class representing key portion. My preference is to first not use compound keys, in the avent that cannot be avoided, use plainCompoundKey that are not integrated.

2) R5 (2.1) was the latest release, there are a number of changes and enhancements in the CVS version - I just have not completed what I was aiming to have done by the next release but it is worth using the latest. Get the CVS code and build from there. Middlegen site will tell you the CVS details (which is standard across SF projects).

David, thanks again.

I apologize for bombarding you with questions - I promise it'll be over soon. :-)

I am still trying to understand the behavior of Hibernate plugin using the plainCompoundKeys property. Let's take a sample table (columns comprising the composite key are underlined):

FOO
Column1FK1
Column2FK2
Column3
Column4
Column5

When I run Middlegen, I get two POJOs with the following properties:
class FooPK, with properties Column1FK1, Column2FK2, Column3,
and class Foo with properties Column5, Column1FK1, Column2FK2.

In other words, each foreign key column is translated into two separate properties: one in the FooPK class and another one in the Foo class, the only difference being the type (primitives and object types, respectively.) I understand this is done in order to reduce the complexity in the mapping of the PK class by moving the association mapping to its "parent" class. But as far as my Java application is concerned, those are two completely unrelated properties in two separate classes, thus they need to be populated separately! Is this the intended behavior, and if so, what's the reasoning behind it? Or maybe the property in Foo is intended to be some sort of wrapper around the one in FooPK?

Perhaps what would really help is some example CRUD code, showing how these objects would be used in a DAO.

Again, thanks in advance.

Gene

in the class Foo you should also have property Column4.


In anycase, it is correct and this is the preferred approach but you could also map it so that the two many-to-one PKFK properties were accessible from the Key. I would not do it and leave it the way you have it. It separates the Key and the associations which makes life easier and its more flexible if you choose to change the mapping. What you will see is the the parent has the many-to-one mappings as update=false insert=false as these relationship values are maintained through the Key. You are right in that is a sort of wrapper where the parent has the actual domain object while the key has the primary key segment.

In CRUD type code you treat the Key just as you would any key (such as a Long), eg, loading the object.
FooPK key = new FooPK(Column1FK1Val, Column2FK2Val, Column3Val);
Foo parent = session.load(Foo.class, key);
parent.getColumn2FKDomainObject(); // Domain object

Saving a new Foo
Foo newone = new Foo();
Column2FKDomainObject c2do = new Column2FKDomainObject();
Column1FKDomainObject c1do = new Column1FKDomainObject();
session.save(c2do);
session.save(c1do);
newone.setId(new FooPK(c1do.getId(), c2do.getId(), new Long(1));
session.save(newone);

Hope this helps.