ORMs comparisons/complaints.

[Gordon Levi]

"lipska the kat" wrote in message


Reply at the end, sorry for the lack of indentation..,




Well I'm not sure what kind of Java applications you write but in the
world I inhabit the client request "we just want to add one more field
to this form" is guaranteed to send a shiver down the spine as it's
usually followed by "How much?, for adding a single field? you gotta be
kidding".

To add a single persisted field to an input form requires the
modification of most if not all of the layers of an application.

Adding a single field to a product line for example would probably
require the modification of all the CRUD methods for that line, not to
mention the inclusion of the field in the search algorithms, modifying
the validation layer, incorporating the field in a logical place in the
HCI, modifying and refactoring the relevant code etc etc. Anything that
can reduce the amount of work required to implement such an apparently
trivial change has got to be a good idea.

Having said that, I don't used ORMs myself, I mean I've tried, I've
really tried but I start reading the documentation and my eyes glaze
over and I discover that I need to learn 'another' (query) language and
I decide that it's just not worth the effort. Stick to SQL, accept the
overhead and I don't think you can go far wrong.

Just my 2 euros worth

--------------------------

I find myself actually agreeing with you again.

Adding even a single field to the underlying data structures is *not*
straightforward at all in a typical Java application.

I'm sorry if you both have had a hard time adding a field to a
database but it is not relevant to my post. I believe that adding a
field to a database should require _no_ alterations to any program
that accesses the database unless the program needs to process the
field. The extra code that processing the field requires could take
from one day to several man years. If you work for a large corporation
you can change one day to one month but that is beside the point.

 

[Gordon Levi]

The context is that the class is persisted in a relational
database.

Thank you, it seems my fears are well founded. Does that mean that
real Java programmers go to the trouble of breaking the relational
model in order to maintain the object model?

 

[Arved Sandstrom]

The name is not unusual in Scandinavia. Just did a lookup - we are
13805 Arne in Denmark alone.

Happy NY to you too.

Arne

Denmark and Estonia (where my parents are from) have a fairly close if
somewhat ancient history: http://en.wikipedia.org/wiki/Danish_Estonia.

It is however probable that very few Estonian names of Scandinavian
origin have Danish lineage. Estonian names of Scandinavian origin would
typically be Swedish...like my first and last name.

AHS

 

[Arved Sandstrom]

I think we almost agree on the grading of the syntaxes.

But we may disagree on the weight given to syntax in an ORM
evaluation.

I just don't see syntax for queries as being important enough
to cause "light years ahead".

Everything else equal, then a nice syntax obviously create
a winner.

Arne

Every time I look at the JPA criteria API, I cringe. This
occasionally causes me to use excessive comparisons.

But I don't see how syntax of data access code is not _quite_ important.
Whether SQL or JDBC or JPA or native ORMs etc. Syntax is a major part of
what makes an API readily useable.

AHS

 

[Gordon Levi]

Ah, yes *majik* I'd forgotten about that, well done, where did you get
your wand? can I get one?

Edgar Codd gave you the wand forty years ago. Christopher Date
explained how to use it and an unnamed hero at Sun Microsystems made
sure it was available in Java with JDBC.

 

[Arved Sandstrom]

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.

I don't exactly choose programming specs for Saturday afternoon reading
either. I haven't run across any that keep me glued to the pages like a
Jeffrey Archer or Ken Follett novel. But material on JDBC or SQL ain't
any easier to read than JPA specs.

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.

If you're dealing with Java ORMs, incidentally, there probably is only X
and Y: as in two major ORMs. It's not that onerous to learn two
technologies, and since both support JPA, it's even less trouble.

As to SQL being superior because you sometimes have to use it, that's
like me claiming that C is superior and the preferred language because
every once in a while I've had to do things like SWIG or Perl XS or JNI.

I'm not American

I am. I'm also Canadian and Estonian. But you understood the term "NIH".

I'd be interested to hear how a constant use of SQL saves time. That
leads to usually re-inventing the wheel. Myself, I'd advocate using a
carefully chosen subset of JPA about 80-90 percent of the time, and
using SQL for the rest. I'd also advocate a fairly thorough knowledge of
a chosen ORM: a lot of critics of ORMs have bitched about gotchas and
inefficiencies and complexities, but yet you've also got all that with SQL.

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.

Having said that, are _you_ able to dispense with primary or foreign
keys when writing SQL or JDBC? Probably not. So why do you expect that
with an ORM? The level of abstraction is not that much greater.

To me, 'mapping' an object to an

RDBMS table (or multiple tables in some cases) means persisting my
Object graph without any of the relational database stuff creeping in,

