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 07:56:21 GMT
netsql wrote:

> Let me try another approach of how I answer this:

Thanks, I appreciate it greatly!  :)

> SQL is a set processing langage. You select a set, update a set where, 
> etc., SQL engines are optimised for this for many decades. (See set 
> theory, unions, intersections, SQL P&T, etc.)
> In general, row by row processing is discuraged when working w/ SQL 
> dbs and is not optimal.

Ok, so it is always going to be less efficient to iterate through a 
collection of instantiated objects
(objects that relate to rows in a table) in the application "process 
tier" (or outside the RDBMS process)
/than/ it would to do a SELECT COUNT(*) FROM TABLE, get the resulting 
int and run with it!

Got it.

> So... row by row processing, or cursor processing is more ORM. ORM 
> attemnts to do SQL optimizing on the Java side, by storing rows as 
> objects and computing. ORM is row aware and ads complexity to Java layer.

Got it.

> Set processing is more SQL Mapping. Native Optimization from the SQL 
> engine is leveraged. SQL mapping is not aware of rows, it's aware of a 
> set of results that may be cached should somone else required 
> identical result set. 

Now this is where the "heart" of my question is!  :)

We all know that iBatis returns Java objects that are mapped to 
/resultsets/ of a statement.  That is
how we all use it.  We have a User table and we have a mapped statement 
that tells the iBatis
library to "take the resultset from that query and create Java objects 
from it" - based on the class
(name) we give it - in this case a User Class.

Now, isn't that the central premis of an ORM - to give the developer the 
ability to see his/her tables and
rows as Classes and Properties?  We are not simply refering to "typed 
datasets" here (like we have in
 .NET). JDBC Resultsets, in a way, are already "typed" - so, that's no 
even what iBatis returns.  As a matter
of fact, iBatis "best practices"  encourage the concept of OO 
containment too (where an object can contain a
list of other objects) - representing a 1-to-many relationship.   (Typed 
dataset don't have this level of
"sophistication" - a concept very much steeped in the semantics of OO.  
Typed datasets would simply carry
foreign key links, very much like the tables they represent on a 
RDBMS.)  iBatis is much more closer to the
OO side than it is to the idea of "SETS".

The point I am making is that, it looks like iBatis has /intentions/ of 
answering the fundamental questions
that all ORM's have ambitions of solving - the primary one being the 
ability to give the programmer a
/natural/ (cough!) feel for their objects.   (Gee, I could puke every 
time the ORM folks say that.)  To use
OO concepts like inheritance, polymorphism to construct their problem 
domain.   (I am not saying this
is possible with iBatis, I am saying that iBatis gives that impression 
when we start do the mapping of
resultsets from mapped statements to Java classes.)

Another way of seeing this apparent iBatis "identity crisis" -  
(Clinton, I mean no offense here, and this is
not my primary objective for this particular discussion :) ) - is the 
glaring lack of support for returning the
concept of RESULTSETS or /disconnected/ resultsets like CachedRowSet or 
WebRowSet.  (Are you
smiling, Clinton?)  :-)

IMO, we need them badly!  If we are going to compare iBatis with a 
spreadsheet and ORM's with
Wordprocessors  (an analogy I absolutely accept!), then where is my 
"spreadsheet" from iBatis.  (The
RowHandler stuff is not an answer btw because I have to create my 
"dataset" myself.)

Kind regards,


View raw message