ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abdullah Kauchali <abdullah.kauch...@isanusi.com>
Subject Re: iBatis and ORM's
Date Sat, 05 Nov 2005 08:44:35 GMT
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


Mime
View raw message