Sverker Abrahamsson wrote:
Hi again,
you are right that Hibernate perform better than CMP out of the box
but tuning the queries and loading still can make a big performance
impact. The systems I work with are telecom and need to be able to scale.
Anyway, I've now come up with a patch that I think is general enough
for you. What I did was to add a setting to andromda-metafacades.xml
called implNamePattern with default value {0}Impl. Then I can easily
change that parameter and entityNamePattern to get the behaviour I
want. All the templates are well written and pick up these settings.
It's beautiful!
Sure that works..I'll apply it :)
Attached is that patch together with a patch for the templates. The
latter is only for nicely formatting the templates so that it is quite
a bit more easy to read. You can use it if you want, otherwise just
dump it.
/Sverker
----- Original Message ----- From: "Chad Brandon"
<[EMAIL PROTECTED]>
To: "Sverker Abrahamsson" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Tuesday, March 15, 2005 3:20 AM
Subject: Re: [Andromda-devel] hbm.xml map to Impl class in hibernate
cartridge - proposal of two ways to improve
Sverker Abrahamsson wrote:
Hi Chad,
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.
You're right: you can't accomplish this with OCL, you don't have
that fine grained control (however most of the time does it matter,
I don't think it does).
Most of my queries contain fetch statements to optimize loading. The
ability to do so was one of my main reasons to switch over from EJB
CMP, the biggest performance problem with CMP was the difficulty to
optimize loading. Properly designed Hibernate queries gives
performance that is not far behind direct SQL queries and gets even
better with the caching. With CMP the difference was magnitudes.
I also switched to hibernate from CMP because of performance as well
as ease of use, I think even without fine grained adjustment of
queries hibernate performs much bettern than CMP.
So no, unless OCL support control of loading then I don't think it
will scale unless you only make very simple queries all the time.
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.)
For those few cases, I would still think overriding the queries in
the code is actually cleaner than having the queries embedded in
your model.
As I wrote above, most of my queries load a hierarchy of classes. I
don't put the queries in the model, instead they currently are done
directly in the SessionImpl. What could make sense would be to
instead add finder methods to the entity and put the queries there.
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.
I don't think your 2nd implementation is the best way to handle it
either, we shouldn't base the class names on the fact that you'll
need to omit Impl" from your query (especially since all other
cartridges already use that naming convention).
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.
I don't think there aren any "illogical" impacts of the current
implementation. The tool is also not mandating anything, the
cartridges reflect what we as AndroMDA developers think are best
practices, the user is free to override or change templates as
he/she sees fit....the cartridges are usually meant to be customized.
That AndroMDA give the possibility to use customized cartridges is
very good. However, I try to avoid using that to not get out of sync
with future development and to be able to contribute back any ideas
I come up with which might be generally usable.
More or less every developer have their own idea of what is best
practice, sometimes based on fact, sometimes it's personal
preferences. Still, a tool should as far as possible be flexible to
support as many as possible without increasing complexity.
Of course.
The current naming scheme seams to be a legacy from xdoclet, if
instead following common praktice for java naming the abstract base
class would be called CategoryBase and the concrete class be called
Category.
I agree with you that all cartridges should use the same naming
scheme and it's probably not a good idea to start changing
everything. I will see if I can figure out a way to do it without
major changes, otherwise I will have to maintain a custom cartridge.
If you can come up with something let us know.
At the end of the day it's your project, you make the call..
/Sverker
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
