> jOOQ has always had a more SQL-centric focus, than a Java one. > So I think that operating on rows, records, result sets, cursors, > etc. will not feel wrong to people with a SQL background.
Having both an SQL and OO background, I can confirm that. > After > all, some dialects (e.g. T-SQL, PL/SQL) implement extensive row > operations in their procedural language parts as well. For me, that's a secondary aspect. What's more important is that, for us, ORM layers simply can't be made to work. (An insightful article on that topic can be found at http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx .) At our project, we need to stick with SQL semantics, and so while we certainly like to map table column structures and foreign-key relationships to Java classes as automatically as possible, this is always less important than being able to effortlessly bang SQL against the database. I think Jooq is for those who find that ORMs don't work for them. Those that find ORMs worth it don't need Jooq, they can use Hibernate or Mybatis or whatever ORM suits them best. Those that try to mix both usually find that they're running into problems with inconsistent data. The usual consequence of denormalized data if you will, or - from the Java perspective - of pointer aliasing. -- 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.
