I'm not convinced about OCL queries. I've read about it on AndroMDA site and at http://www.klasse.nl/ocl/. However, I've not seen any examples of how I can control which classes are acctually loaded in a query. When my web layer fetch data from the business layer, I want to optimize loading of the data hiearchy which is sent back using fetch in the query. I typically do queries like "from Category as category left join fetch category.content where ...", how can I accomplish that with OCL? Specifying eager loading in the mapping is not the answer since sometimes I want to load Categories without loading Content.
Ok, when it's about Category and Content it's not such a big deal but I have another relation between FileMetadata and FileContent where the latter can hold megabytes of data in a blob so I don't want it to be loaded from the db unless it should be used. There is a huge difference in performance in this case. (I am having problems that the FileContent is loaded with FileMetadata anyway under some circumstances but that is a different story which I'm also working on trying to solve.)
Your note that it would be a bad idea to make every table have a descriminator column is valid, that's why I started to think about the second solution which I now think is better. I was at first affected in my thinking by the way xdoclet do.
Still, I think that the tool should not mandate one way or the other. It should give the choise to the developer without any extra negative or unlogical impacts.
Your point about namespace taken, I've changed in my project now and let my case rest on that issue.
/Sverker
----- Original Message ----- From: "Chad Brandon" <[EMAIL PROTECTED]>
To: "Sverker Abrahamsson" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Tuesday, March 15, 2005 1:00 AM
Subject: Re: [Andromda-devel] hbm.xml map to Impl class in hibernate cartridge - proposal of two ways to improve
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
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Andromda-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-devel
