Re: ORMs comparisons/complaints.
On 1/3/2014 10:24 AM, lipska the kat wrote:
On 03/01/14 14:18, Arved Sandstrom wrote:
On 01/03/2014 05:08 AM, lipska the kat wrote:
On 03/01/14 04:29, Arved Sandstrom wrote:
The JPA specs are some of the best specs I've seen. The associated
specs
for the actual implementations are also quite good. If your eyes are
glazing over when you try to read these, I'm pretty sure you've got a
hell of a time with almost every other spec out there.
Now now, you're making assumptions again aren't you.
They're glazing over through BOREDOM, any other assumption is erroneous.
You're making assumptions yourself. I didn't imply that you were
mentally retarded. I merely observed that if your eyes glaze over when
reading JPA or Java ORM specs, your eyes must glaze over when reading
most other specs.
Actually, RFC2616 and updates has been my preferred bedtime reading for
the past few years, I still browse it from time to time. I also enjoy
the HTML5 and CSS3 specs along with a regular perusal of the latest Java
API docs, so no to general glazing overness but yes to glazing overness
when it comes to third party frameworks ... I just can't get excited
about them.
Then read Java EE API docs.
Like JPA Criteria API.
:-)
I'd rather spend the time improving my SQL skills. This whole business
about saving time and 'making things easier' doesn't always chime. Work
for company A they use ORM X, learn ORM X, still need SQL to do stuff
the ORM can't manage. Work for company B they use ORM Y, learn ORM Y,
still need SQL to do (different) stuff the ORM can't manage. See a
common thread here.
I'll stick to SQL thanks.
I see a common thread: meaning no offense, I think you are biased
towards SQL to the extent that you are discounting more abstract data
access technologies...not that SQL is actually that close to the metal
either.
Actually I just can't be arsed with frameworks, I try too get closer to
the machine, not further away from it.
It has been known for more than 25 years that getting closer to the
machine is not cost efficient given the way cost of hardware
and cost of people evolve.
It could
just be me, but I like it when I get a substantial assist creating
objects out of relational data. You just now above said "accept the
overhead": guess what, there's a lot of overhead.
I'll tell you what, I'll spend whatever time is required to learn one of
these XML ... oops ORMs when one comes along that allows me to write
classes that don't need primary keys.
I'll assume that you are not questioning the general usefulness of
primary, composite or surrogate keys. :-)
RDBMS Keys of whatever type and complexity are irrelevant to an Object
graph. RDBMS Keys are needed in my Object models if I want to load and
store instances from and to an RDBMS, they don't belong there, they
annoy me and they destroy the beautiful simplicity of explicit
relationships implemented by aggregation and composition. If it was up
to me I wouldn't have the bloody things anywhere near my code.
Well - you need the keys no matter whether you use ORM or plain JDBC.
And besides the concept of object id is not only for persistence - you
will need it for simple stuff like collections as well.
Arne