Christian Bauer

author
+ Follow
since Aug 31, 2004
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Christian Bauer

I have not been back to the Hibernate forums for issues because the attitude from yourself and others has been extremely poor



Oh yeah, and I'm out of here now. Last time I was called an "ass" for helping someone. Now my attitude is "extremely poor". Ignorance is king.
Dude, you repeat again some "distinct duplicate" thing that just doesn't exist. If you query with a join fetch, you get duplicates. No "distinct" clause will make this go away. You don't have to write your own SQL for that, because the SQL is no different than HQL or QBC. It's the same. I think you are looking for "new HashSet(q.list())", if you want to make an (inner|outer) fetch join result distinct from an object graph perspective.

When it comes to database stuff, Vinnie completely understands the difference between the joins, in database terms.



Since you (or someone else) deleted his statement about "inner joins avoid duplicate records from the driving table", which is clearly false, nobody can tell. But I assure you that inner vs. outer join is a common problem for many people, surprisingly. Even the authors of Hibernate Quickly didn't understand it and tell readers to use inner joins all the time for eager graph fetching (they promised to fix this in errata). To repeat it a last time: the type of join makes no difference for the presence or absence of duplicate information. The difference is in the inclusion of data in the result that doesn't match the join condition, if an outer join is used. No Hibernate at all, basic SQL.

Other misconceptions that came up in this thread, about collections, sorting, query results, distinct projection, etc. are basic things in any database application, not related to Hibernate. By the way, you can write a complete application without ever mapping a collection. The only association mapping that is really needed is many-to-one. Every collection mapping is a conscious design decision you make, for convenience. If it is not convenient, don't do it. Use an explicit query (which, in Hibernate, behave exactly like SQL).

Also, I've only replied because "Hibernate Hell" is not something I'd leave uncommented in any forum. Repeating over and over what I explained in ample detail in thousands of pages of documentation already is however not something I can spare more time for, so I'm out of this thread now and back to writing more documentation... hoping that someone reads and understands it.
You still don't seem to understand the difference between an outer join and inner join. It has nothing to do with duplicates.

If you load Orders and all their LineItems, you can use an inner or outer join fetch. Both results contain duplicate Orders, as each Order has potentially several LineItems. The difference is simple: With an inner join, only Orders that _have_ LineItems are retrieved. With an outer join all Orders, with or without LineItems, are included. That's why you'd almost always use an outer join for eager fetching of object graphs, unless you really know what you are doing.

Your statement about "duplicates in a fetch=join mapped collection" is... wrong. Hibernate does not do this - in fact, it would break all Hibernate applications if true. My guess is that you are confusing queries and mappings. As you haven't shown any code or mapping, its impossible to figure out what you are missing exactly.

For the rest of your posting I don't have the time to elaborate. If you don't want to continue hand-waving about your problems, I suggest you visit the Hibernate forum and post the required information (code, mappings, etc.), so somebody who has more time can have a look. Don't name your posting "Hibernate Hell" though.

If you are comfortable with breaking data independence, by all means, use an object database. A nice side effect is that when the software breaks down in a few years, I get paid to migrate it to a real database
"1. Fetch depth is basically hard-coded, you can't specify this when you query so your queries are either way too much or too little for what you're trying to do...if you're using joins and such."

There is no "hard coded fetch depth" in Hibernate, you can fetch any graph you like with the minimum number of SQL queries. Your statement is too vague to go into more detail about the problem.

"2. Left joins are used in the place of inner joins by default - the only way around this is to use a funky HQL query to join the objects and the results are an Object array...not very flexible...I'd like to be able to use inner joins as easily as outer joins are in mapping files."

Sorry, but inner joins don't do the same as outer joins. There is a reason why outer joins are used for eager graph loading. An inner join would not retrieve all the objects. If you get an Object[] back from a Hibernate query you simply didn't specify a SELECT clause or a Projection (Criteria). This system _is_ flexible, if used correctly (and its the same as in SQL, really).

"3. To get unique results you're forced to use a HashSet instead of a List in your domain objects...otherwise you have to code around it inside of your app...which is tedious and ugly."

I don't really know what you mean here, certainly "results" from a query have nothing to do with the collection design in your static domain model.

"4. It isn't simple to just return a single field or a select number of fields in an object like you can w/ a SQL query...sometimes I just need to populate form values w/ smaller amounts of data...Mark...you posed a solution for that a while back but again...you were designing *around* Hibernate...shouldn't have to do that w/ *any* framework."

Well, since it seems you don't use SELECT or Projections, it probably is difficult to select only the things you want in a query. Again, this statement is very vague and I don't know what else to answer.

Frankly, I've seen many people try to learn Hibernate and see how they make progress. I'm sorry to say that you are possibly trying to do many things at once, too quickly, and at the same time you are skipping some of the basics. Don't blame the tool if this approach doesn't work.

By the way, you can use Hibernate just like iBatis if you think that will be easier. Check this blog entry and the new StatelessSession in Hibernate 3.1: http://blog.hibernate.org/cgi-bin/blosxom.cgi/2004/08/23#customsql
You can't use pagination with an outer join fetch. If you start thinking about the SQL and how the resultset looks like, it should be quite obvious why it doesn't work.
Set resultSet = new HashSet( q.list() );
Of course you can use generics on any List, Set, Collection, or Map, that is managed by Hibernate. If those standard interfaces are not enough, you can as well extend Hibernate by implementing the PersistentCollection interface.
Some factual corrections to the statemens made by Mr. Bollinger.


The hibernate forums are horrible. [removed my own hateful remark] I've been scorned several times on the hibernate forums.



This is not true. Your posting history on the Hibernate forum (http://forum.hibernate.org/search.php?search_author=gdboling) shows that you started 13 threads. Only one of them did not get any answers (not unusual for a forum with more than 150 questions/day). Some of your postings you answered yourself a few minutes later. In other threads you personally thanked David, Steve, Gavin, and me, for the help we provided you (and quite quickly, I might add). In not a single thread have you been "scorned" by anybody.

Personally, I think it would be great if you would stop calling people who helped you "asses" and something they spend a lot of time on "horrible".


[removed statement that was based on bad information and lack of research by myself]



This is not true. The page in question ("Hibernate with Spring" or something) was removed after

1) I made updates to the 2 year old page, adding content for Hibernate3, effectively showing that many things Spring did (quite well) for Hibernate2 are no longer necessary.

2) Juergen Hoeller, a prominent Spring developer, requested the page to be removed.

The reason certainly wasn't that we want people to "pay for JBoss", which would be quite difficult - it is free software.

---

As for the original poster: Nobody forces you to use an ORM tool. If it doesn't work for you, don't use it.
[ September 23, 2005: Message edited by: Gregg Bolinger ]
Thanks, a nice forum.

For all those who still want to get a copy of Hibernate in Action: we are having a users poll/survey during the next 4 weeks with free copies to win. Just check www.hibernate.org during the next week.
Don't know, never tried it. It is using persistent superclasses, if I remember correctly, so its' non-transparent. I don't have any opinion about it.
It's a sales-seminar. I wouldn't want to attend that
BTW, thats from Hibernate in Action