Re: ORM or JDBC?
On 23 Mar, 22:09, Lew <no...@lewscanon.com> wrote:
Alessio Stalla wrote:
Existing Java ORMs (those known to me, at least) fail at mapping comple=
x enough object graphs.
Depends on what you mean by "fail".
I mean that there are some operations that make sense on object graphs
and make sense on relational tables, yet you can't map them with
present ORMs as they are out of the box.
Relations are not (only) Collections, as ORMs would like us to believe.
Collections cannot be a) filtered and b) joined without for() loops in =
Java.
Not true.
Where the use case is common enough you can create custom collections thr=
ough
judicious use of JPQL or Criteria, much as you would have to use custom J=
DBC
queries mapping by hand to a collection (!) were you to eschew JPA.
Well, yes. Of course what can be done in one language, can be done in
the other, if they are Turing-complete. I really meant "cannot ...
without for() loops in Java" AND without implementing framework-level
support for it (in other words, extending the ORM itself). I'm not
saying no such ORM can exist in Java, just that it doesn't exist now
(as far as I know).
a) parent.getAdultChildren() can only be implemented as removeMinors(pa=
rent.getAllChildren()).
b) grandParent.getGrandChildren() can only be implemented
'Ware claims of "can only be implemented", particularly where several
reasonable alternatives exist.
as for(Person p : parent.getAllChildren()) { collect(p.getAllChildren()=
; }.
The same alternatives exist for this, too.
Ok, I mean: there's no Collection.filter() or Collection.join(). If
you write them, there can be MyEnhancedORMCollection.filter() and
MyEnhancedORMCollection.join().
That's probably fine (even if too verbose and not easily parallelizable=
) for objects in memory,
Which is precisely why JPA allows for alternatives.
Yes, it's an object model on top, but you can still leverage the data mod=
el at
the bottom. JPA does not preclude that.
Of course not, but - for me, personally - being "forced" to leverage
the data model at the bottom is a failure of JPA, in the sense that it
promised to take my somewhat arbitrary(*) object model and map it to
SQL, but it didn't do it completely.
(*) I know it's not really arbitrary, that's an oversemplification;
but I maintain the position that there are some object models that can
be mapped by JPA implementations, and yet they cannot implement
certain operations in a OO way without extending the JPA
implementation itself.
but it's completely stupid for objects fetched from a database.
Dropping to JQL, criteria, or SQL is not a solution, because it means s=
tepping outside the OO world to return to a relational view of the world.
Well, it actually is a solution. Yes, it forces you to think about the
relationships a little more deeply than the simple cases you referred to,=
but
then the relationships are deeper, so that's understandable.
JPQL or JQL or whatever the initialism /du jour/ is still object-oriented=
, in
the sense that its queries are phrased in terms of objects and their
relationshiops, not tables and rows. This, in fact, causes difficulty =
for
folks who get confused by its superficial similarity to SQL.
They're still somewhat OO, but not in the sense that you can always
reason about entity.method(). Sometimes, you are forced to do
dao.method(entity) to access some property of the entity. (Or to
extend collections so that etc. etc., we already said that).
I don't know the .NET world well, but I've been told LINQ can solve bot=
h these problems
because it represents relations as Queryables (Iterables on steroids) t=
hat support .where and .join methods (or equivalents).
Ummm, that's essentially what JPA does. Collections are all 'Iterables=
'
albeit not on steroids (thank goodness or Java would suffer the rage epis=
odes
and sexual dysfunction).
They're just Iterables. They don't have .where or .filter or .select,
nor .join.
To be more specific, I'd like to do
person.getAllChildren().select(gte("age", 18));
or, even better,
person.getAllChildren().select({ x => x.getAge() > 18 }); //or
whatever closure syntax is supposed to be currently
and have it result in a single query with a WHERE ... AND person.AGE >
18 (if the collection is lazy and not yet loaded in memory).
Similarly, to get all the grandchildren, something like
person.getAllChildren().join({ x => x.getAllChildren() });
(join(x) could be defined as map(x).flatten(), at least conceptually).
Now this is not a reason not to use ORMs in Java at all,
but certainly one must be well aware that seamlessly mapping
a rich domain model to an RDBMS is presently impossible.
"Impossible" is such a strong word, and in this case, inapplicable.
I don't know what you mean by "seamless" but I'll settle for "not harder =
than
doing it the other way". JPA is not harder than doing it the other way=
for
the cases you cited.
No, it's certainly easier, but it's still, imho, a leaky abstraction.
And I don't like leaky abstractions ;)
Anyway, your points are valid. I certainly used too strong words.
Alessio