Re: [Andromda-devel] hbm.xml map to Impl class in hibernate cartridge - proposal of two ways to improve

[Chad B. <cha...@gm...>]

Sverker Abrahamsson wrote:

> Hi
> I recently started to look at 3.0RC1 and I quickly discovered that 
> it's a lot of differences compared with 3.0M3. I managed to get my 
> project refactored for the new structure, most changes are logical 
> although some were a bit odd, and eventually I got it to compile.
>  
> However, when I deployed it none of my queries worked. Analyze showed 
> that instead of the abstract class name, e.g. Category, the new 
> mapping use the Impl class, i.e. CategoryImpl so my query would be 
> something like "from CategoryImpl as category ...", which is very ugly...
>  

If you used the OCL queries you wouldn't need to worry about this (it 
translates it for you to the correct implementation): I still think 
embedding hibernate queries in your model is a bad idea, what if you 
change technologies...you'll need to rewrite all your queries in your model.

> I see two ways to solve that. One is to do the same kind of mapping as 
> xdoclet do, where the mapping is done on the abstract class Category 
> with CategoryImpl as subclass. I did a patch for that, where I also 
> formatted the template a bit nicer (so that now it's acctually 
> readable). It now works perfect with my queries. The patch for that 
> change is attached as andromda-hibernate1.patch.

I think its a bad idea to make each table have a hibernate specific 
descriminator column.

>  
> However, my changes only work fine when using 
> table-per-class-hierarchy mapping strategy since it require use of 
> discriminator column to specify that it is the Impl class that should 
> actually be loaded. When using other mapping strategy, I was back to 
> mapping to Impl class.
>  
> That disturbed my estetic sence so I gave it a bit more thought. 
> Whatever solution should work with all mapping strategies with no 
> extra flaws for any of them. So then the best would be to call the 
> abstract class e.g. CategoryBean and the impl class Category. The pro 
> is that it then work the same with all mapping strategies, the con is 
> that it breaks the AndroMDA naming strategy that all concrete 
> implementation classes ends with Impl.
>  
> Probably someone will argue that it's not a problem to write 
> CategoryImpl in the query but I claim that what should be used in the 
> query, and everywhere else in the code, is the same name as is used in 
> my class diagram. Everything else would be unlogical and ugly

> Anothter issue is that hibernate cartridge use table-per-subclass 
> mapping strategy as default while Hibernate recomend 
> table-per-class-hierarchy. It can of course be discussed which is the 
> best strategy, but in my humble opinion the default should be the 
> strategy recomended by Hibernate.

Its very easy to change the default yourself using the namespace, just 
use this property: hibernateInheritanceStrategy 
(http://team.andromda.org/docs/andromda-hibernate-cartridge/namespace.html)

>  
> I haven't yet created a patch for the second variant, before doing 
> that effort I would like to hear the opinion from the developers.
> /Sverker