> I know that many people hate hibernate because they think > it's too much magic, it's partly true but I'd say it's > also probably the most misused framework on the planet.
I guess both the hate and the misuse come from misrepresentation. The "Hibernate in Action" book even goes to great lengths to explain how to do "long-running conversations that span multiple transactions". > There are countless of posts everywhere showing that people > rely too much on lazy loading and long lived sessions, they > would like to deal with their database just like if it was > fully loaded into memory, Well, there's the promise that "you can code with entities just like with Pojos". In some ways you actually can, but in others you can't, and the docs don't spell out the border. Again, that's more a documentation problem. > run out of resources and experience slowness because they > want to stay in an object oriented world and totally ignore > SQL, stored procedures. That's yet another issue. You can't use stored procedures if you want to keep migration costs under control. Or, put another way: If you use stored procedures, you should keep the business logic in the database, and then any shitty ORM will do and you don't need Hibernate that much anymore. > Imho hibernate itself is rarely the unique cause of > disaster, you can carefully check display and check > the SQL output or every operation, and if it's close > enough to what you would write yourself, it can't be bad. Well it isn't. It's generating different projections and joins that those that I'd do, and I can't easily make it generate the code I want it to. Now if Hibernate were better at generating good SQL than I am, that would actually be a good thing, but Hibernate's SQL is sometimes very inferior. Hibernate also doesn't even begin to handle bulk queries. In the end, you write your business logic twice, once in Java for Hibernate and once in SQL for the nightly batch runs... THAT part of the impedance mismatch remains in full force. Now again that's where Hibernate collects hate points: The docs promise that it's the end to that mismatch. In general, I think Hibernate fails to clearly spell out the limits of what it can do, so people come to it with expectations that Hibernate can't match. Not the peoples' fault I think. > Suppose I want to load a collection of objects with 2 > or more one-to-many relationships, I have the following > options > > 1) Fetch a collection of records from the main table, > and use fetchX methods to navigate which is ok for 1 or > 2 records but totally inefficient when used in a loop Hehe, no, you wouldn't want single-record fetches. You could fetch in groups, using WHERE (pk-fields-of-child-table) IN ((fk-values), (fk-values), ...) where fk-values are those foreign-key values found in the main table records you already have. It's mildly ineficient because you need to transmit all the foreign key values back, but you can run the queries in parallel. For interactive use, the latency isn't very nice because each table requires its own round trip; you want a single query for that use case. > 2) Issue one query + 2 correlated queries queries and > do the mapping in memory, which is error prone, > requires a lot of code and has a huge negative impact > on my productivity. Is Jooq not able to notice that the same record got returned twice? It should, but there are complications with unique keys that I'm not sure how they finally got sorted out. > Given enough free time, I could think of a way to > implement caching for the fetchXXX methods, but past > the 2 or 3 basic use cases, I'd be reinventing hibernate. You essentially reinvent Hibernate's first-level cache. Which would be a Good Thing IMHO. I've been wanting to have direct access to that cache all the time: iterate over its records, inspect it for existence of a record, flush exactly what I want flushed, inspect the staleness status (known-current, known-stale, unknown), that kind of stuff. (That's one of the things I dislike about Hibernate: it consists of a lot of building blocks, but the individual blocks aren't accessible, it's all hidden behind a facade and you can't properly look into what it's doing, or use some of its mechanisms in isolation where it would be useful.) > It doesn't mean there isn't any solution in between > (I mean between JPA and Jooq), an excellent .Net > commercial ORM called LLblgen which is also based on > generated code offered a great, predictable graph > loading AP without relying on obscure caching mechanisms. Sounds intriguing. Are there any whitepapers around? -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
