ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chen, Tim" <Tim.C...@NielsenMedia.com>
Subject RE: The biggest problem with iBATIS ..............
Date Tue, 08 Mar 2005 20:32:37 GMT
You forgot mass updates/deletes ;) 

-----Original Message-----
From: Antony Joseph [mailto:ajosephmi@lycos.com] 
Sent: Tuesday, March 08, 2005 11:31 AM
To: ibatis-user-java@incubator.apache.org
Subject: The biggest problem with iBATIS ..............

Hi all,

I came across this on one of the other forums.

"The biggest problem with iBATIS is its too simple"

So here is a couple of suggestions to the iBATIS team to make the
framework as complicated as the much hyped ORM tools in the market.

1) iBATIS needs a new query language. SQL!, its sooo 20th century,
everyone knows it, and whats with this bias towards english. We live in
a global village, I suggest that the new query language include terms
from all continents.
2) It needs some kind of session management. All the other ORM
frameworks have it, why not iBATIS.

Since its seems these days the goal of a corporate consultant is to make
sure the application costs as much as possible and takes as much time as
possible, here is a synopsis of the conversation a consultant will have
with the project manager using the new iBATIS(or your favorite ORM

1) As you know the framework uses a new query language, your developers
need to be trained on it. My company X provides a 3 day training course.
Its just $xxxx.xx per person. Don't forget to include the DBAs for
training. cha-ching!
2) Your developers seem to be ignorant of  ORM design patterns  like
'Open session in view', 'session-per-request-with-multiple-transactions'
.... etc . My company X provides a 1 day training course for ORM
patterns. It just xxxx.xx per person. cha-ching!
3) What!, your the DBAs want to denormalize the tables. This is a
problem, but we can solve it. The will cause the queries to get
complicated (Actually the queries start looking more like regular
expressions than queries) and it will take X weeks more and cost Y
dollars more to complete the project. cha-ching!

4) Those SOB users. They want to query data with something other than
the primary key!. We can take care of their requirements, but now, we
will have to write a whole bunch of dynamic queries to take care of all
the different query combinations. This will delay the project by another
X weeks and cost X dollars more. cha-ching

5) And when the totally confused junior programmer (confused by session
management and the query language) writes a query which reads the whole
graph of data from the database bringing the application to a crawl: 
Mr project manager, my company X has a caching framework, its only
$xxxxx.xx/per CPU. Plug that in and all your problems will be solved.
cha-ching, cha-ching, cha-ching.

Imagine the name recognition new iBATIS will get. A whole bunch of
confused developers will be asking questions on this forum, and then on
the Spring forum, and then the struts forum and finally if all else
fails, ask them on Matt Raible's blog. Thats publicity money can't buy.

So my question to Clinton and gang is, are you going to incorporate
these changes or follow on the same old beaten path of adding new
features and making the framework simpler to use?


Antony Joseph

NEW! Lycos Dating Search. The only place to search multiple dating sites
at once.

View raw message