Don't choose an ORM then. The 'R' sorta means that "relational
stuff" creeps in. Although if you can write SQL in a data access layer,
and generate objects for use by the BL layer or higher, I'd be curious
to find out how you can ignore "relational stuff".

and I include annotations, comments, pointed sticks or any other
artifact that is only included to enable the ORM, and yes I know about
the alternatives.

What alternatives? XML?

I keep wondering if it's possible using reflection and introspection ...

Feel free. If you're going to do that, may as well devise an efficient
file structure for data storage, and write C or C++ for access. Oh,
wait...Oracle and MS and a bunch of other companies already did that.

Hope this clears things up.

It clears things up. We still disagree.

AHS

 

[Arved Sandstrom]

No, it usually means that the Object model is broken in order to
maintain the relational model.

Programming, like any other discipline, is replete with people who
create or seize on trendy theories or ideas, or start thinking that they
understand really complex concepts when they have got 2 years of
experience, or start tossing around high-faluting terminology.

Not saying you are one.

Having said that, some folks invented dubious concepts like
object-relational impedance mismatch, likely because some of them knew a
bit about EE. This unfortunate terminology has led to legions of people
expounding on this "mismatch". For years you've had a whack of folks
bending over backwards to academically opine on how bad this "mismatch" is.

I may sound a bit like the kid who claimed that the emperor had no
clothes, but let's be real: the object model is *not* broken when you
deal with relational. Last I checked, any time I've used SQL via JDBC,
or used JPA, I get pretty decent objects...and the object model is not
broken at all.

AHS

 

[Arved Sandstrom]

And it won't -- assuming there are no constraints placed on the new
field, and none of your SQL calls depend on the particular ordering
or cardinality of the columns in that particular table. Oh, and of
course assuming that none of the triggers or stored procedures in
the database depend on the particular ordering or cardinality of
the columns either.

Oh, _and_ assuming that the new field doesn't cause Oracle to
choose a new, much slower evaluation pathway for any of your
SQL calls just out of spite.

In the wider context of this thread, technical matters this specific
make sense only to DBAs and a small percentage of developers. Most
developers who resort to using SQL don't even understand this stuff.

People created SQL, JDBC and ORMs so 99 percent of the developers could
be insulated from this information.

AHS

 

[Arne Vajhøj]

Given an existing relational database (or set of databases) that:

!) Is/are central to the business (i.e. not there just to "support" some
specific activity).

2) Is a fairly good relational expression of the underlying business model (but
see (3) and (7)).

3) Is old, old, old...

4) Is used by more than one application, which are not all written in the same
language

5) Has severe perfomance problems (caused by the nature of rhe business) even
when accessed via had-written SQL such that there is a fairly large amount of
explicit demnormalisation, and the write-measure-rewrite loop is a central part
of normal, everyday, application development/maintenance. And, even so, many of
the most important processes take long enough to cause very real operational
difficulties for customers.

6) Is not simple, in the sense that most of the "entities" that a user would
think in terms of do not correspond to rows of data in single tables.

7) Has historical quirks (see 3). Such as: no primary keys (the data has
primary keys at the logical level, but -- due to history -- the physical DBMS
itself doesn't know what they are, it just knows about a buch of unique
indexes). No FK constraints (again they are there in the logical model, but
not expressed physically).

Is my feeling that even attempting to use an ORM for developing brand new
applications against the database would be impossible and/or massively
counter-productive, actually defensible ? I.e: am I right to dismiss ORM /out
of hand/ ?

(Incidentally, of the relatively few database I've come across in 30 years of
programming, many fit that pattern).

I don't think you should discard ORM without further investigation.

Nothing of what you mention scream "not possible with ORM".

Specifically I would expect:
* no physical PK to work OK with the ORM when you declared the logical
PK as id in the class
* no physical FK constraints to work OK with the ORM
* write-measure-rewrite to be fine with ORM
* performance of ORM not to be worse than direct SQL
* flexible mapping between classes and table to work OK with the ORM

But based on the general state of the database, then I would say that
the risk of running into a problem is much higher than with a from
scratch database.

And it is given that you can not generate the classes and/or the
mapping automatically from the tables given the description.

And all ORM's are not the same, so some may work better than other
with a scenario as the one described.

[and those types of scenarios are rather common!]

If you have time to research (POC) ORM, then I think you should.

If you do not have time, then you should probably discard ORM
due to the risk of problems due to non-optimal environment.

Arne

 

[Lars Enderin]

2014-01-03 14:10, Arved Sandstrom skrev:

Denmark and Estonia (where my parents are from) have a fairly close if
somewhat ancient history: http://en.wikipedia.org/wiki/Danish_Estonia.

It is however probable that very few Estonian names of Scandinavian
origin have Danish lineage. Estonian names of Scandinavian origin would
typically be Swedish...like my first and last name.

