|
From: Chad B. <cha...@gm...> - 2005-03-15 00:01:09
|
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 |