2013/7/29 Durchholz, Joachim <[email protected]>
> ** > There are various things that cause difficuilties in Hibernate, and that I > hope will be easier with Jooq (still not using Jooq yet, unfortunately): > When will you finally use it! :-) I'm looking forward to tons of feedback from you, once you're starting to delve into details... > 1) Session demarcation. Any exception invalidates the Session, which means > you lose the running transaction and the only recourse is to recreate a > Session (easy), reload all data (now where's that promise you can code with > entities as if they were standard Pojos...), redo any modifications (bad if > that was a lot of work) and commit again (that's easy, again). I hope that > Jooq does not tie transactional logic to any fragile resources like that. > Hmm, I'm surprised that you have to reload all data when you get an exception. It's a common pattern to try to insert something, check for a constraint violation, and then insert something else or update something. (I know, race conditions, but sometimes that's the easiest way). So you're saying, with Hibernate you cannot make use of exceptions from constraint violations, or raised from stored procedures? jOOQ does not interact with your sessions / transactions / connections directly. Since jOOQ 3.0, you're in full control of those lifecycles through the ConnectionProvider SPI: http://www.jooq.org/doc/3.1/manual/sql-building/dsl-context/connection-vs-datasource There are no plans of adding anything like transaction / session support any time soon. Other tools do that much better. > 2) It's possible to control which dependent entities are autoloaded in > Hibernate when loading a main entity, but the API stinks. Several layers of > fallbacks, needs twiddling in at least two places which use gratuitiously > different terminology, and in some situations the setting is advisory only > i.e. Hibernate's behaviour may vary after an upgrade. > I think you always control that explicitly in Jooq. > There's no such thing as autoloading in jOOQ. There's only explicit writing out all the joins. This is debatable, of course, as JOIN syntax is a bit verbose. But even if it was simplified, it would still be explicit. On the other hand, if, for instance, you want to "auto-load" addresses when loading customers, you can already do that through SQL views. 3) Hibernate has three entirely different APIs (Criteria, HQL, SQL), with > different abilities and different semantics (SQL doesn't affect the session > cache, for example; Criteria and HQL have a largely overlapping feature set > and semantics but some things that you can do you cannot do in the other). > If you find that one API does not suit you, you need to rewrite, and the > APIs are so drastically different that you can throw away the Criteria code > you have if you need HQL. > Jooq doesn't have this kind of largely overlapping (hence redundant), > semantically different (hence requiring full rewrites) nonsense. At least I > hope so :-) > We could argue that the SQL DSL has some overlapping / orthogonality with the "ActiveRecords" / UpdatableRecords. I'll get back to that when answering to your bullet 5) 4) Hibernate is a bit thin on documenting details. Docs are mostly there, > but sometimes distributed across official docs, tips&tricks sections, and > books; plus, sometimes the docs are incomplete and you have to experiment > (and hope that behaviour doesn't change during the next update). > Can't say much about Jooq's documentation since I haven't used it in anger > yet, but what I did see didn't look like it left many stones unturned. > I'd say that both documentations are about equal. Except that I'm not aware of any books on jOOQ (yet). > 5) Hibernate is full of subtle semantic distinctions. They're so subtle > (but important) that, sometimes, the Hibernate team decides to correct a > mistake. Since the issues are subtle, you don't know your usage of > Hibernate was affected until the upgrade hits you right in the face. > Jooq has a simpler semantics. That's partly because it doesn't try > anything fancy with a session cache. (There have been moves towards subtler > semantics though. I'm a bit worried there.) > Again, jOOQ's "ActiveRecord" / UpdatableRecords feature is a bit subtle. They ship with dirty flags on every attribute in order to control what happens on store(), update(), insert() calls. And then, there's the optimistic locking feature, of course, which some love, others hate, and which I have to maintain ;-) But in general, jOOQ doesn't (try to) solve as many different problems from different problem domains, which makes it easier to foresee semantics. Cheers Lukas -- 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.
