> At a certain point this is getting beyond parody. That statement sounds exactly like it’s discussing SQL!
Nope. The underlying relational model is great. Knowing what tables are like, how and why indexes work (and when they don't), transaction isolation levels, all that stuff is extremely useful transferrable knowledge (and will help you out whether you're using an ORM or not). Knowing the three or four different bizarre pseudo-COBOL variants that different database vendors use to express something like "pull rows recursively from this table" or "format this string using these two numbers and this date" is stamp collecting at best.
Disagree. All too often, JPA/Hibernate dumbs the relational model down into record-at-a-time processing with navigational queries reminiscent of pre-relational network databases and counting and joins implemented by unnecessary fetching and client-side processing rather than aggregate queries and joins. Furthermore, it brings fuzzy locking semantics/locking as a side effect of lazy/eager fetching and artifacts such as a pattern of unnecessary "id" columns due to lack of support or asymmetrical and idiosyncratic handling of compound keys, also extra magic for "many-to-many connectives" (the wording alone is non-relational), lack of attention for decimal arithmetic/overflow with money values, idiosyncratic date/time conversions and mappings of enums into ordinals, etc. etc.
Not my experience at all. The support for aggregate queries and joins is very good if you actually use it; likewise the support for decimals, date/time and enums (though I say that from a position of thinking a lot of database date/time handling is wrong, so take that as you will). I'm not a fan of lazy fetching but if it's something you want then the locking semantics are a natural consequence of that. Many-to-many connectives are indeed non-relational, but again if they're something you want (and again I mostly avoid them) then they work the way that they have to work.
Nope. The underlying relational model is great. Knowing what tables are like, how and why indexes work (and when they don't), transaction isolation levels, all that stuff is extremely useful transferrable knowledge (and will help you out whether you're using an ORM or not). Knowing the three or four different bizarre pseudo-COBOL variants that different database vendors use to express something like "pull rows recursively from this table" or "format this string using these two numbers and this date" is stamp collecting at best.