Hi!

I've encountered another problem with hbm2java - the generated constructors don't follow the original and most probably meaningful order from the mapping file. For example, if an Address has a State property, the tool will put the state at the end, which is not desired. I personally don't understand why relationships should always be at the end?

Is it so important ?

If you add extra properties and it re-arranges them randomly, you need to update the signatures everywhere! And also, as I mentioned in my first post, the intuitive order or arguments saves time and makes the code cleaner and easier to read.

You can check the hbm2java source, it may not be difficult to solve or to find the reason.
Max may answer.

I'll speculate w/o looking into the code that he's looping one-by-one thru all possible children elements generating Java properties (<property>, <one-to-one>, <many-to-one>, etc.), rather than looping thru the children XML elements in their physical order and then calling the appropriate property code generation code. Anyways, I'll try to patch it myself and submit it to JIRA. I shouldn't be a big deal!

Probably I have all these issues, because I use the mapping file as my domain model and then generate .sql i .java from it. If I use POJOs with XDoclet, I wouldn't have all these issues, but probably I'm not alone and making hbm2java more flexible will just add more value to Hibernate.

Of course, this patch will have a parameter for backward compatibility.

you analyzes is correct.

Add a JIRA for it when you have a patch and i'll apply it ;)

+1

This is importent for me too. Working is more smooth if the constructor-fields are in the same order.

If you found a solution please let me know, else i might have a look into hbm2java.

Looks to me as though hbm2java doesn't shuffle the properties, but instead lists them in the order:

id
composite-id
properties
one-to-one associations
many-to-one associations
collections: list, map, set, bag
components
subclasses

This is from reading ClassMapping.java.

I think that within each of these categories, hbm2java does not reorder entries. So the order is deterministic, but the mapping order is reshuffled by entity type into this order.

Cheers,
Rob

it should be doable to do it "in order" but the processing will just need to iterate a whole lot more ;)

Honestly, I kind of like it as it is now -- it keeps the Java code nice and organized. Adding a property/field/association/whatever doesn't randomly shuffle other entries around; it's just that the new entry gets grouped with other entries of its type. So there is no risk that adding a new entry will reshuffle *all* current entries, which is what the original poster thought would happen.

Cheers,
Rob

Rob,

Of course it reorders them! If I put them in one order in the mapping file and it changes it, yes, it definitely reorders them, because I decide what's the meaningful order! Max & co. did it this way, just because it was easier! Do you reorder your fields in the class by type, for example?!

I understand that you don't like it the way it is. It should be pretty easy for you to write a patch for it :-) It's all right there in ClassMapping.java.

Personally I don't look very closely at the hbm2java-generated files -- I always use <meta generated-class> to allow me to subclass the generated files, so I can add my own methods and business logic to the subclasses while still being able to regenerate the generated classes at any time. So I am barely aware of what the generated code looks like :-)

Cheers!
Rob