Clinton Begin wrote:
Try this with Hibernate:
int i = (Integer) client.queryForObject ("countUsersInGroup", "MyGroup");
<select id="countUsersInGroup" resultClass="int" parameterClass="string">
SELECT Count(1) FROM Users WHERE GroupName = #groupName#
</select>
So, we're saying Hibernate has to receive results from all (including ad
hoc) queries to /map/ to Java classes!
An ad hoc query that does not have a Table-to-Class association is
/impossible/ to construct in Hibernate?
In asking yourself why this isn't possible in Hibernate, you'll answer
your first question.
To answer the third question, try this with Hibernate:
client.delete("deleteUsersInGroup", "MyGroup");
<delete id="deleteUsersInGroup" parameterClass="string">
DELETE FROM Users WHERE GroupName = #groupName#
</delete>
In asking yourself why this isn't possible, you'll answer part of the
third question.
Understood.
The rest of the answer to the third question is this: Generally
systems involve many more SELECT statements than INSERT, UPDATE and
DELETE combined. Usually all of the value in a relational database
system is realized from the SELECT statements. Nobody makes money on
INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very
well (as long as you're not talking batch updates and deletes). But
ORMs generally do very little for SELECT, and in fact, ORMs often
complicate SELECT. Having experienced this myself, I'll say that
beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PK....ORMs
don't generally help much.
Beautiful, I like this answer. <g>
What ORMs do very well though is manage the relationships between
objects and how the impact a change to one object should (or should
not) imact related objects. ORMs also tend allow for much more
effective caching of objects (thanks to OID).
Yup.
But anyway, this is an old discussion that's become way to old.
Old, yes - but certainly not /concluded/ by a long shot! :-)
The real answer to your question is another question: why are you
comparing an ORM to iBATIS?
For two reasons:
1. I am compiling a document that identifies a few ORM and "data
abstraction" tools on a spectrum
that looks like this:
<-------------------------------------------------------->
SET BASED OO BASED
I then want to enumerate /characteristics/ of the different tools and
give "flavours" to these characteristics
by saying: "ah, this one leans towards SET semantics" or "this one has
a putrid stench of OO mentality".
(You can see my bias! But I am not against OO! <g>)
The second reason is based on my defense for the use of iBatis in our
project. If I get asked why iBatis
is /NOT/ an ORM tool, I need to answer that question in a cogent and
decisive manner. Otherwise I
will be faced with the task of defending the /lack/ of ORM type of
functionality in iBatis!
It's like comparing a Spreadsheet tool to a Word Processor.
Love that! :) (So, where's my "disconnected resultset" - or
spreadsheet in iBatis, Clinton!!! <g>)
http://issues.apache.org/jira/browse/IBATIS-206
