Hibernate version: 3.1-rc1

Mapping documents:
<?xml version="1.0" encoding='UTF-8'?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd" >
<hibernate-mapping package="nl.anwb.happi.acc.model">
<class name="Relatie" table="relatie">
<meta attribute="interface">true</meta>
<meta attribute="generated-class">nl.anwb.happi.acc.model.hibernate.HibernateRelatie</meta>
<id name="id" type="java.lang.Long">
<generator class="native" />
</id>
<joined-subclass name="Accommodatiehouder"
table="accommodatiehouder">
<meta attribute="interface">true</meta>
<meta attribute="generated-class">nl.anwb.happi.acc.model.hibernate.HibernateRelatie</meta>
<key column="id" />
</joined-subclass>
</class>
</hibernate-mapping>

Description:
When I run hbm2java I expect the following interface hierarchy:


However, hbm2java generates a faulty Relatie interface instead of the Accommodatiehouder:


Is this a bug or do I use the wrong metatags?

Kind regards,
Bas

hmm seems we have some bad logic about appending class/package names when using generated-class.

please put this in jira.

I didnt notice this at first glance but you have a couple of errors.

first "generated-class" should have inherit="false" otherwise it will be appended to the <joined-subclass>

second you list the same generated-class name for <class> and <joined-subclass> ...that does not make sense. They should be separate.

Hello Max,

Excuse me for the typo. I added inherit=false to the "generated-class" meta tag and the generated interface is almost right. It only extends the super-interface from the wrong package:


Expected:

BTW: public is a redundant modifier (according to CS).

Thanks again,
Bas

well - somewhere your interface/class should implement the mapped entities.

generated-class is to allow you to write a subclass that extends the generated-class ...subclasses of that should extend your generated class.

and yes public is a redundant modifier, but I hate interfaces that is not explicit about their "public and staticness" :)

i think you need to have some separate templates and use those to solve your generation issues (which looks very specific/weird from my pov ;)

Hello Max,

Perhaps it's interesting to explain why I chose this (rare) generation strategy. Currently I'm working on a project which is bound to the following criterion.



My first approach was to generate domain classes with the default hbm2java settings. However, when behaviour was added to the domain classes and something changed later on in the mappings document, so that the domain classes had to be re-generated, the added behaviour was overridden.

To overcome this issue I decided to generate an abstract class hierarchy so that behaviour could be added to their implementation. At first this seemed an excellent separation of persistent and inferred behaviour. However, I couldn't implement inheritence. An example:



My current strategy is to generate a full interface hierarchy and to implement all behaviour by hand. For example:



Please let me know if you have any suggestions!

Kind regards,
Bas

why dont you *just* use "generated-class" ? this is exactly the usecase it is there for!

no need for interfaces etc.

Because my teammembers want to add behaviour to the generated classes and they want to keep the class hierarchy in-sync with those classes. You can't have both without multiple inheritance as I illustrated with the abstract class example above.

I realise that my strategy is far from optimal and I'm open for any alternatives.

Kind regards,
Bas

Huh?

B extends A is mapped in a hbm.xml

normally that would create

class A {}
class B extends A {}

if you adds generated-class meta attribute to each of these,e.g. BaseA and BaseB the following will be created:

class BaseA {}
class BaseB extends A {}

Meaning that you write the A and B class which look like:

class A extends BaseA {}
class B extends BaseB {}

There is *no* multiinheritance here and you mapped stuff is kept in sync and developers can add their custom stuff.

beaware that this model has an advantage (from my POV) that you only need to add generated-class to those classes when you actually needed and the hiearchy/dependencies will still be in sync.

OK, here comes the problem: if you add method m() to class A then A.m() is not overloaded to class B. Losing this OO principle is unfortunately not an option.

Kind regards,
Bas

huuh ? why is A.m() not overloaded to class B ?

Oh, I see!! So the class hierarchy is:

B -> BaseB -> A -> BaseA

If I generate BaseA and BaseB with the generated-class meta-tag, how do I force BaseB extends A?

Thanks for your smart thinking!

Bas

That is the whole trick about generated-class! It only tells that it should generate another class with another name - it does not affect how other classes refer to it; which make it usable for just your scenario!