The more usual Swedish variant would be Arvid (Sandström).

 

[Arved Sandstrom]

That might matter to me inasmuch as I do understand the use of EXPLAIN
and similar tools to understand why an SQL query is slower than expected
and how use the tool's output to decide if a speed-up is worth it and, if
so, how to modify the query and/or the schema.

Are there similar ORM tools and if so, do they tend to be generic or ORM-
implementation specific?

Martin, the SQL generated by Java ORMs is not hidden. Suitable logging
levels expose the generated SQL. If you distrust that logging there are
always DB profilers. Many/most ORMs are open source: when in doubt,
investigate the code...I've tweaked several Java ORMs after code inspection.

In my opinion the first and usually the best "tool" is simply the native
implementation spec.

I do myself understand execution plans quite well, but not nearly as
well as a good DBA. In most consulting engagements that involve RDBMSs,
if performance issues get tricky I do not hesitate to talk to a resident
DBA: that's another great "tool".

AHS

 

[Arved Sandstrom]

"lipska the kat" wrote in message


Reply at the end, sorry for the lack of indentation..,

I don't understand this so I fear I must be doing something wrong in
my Java programs. If someone wants to add a field in a database why do
I have to alter anything in my program other than adding, for example,
getString(String columnLabel) if I want to actually use the new field
at that point in the program.

Well I'm not sure what kind of Java applications you write but in the
world I inhabit the client request "we just want to add one more field
to this form" is guaranteed to send a shiver down the spine as it's
usually followed by "How much?, for adding a single field? you gotta be
kidding".

To add a single persisted field to an input form requires the
modification of most if not all of the layers of an application.

Adding a single field to a product line for example would probably
require the modification of all the CRUD methods for that line, not to
mention the inclusion of the field in the search algorithms, modifying
the validation layer, incorporating the field in a logical place in the
HCI, modifying and refactoring the relevant code etc etc. Anything that
can reduce the amount of work required to implement such an apparently
trivial change has got to be a good idea.

Having said that, I don't used ORMs myself, I mean I've tried, I've
really tried but I start reading the documentation and my eyes glaze
over and I discover that I need to learn 'another' (query) language and
I decide that it's just not worth the effort. Stick to SQL, accept the
overhead and I don't think you can go far wrong.

Just my 2 euros worth

--------------------------

I find myself actually agreeing with you again.

Adding even a single field to the underlying data structures is *not*
straightforward at all in a typical Java application.

I also tend to agree with your comment regarding ORMs v. standard SQL.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
(e-mail address removed)
[Replace the "SixFour" with numbers to email me]

Adding a field - either at the DB table level, or at a more abstract OO
level - isn't trivial, but neither is it usually brutally difficult. Not
from a developer standpoint. It's usually straightforward, just time
consuming, as I mentioned in another post. Too many changes like this
leads to "death by a thousand cuts".

As I mentioned in that same post, the real issue with changes like this
is that some end user, client, PM, architect or designer is vacillating
or being incompetent or not resisting ill-advised requests. The problem
is higher up the food chain.

And even when programmers are asked to make a change like this, the bulk
of expended effort is not at the data access layer level. You guys have
yourselves intimated this, or flat out said it. So if most of the work
is not at the DAL level, but happens in business logic or the
presentation layer, *and* the choice and employment of JPA, native ORM,
JDBC, SQL etc is confined to the DAL, why is it not fundamentally a
problem with human beings? It's not the fault of an ORM.

AHS

 

[Arne Vajhøj]

Thank you, it seems my fears are well founded. Does that mean that
real Java programmers go to the trouble of breaking the relational
model in order to maintain the object model?

????

If you use an object oriented language and a relational
database, then you will have both an object model and a
relational model.

Neither model need to be broken.

And it is not something special for Java.

The only thing special for Java may be that using an ORM instead
of a lot of handwritten code when moving data between the two models
is much more common than in many other languages.

Arne

 

[Arne Vajhøj]

Bollocks, and I mean that most sincerely, If you *really* think about it
and you're *really* honest with yourself can you think of one single
time when you designed a system that you *knew beforehand would persist
it's data in an RDBMS* where this knowledge didn't in some way, however
sub-consciously impact the decisions you made when you were designing
that system?

I think this may be a very good example of the type of argument that
Arved was thinking about.

1) There is really nothing sub-consciously flowing. If you do code
first, then you do the object model exactly like you would if it
were not to be persisted - there really is not any room for
influence from persistence - attributes and associations are
given by the problem domain. If you do database first, then
the object model is completely and very consciously determined
by the relational model.
2) Even in the cases where the relational model do impact the object
model, then that does not mean that the object model is broken.
3) And even if the object model were broken, then that would not
be any different with plain JDBC than ORM.

