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

Reply via email to