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,
Abdullah