Arne

 

[Arne Vajhøj]

I'm sorry if you both have had a hard time adding a field to a
database but it is not relevant to my post. I believe that adding a
field to a database should require _no_ alterations to any program
that accesses the database unless the program needs to process the
field.

We are discussing how to do it when the program does need to
use the field.

The fact that no changes are needed if the field is not used is
correct but not very relevant as an argument for or against ORM.

Arne

 

[Arved Sandstrom]

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. I prefer to be in control quite frankly and not rely on what
someone else thinks is the right way to do something.

Therein lies our philosophical difference. In software development it is
not possible to be in control. You may accomplish various semblances of
"being in control", but nothing you do doesn't eventually rely on the
efforts of dozens or hundreds of people.

There isn't any major difference between the abstraction provided by a
RDBMS DDL/DML or the abstraction provided by JDBC or an ORM. In none of
those cases are *you* in control. If you really want control, revert to
assembler or machine code, and create your data storage yourself. Even
better, let's shoot for microcode.

Now I know you're kidding, Jeffrey Archer!!! *Jeffrey Archer* jeez, the
man's an imbicile.

I'm not a personal friend of his, I've never met him. Given his career
he's probably not an imbecile, though. Maybe not just your favourite
author. Whatever people created Coronation Street are surely not
imbeciles either, but I can't myself stand the show.

Yes but it's so much more *interesting*


Actually I just can't be arsed with frameworks, I try too get closer to
the machine, not further away from it.

Time and a place. Most every framework was created for a decent reason.
The implementations may be imperfect, but that's no reason to abandon them.

C is god, there is no competetion. I went with Java bacause that is
where the money was when I graduated, I was cracking C when I was first
year Uni, I broke their network simulators in about 5 minutes flat, I
like C ... but I've done better out of Java.

C is not god, languages like J and F# and Prolog are. I wouldn't let
most coders approach C, although I myself really like C. I wouldn't let
most coders tackle C++ either, not even the latest version.

That's very kind of you, I will
You're welcome.

Not Invented Here has nothing to do with it. I'm Canadian born,
Vancouver BC (and Scottish)


Yes, but it's just *one set of complexities*

I get that you're making that point. It's not entirely true, there are
vendor variants of SQL.

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.

Please tell me how you will _identify_ persisted objects?
[ SNIP ]

Actually I like XML, I've started to store entire tranches of data in
XML in a database, it makes adding fields to a particular data cluster
so much easier. ... and I'm getting *really* good with DOM

Makes sense that you like DOM. It's a low-level interface, quite painful
to use, and there are many better alternatives.

And isn't that a fantastic freedom that we need to carefully defend.

It is.

AHS

 

[Arne Vajhøj]

That might matter to me inasmuch as I do understand the use of EXPLAIN
and similar tools to understand why an SQL query is slower than expected
and how use the tool's output to decide if a speed-up is worth it and, if
so, how to modify the query and/or the schema.

Are there similar ORM tools and if so, do they tend to be generic or ORM-
implementation specific?

Since most ORM's support multiple databases that may have different
performance characteristics, then explaining ORM may be difficult.

Most ORM's allows you to dump the actual executed SQL against a specific
database and that SQL can be explained.

So if you have a specific performance problem using a specific database,
then you can investigate.

But as a general rule of thumb, then I would say that the SQL becomes
so complex that you need to explain different variants to find out what
is performing best in a specific database, then you should start
considering whether an ORM is the right tool for the job.

Arne

 

[Arne Vajhøj]

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.

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.

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

 

[Arved Sandstrom]

I think this may be a very good example of the type of argument that
Arved was thinking about.

1) There is really nothing sub-consciously flowing. If you do code
first, then you do the object model exactly like you would if it
were not to be persisted - there really is not any room for
influence from persistence - attributes and associations are
given by the problem domain. If you do database first, then
the object model is completely and very consciously determined
by the relational model.
2) Even in the cases where the relational model do impact the object
model, then that does not mean that the object model is broken.
3) And even if the object model were broken, then that would not
be any different with plain JDBC than ORM.

Arne

Thank you, Arne, you just summarized my thinking much better than I
myself did. As you pointed out better and more succinctly than I did,
use of an ORM, as opposed to JDBC and SQL, cannot have less or more of
an influence on object design.

AHS

 

[Arne Vajhøj]

Every time I look at the JPA criteria API, I cringe. This
occasionally causes me to use excessive comparisons.

But I don't see how syntax of data access code is not _quite_ important.
Whether SQL or JDBC or JPA or native ORMs etc. Syntax is a major part of
what makes an API readily useable.

It certainly is important.

Arne