|
History
| Log In
|
|
|
|
This workaround is actually incorrect and will produce bad results. Specifically, if you do have a record in the tradeprices table that matches the criteria but not the tradeid, you will NOT get a null record you expect.
What is REALLY needed is implementation of the "with" keyword from Hibernate 3.0. Hibernate filters should also, in my opinion, add their conditions to the "on" clause.
So should the were clauses added on collections in the mapping file when such a collection is fetch joined. The same applies to the were clauses of classes.
Just a quick question, thinking of making a own simple patch for this for the time being.
It looks like JoinFragment.AddFromFragmentString() is the place which adds the "with" statment right? I would be very interested in an additional keyword in NHibernate's HQL as well. (Like the 'with' keyword that exists in Hibernate (Java version thus) HQL, like it is documented here:
http://www.hibernate.org/hib_docs/reference/en/html/queryhql-joins.html This could be extremely usefull in combination with DTO's. :) At the moment I work around this issue in a similar fashion like Dragos Nuta posted here, but this is indeed not always a good solution. This is very important issue. We can workaround most cases with complicated subqueries, but it causes serious performance issues , especially on huge tables.
Any hope to implement it in the next version ? Probably it will require the AST, which is not yet planned.
I have read Nels_P_Olsen's forum post: http://forum.hibernate.org/viewtopic.php?t=961233#2375800 - cost is "currently estimated at $25k" , way too much for small firm (6 programmers) . Going for native SQL in critical cases is still cheaper. Maybe someone can have a sort of whip-around for this feature than we can spend some $ on it...
I am trying to get funding for this revived. It was backburnered last winter because management wanted to look into Microsoft's Entity Framework to replace our use of NHibernate. By summer they decided against that.
What about having two or three different companies sponsor this? One point: The job is more than just porting AST.
Nels,
Yes, having several companies sponsor this feature is possible. Since I originally opened this issue 3 years ago, I've found a few workarounds... 1) use named queries with SQL having any join syntax desired... 2) use all oracle outer join syntax in HQL with no mix of ansi join syntax... 3) simply remove the extra condition in the HQL, which would return more rows than desired, then manually eliminate unwanted rows in the business logic.
well... what if you had to also order the result set like this.
SELECT customer.id from customer as c left outer join adddress as a on (a.customer_fk == c.id and a.add_AddressType = 1) order by a.Street if you remove the extra join condition then the ids would be retrieved with wrong ordering. if you wanted to elminate the unwanted row then you would have to: - drop the extra condition (a.add_AddressType = 1) - get also the ordering row (a.Street) - eliminate the repeating entities by hand - order the remaining entities by hand this is not a problem if the set is small but what if you return 10k customers and each having several, one or no addresses. instead of only getting the small ids, the query will be at least a little less efficient, and the elimination of duplactaes and ordering will use extra cpu and ram. does anybody have any solutin to this in HQL?! Luckily we have ISQLQuery --> http://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/querysql.html
We are working on it
http://fabiomaulo.blogspot.com/2008/12/artorius.html Check the grammar and passing tests and wait for the final solution. |
|||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Critical
Allow expansion of the "on" clause in joins.
from trade t
left join fetch t.tradeprices tp
where t.portfolio=53
and (tp.tradeid is null or tp.effdate >= '1-Jul-2005')
Not a solution but a workaround..