Yeah, but this is what proper statistics are good for. The "solution" is just a nasty hack.
If the query optimizer chooses an obviously wrong join order than something is wrong with the statistics. The proper way is to fix those.
Three reasons suddenly come to my mind why using this "hack" is wrong:
1.) You have to modify every single query in your application.
2.) The queries become less readable. Your code will be less maintainable.
3.) The behaviour is unpredictable. New useful indxes might not be used; the query optimizer might realize in later versions that multiplying with 0 is always 0...
Don't cure the symptoms. Fix the problem.
Regards
Felix
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043090#4043090
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043090
"christian.bauer(a)jboss.com" wrote : By the way, you can always use the TransactionalSeamPhaseListener and @TransactionAttribute(REQUIRES_NEW) to suspend the existing transaction during a particular method call in INVOKE APPLICATION. Your method then executes in a new transaction context - which is committed when the method returns.
|
Have you actually tried that? I'm asking because it definitely does not work with my application (Seam 1.1, JBoss 4.0.5).
I also recall that somehwere Gavin notes that in particular this type of transaction attribute is not supported by the @Transactional notation, which I guess you would have to use in Seam instead of @TransactionAttribute?!
http://docs.jboss.com/seam/1.1.1.GA/api/org/jboss/seam/annotations/Transa...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4043088#4043088
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4043088