I did miss a few. Somewhere down the line I will include it in my next joke which will include the fiasco called detached objects.
----- Original Message ----- From: "Chen, Tim" <[EMAIL PROTECTED]> To: ibatis-user-java@incubator.apache.org Subject: RE: The biggest problem with iBATIS .............. Date: Tue, 8 Mar 2005 15:32:37 -0500 > > You forgot mass updates/deletes ;) > > -----Original Message----- > From: Antony Joseph [mailto:[EMAIL PROTECTED] > 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 > framework). > > 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 > http://www.logicden.com > https://workeffort.dev.java.net > > -- > _______________________________________________ > NEW! Lycos Dating Search. The only place to search multiple dating sites > at once. > http://datingsearch.lycos.com Antony Joseph http://www.logicden.com https://workeffort.dev.java.net -- _______________________________________________ NEW! Lycos Dating Search. The only place to search multiple dating sites at once. http://datingsearch.lycos.com
