Re: iBatis and ORM's
Clinton Begin wrote: The fact that it currently translates the resultsets into an object model As a matter of fact, it could be argued that /that/ part of iBatis is its /weakness/. That part? That's not a part...that's ALL iBATIS does. If you've misunderstood that, then I'm sorry for our lack of clarity. As far as I know (please correct my ignorance), iBatis does the following: 1. It does a good job of hiding tedious JDBC stuff (transaction stuff included) through a best practices approach; 2. It does a fantastic job of dynamically constructing SQL/sp statements (complete with iterations, string replacements etc); 3. It does a good of organising your SQL statements /outside/ your application; 4. It does a good job of mapping query results to an object model; :) 5. It /also/ returns simple collection objects (very much like datasets but without the built-in expression support, metadata or navigation support you'd normally associate with datasets.); 6. It does a brilliant job of caching /results/ from SQL statements or stored procedures; (There are more I'm sure.) Now, depending on the circumstances, a user of iBatis may or may not find any one or more of the above features useful. In some cases, some of the features are totally useless. In /my/ situation, feature number 4. is a total waste of time! Why? Because we're not interested in the ORM features of iBatis. Instead, we are interested in the collection model of iBatis - a functionality currently afforded by iBatis when we avoid doing the rich object model stuff (feature 4.). Look at some of the comments Gavin is making about /lack/ of ORM functionality in iBatis because of this: Gavin's right. We lack a lot of ORM features. Because we're not an ORM. That, IMHO, is a wrong reason to say we are not an ORM. A correct conclusion from that is that we are a *bad* ORM.It just gives more ammo to the Hibernate folks. Needlessly. No, you are the only person suggesting that thus far. I am simply asking for clarification. I began this thread by saying iBatis is /not/ an ORM. I wanted to understand why you say that too. And if you believe it, give some good reasons, because I need to use them for iBatis' sake in our project. All I've said is: call it that if you want. I certainly don't want to call iBatis an ORM because I believe it offers a paradigmatically alternative solution strategy to ORMs. I believe it is not an ORM - not because it lacks key features of an ORM - but because it offers a dataset based solution too. I can't seem to convince you otherwise. I doubt you will convince anyone by saying that iBatis is not an ORM because it has some ORM stuff but it lacks some key features of an ORM. That simply is not going to be fruitful. It's like saying a half-baked cake is not a cake. It's simply a /bad/ cake. It seems that I could only do so by supporting disconnected rowsets. iBatis currently supports disconnected rowsets. Yes. But not the standard ones. Yes, I would certainly be happy if I could have iBatis return a rowset instead of me constructing one by the row handler logic. I would really appreciate the effort towards that. Without a doubt. (I wonder how many others would too?) We may indeed do that in the future...but not for the reasons you're suggesting. For a good description of the differences between ORMs (Metadata Mapper) and iBATIS (Data Mapper) and Table Data Gateways (DataSets), see Martin Fowler's Patterns of Enterprise Application Architecture. I will thanks. I see you've entered the feature request in JIRA. It is likely it will make it into some future release. Yup. :) I am really hoping you guys would find some time to look into it. Really. :) BTW, I mean offense or disrespect for the valuable time and effort all you guys put into iBatis. I love iBatis. I would like to continue using it and trust that my comments here are only received as a way to improve on it! I certainly hope so.
Re: iBatis and ORM's
Abdullah Kauchali wrote: BTW, I mean offense or disrespect LOL. I mean *NO* offense or disrespect ... Sheesh, as if the discussion isn't sensitive already! :-D
Re: iBatis and ORM's
Vic, For what it's worth, it's the same argument that we'd use against Maps as the domain model, which we've been through (a thread almost as long and tedious as this one). ;-) Obviously there are some significant design philosophy differences at work here. And that's okay. iBATIS is our philosophy, and is one worth protecting. My monthly bandwidth overcharge bills tell me that at least a few people agree with me. Anyone with a different philosophy is welcome to comment and request features, but belaboring points such as this, and implicitly or explicitly concluding things of their own as Abdullah has done, inevitably becomes rude and a waste of time. It serves only to annoy and distract the rest of the list. We've noted the feature request. But further design philosophy wars are out of scope for this list. My apologies to the rest of the list for filling your inboxes with this. Best regards, Clinton On 11/7/05, netsql [EMAIL PROTECTED] wrote: Clinton, I agree, they don't feel right. Can you help me verbalize yourbellow statment.Why is dataset or rowset a horrible design choice?.VClinton Begin wrote: Datasets, rowsets, strongly typed or not are generally a horrible design choice and shouldn't be used in any sort of system that requires a maintainable object model that can exist with or without a database.--thx,.VYour Roomity Broadband Community http://roomity.com/demo.jspcell: 917 825 3035 in DFWemail: netsql at roomity.com
Re: iBatis and ORM's
If we are going to have support for disconnected rowsets in the future What would be the reasons why you might introduce such a concept in iBatis? I don't know. Personally I see no need. But I am just one person of thousands who use this framework. It will need to be discussed, a case will need to be made for supporting them, and we'll need to ensure that doing so doesn't threaten the scope of iBATIS or the existing feature set. Cheers, Clinton On 11/7/05, Abdullah Kauchali [EMAIL PROTECTED] wrote: Clinton Begin wrote: I am simply asking for clarification. And now you have it.That iBatis is an ORM tool that lacks important ORM features?:)(Justjoking!) Clinton,Firstly, please accept my apologies for upsetting you. That was nevermy intention.I see you are ona massive defensive mode here, so I will give up here.However, can you answer one last question for my sake on this topic - I'd really appreciate it:If we are going to have support for disconnected rowsets in the future(for reasons other thanwhat I cite :-) ),can you tell me on what basis they will beintroduced?What would be the reasons why you might introduce such a concept in iBatis?Kind regards,Abdullah
Re: iBatis and ORM's
Hmmm...sounds like a pyramid scam opportunity. Now all you have to do is convince them to pay everyone on the list above them 1 dollar. Except they get to use ibatis which should definitely get them their money back sooner or later. Clinton Begin wrote: But if those two people convert two people each.exponential growth! On 11/4/05, *Kim Goings* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I will try. I've only been able to convert 2 people so far and would love to reach more. :) Kim On Nov 4, 2005, at 5:49 PM, Clinton Begin wrote: Sorry everyone. I didn't mean to sound like I don't care about such comparisons. I think it is old for me, and I'm able to look at situation objectively and decide whether Hibernate or iBATIS (or neither) is the best choice. To me, it seems obvious. Perhaps this is a VERY long overdue FAQ that we need to add. Anyone care to start it and begin collecting these thoughts? I would, but apparently I'm too jaded. ;-) Cheers, Clinton On 11/4/05, Kim Goings [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: been around it for so long.:)I think it's still valid.I've started to become quite the iBatis evangelist and when people ask why I think it is better or how it is different than Hibernate, the points you (and others) have made here are what I need to back me up. Like it or not, when people are deciding what to use on a project, it's not uncommon for iBatis and Hibernate to be the top two contenders. Maybe that's a growing trend stemming from painful Hibernate experiences.I think in many cases, people have realized they don't really need an ORM, but are fearful of pulling away because Hibernate is the hip way to go these days. They are different things and, as always, the best choice really does depend on the project.But for the most part, I think the decision often lies in the answer to Are you comfortable with SQL?or Do you have a DBA?(who presumably wants more control over what your app does to the db than Hibernate allows). AnywayI love iBatis and would be hard-pressed to find any situation where it wasn't the best, or at least sufficient, choice. Kim On Nov 4, 2005, at 4:55 PM, Clinton Begin wrote: Try this with Hibernate: int i = (Integer) client.queryForObject (countUsersInGroup, MyGroup); select id=countUsersInGroup resultClass=int parameterClass=string SELECT Count(1) FROM Users WHERE GroupName = #groupName# /select In asking yourself why this isn't possible in Hibernate, you'll answer your first question. To answer the third question, try this with Hibernate: client.delete(deleteUsersInGroup, MyGroup); delete id=deleteUsersInGroup parameterClass=string DELETE FROM Users WHERE GroupName = #groupName# /delete In asking yourself why this isn't possible, you'll answer part of the third question. The rest of the answer to the third question is this: Generally systems involve many more SELECT statements than INSERT, UPDATE and DELETE combined. Usually all of the value in a relational database system is realized from the SELECT statements. Nobody makes money on INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very well (as long as you're not talking batch updates and deletes). But ORMs generally do very little for SELECT, and in fact, ORMs often complicate SELECT. Having experienced this myself, I'll say that beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs don't generally help much. What ORMs do very well though is manage the relationships between objects and how the impact a change to one object should (or should not) imact related objects. ORMs also tend allow for much more effective caching of objects (thanks to OID). But anyway, this is an old discussion that's become way to old. The real answer to your question is another question: why are you comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool to a Word Processor. Cheers, Clinton On 11/4/05, Abdullah Kauchali [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Clinton Begin wrote: ORM 1) Maps classes to tables, and columns to fields. Don't we do that with iBatis too? Are we saying that mapping classes to tables, and columns to fields is generally a bad idea? 2) Must support Object Identity Yes, of course.Excellent
Re: iBatis and ORM's
Hi Adib, Thanks for sharing such a detailed account of your experiences. Did you ever run into any problems with the object identity hashCode/equals issue with hibernate. I know the hibernate people keep saying this is a general java issue (which I understand) but I find it a major reason for not using it. It just tells me that object identity in orm (and really therefore orm) is flawed. It just doesn't feel right. This is why i love and continue only to use ibatis. It keeps things simple and there are no ambiguous use cases which leave the user bewildered in terms of what the heck is really happening underneath the covers. Huy Adib Saikali wrote: Here are is a record of my experiences with Hibernate on a recent web project where I was the team lead and had complete control over choice of technology. This message is in the spirit of theory vs. practice. A wise programmer once told me that Simple things should be simple and hard things should be doable. I was recently on a new project where I was the team lead and I made the choice to use hibernate. This was my first serious hibernate project and I found out that in Hibernate simple things are not so simple but the hard things are theoretically made easy by hibernate. However, I needed the simple things 80% and the hard stuff about 20% of the time. In my particular situation I had a very well designed data model that was built by a highly experienced data modeler. The data model was built a couple of weeks before I joined this project as the team lead and it had about 90 tables. The task of mapping this data model to hibernate was not very easy, in the end we went with a one table one class mapping. We had many association tables that carried the reasons why the association was there in the first place. So we had to expose the association tables as mapped hibernate objects (This was also the recommendation of the Hibernate in Action book). Developer productivity was the number one priority on this project, because we had a very tight deadline which we met). The idea behind ORM is that the developers would have only had to deal with the Java Objects but alas that was not doable they all ended up with print outs of the data model on their desks. After my experience with this project I do not sure that the goal of cleanly separating the Also many of our web pages had data on them that was very easy to grab via SQL however it would have required a lot of code to traverse from one java object to another to present those pages. Following the advice of the Hibernate in Action book we ended up using report queries to get our data out of the database. Almost every screen that we did had one or two report queries. The interesting thing is that the report queries in Hibernate turned out to be more complex to write and figure out. We frequently had to write queries in SQL then convert them to HQL. The whole idea of hibernate taking care of generating the SQL for you did not pan out. We still had to write a lot of queries. Many of the tables we had a lot of relationships to many other tables and I frequently found out that I could not map those relationships very easily to hibernate. At first I was tempted to go to the data modeler and ask him to change the relationships to make the hibernate mapping easier. The more I understood the business problem the more I figured out that he had done a great job and it was pointless to change the data model to try and make it more hibernate friendly. For the record the data modeler was great to work and he did not object to any changes that we requested. So I made the decision not to map the complex relationships to hibernate. Only simple relationships got mapped to hibernate, and this another disappointment for me with ORM Hibernate. It just seemed that I was always trying to fit a square into a circle. In the end I had one java class for each table in the database, only simple relationships were mapped. Complex relationships were not mapped and that simplified our project quite a bit and allowed us to get in on time. So we needed up with a lot of report queries in HQL which made use of the new operator in the HQL to stuff the results into java objects. At the time I started this project I did not know much about iBATIS and I knew a lot more about Hibernate. Developer productivity was one my keys goals and I figured that it would be easier for me and my team to have access to books on hibernate and there were more learning resources for hibernate. If I was doing this project again I would have probably gone with iBATIS since I eneded up using hiberante the iBATIS way! My intuition as a programmer is that mapping statements to classes is better than mapping classes to tables, simple because it more naturally fits the principle that simple things should be simple to do and hard things should be double. One of the key features of SQL is its clousure property every SQL query returns a
Re: iBatis and ORM's
Clinton Begin wrote: This is really good discussion. I hope you guys help Kim with the FAQ, and post your feature requests to JIRA (I think use iBATIS as a spreadsheet is already in there). ;-) If you mean my JIRA entry, then I agree. But, hey, you started the iBatis is a spreadsheet analogy! ;-) Anyways, IMHO, I think we very badly need support for disconnected datasets or resultsets in iBatis. A concept like strongly typed datasets from .NET will be a /dream/! IMO, the current way iBatis does things makes it more of an ORM than it does a collection based data abstraction layer. :-) And the last thing I want to do is waste my time defending ORM for iBatis' sake!
Re: iBatis and ORM's
Alan Chandler wrote:
Hang on a sec here, don't we also map Java Classes to database tables
with iBatis? A User class
in my design maps to a User table in the database. Isn't this exactly
how the iBatis docs tell us
we should map our result beans?
Well
a) I was simplifying, but yes we map to beans not objects - but I have a
message that I want to get across
Hi Alan,
Instantiated beans are objects too, no? :) The point is that /once/
we start creating classes like these:
public class Student{
private Classroom classroom; - another class
}
or
public class Classroom{
private List students; - collection of students
}
... we get snookered into the ORM corner.
b) We do NOT map directly to tables, only to the results of a SQL statement
(which - as you say - might be a table). But the crux of my arguement is
that although for simple CRUD you might have that simple mapping, any real
application is more complex than that.
We have a 90 table data model where we began to model the bean
structures exactly as suggested by iBatis
documentation.
We then removed all such structures (refer above to the class examples)
and are now using the dataset
approach (with foreign-key links) - but this is very clumsy with
instances of beans in lists instead of dealing with
true-blue disconnected datasets. :-)
I disagree if you design your database with proper normalisation. In my
recent family tree application of the 12 SELECT statements only 2 mapped
directly to the table and 2 others half did (I added a dynamic where clause
to limit the search via a filter).
How many iBatis users design their beans like the example above?
Kind regards,
Abdullah
Re: iBatis and ORM's
The fact that it currently translates the resultsets into an object model As a matter of fact, it could be argued that /that/ part of iBatis is its /weakness/. That part? That's not a part...that's ALL iBATIS does. If you've misunderstood that, then I'm sorry for our lack of clarity. Look at some of the comments Gavin is making about /lack/ of ORM functionality in iBatis because of this: Gavin's right. We lack a lot of ORM features. Because we're not an ORM. Woah, so iBatis is an ORM? Is that what we conclude here? No, you are the only person suggesting that thus far. All I've said is: call it that if you want. I can't seem to convince you otherwise. It seems that I could only do so by supporting disconnected rowsets. We may indeed do that in the future...but not for the reasons you're suggesting. For a good description of the differences between ORMs (Metadata Mapper) and iBATIS (Data Mapper) and Table Data Gateways (DataSets), see Martin Fowler's Patterns of Enterprise Application Architecture. If we go iBatis, the folks who want to use Hibernate will ask for the missing Hibernate features in iBatis. Your clients will never get Hibernate features without using Hibernate. Disconnected rowset support in iBATIS won't change that. iBATIS and Hibernate do not compete at the same level, no matter how much some people would like them to. They are hardly even in the same problem space. I see you've entered the feature request in JIRA. It is likely it will make it into some future release. Cheers, Clinton On 11/7/05, Abdullah Kauchali [EMAIL PROTECTED] wrote: Clinton Begin wrote: I think we very badly need support for disconnected datasets or resultsets in iBatis. Datasets, rowsets, strongly typed or not are generally a horrible design choice and shouldn't be used in any sort of system that requires amaintainable object model that can exist with or without a database.That is simply not true. Introducing datasets takes nothing away from the /real/ power of iBatis - the abilityto construct and refer to (call) statements through generic parameterobjects.The fact that it currentlytranslates the resultsets into an object model (ORM style), IMO, is really not its strength.As a matter of fact,it could be argued that /that/ part of iBatis is its /weakness/.Because people begin to expect the wholeORM kitchen sink with it too.Look at some of the comments Gavin is making about /lack/ of ORMfunctionality in iBatis because of this:http://forum.hibernate.org/viewtopic.php?t=946112view=nextsid=16a15cd9d22236aaded5c042ec758841 Does it support dirty checks. That is so totally irrelevant to iBatis. ORMs are not bad for WHAT they intend to do.They are sometimes just overcomplicated because of HOW they do it. Yes. We should be working with rich object models, not with two dimensional arrays of disorganized bits.Rich object models is the puzzle ORM's intend to solve.If iBatis is /all/ about that, then I'm afraid itis an ORM - and I fear Gavin is right when he says key functionality ismissing with iBatis.The fact is, we are not intending to use iBatis in that way.We havesuccessfully created models without rich object models that use simple beans and lists as disconnecteddatasets.And the concept worksperfectly.But it is cumbersome because we don't have the full power ofa cachedrowset or analogous. A concept like strongly typed datasets from .NET will be a /dream/! Hey, did you know that Hibernate supports strongly typed, disconnected data?Check it out.I will, thanks. :) But, I'd rather construct and organise my SQL/sp statements through iBatis.It's justso much better! Call it what you want, ORM or whatever.iBATIS is iBATIS.It does what it does.We're not trying to fit into any mold. And the last thing I want to do is waste my time defending ORM for iBatis' sake! If you have to defend it, there are two possibilities.1) iBATIS is the wrong choice for you're situation, or 2) you're talking to the wrong people.Either way, we don't typically build features simply to satisfy any debate.Woah, so iBatis is an ORM?Is that what we conclude here?Clinton, this is not just a debate for us.We have to make some hardchoices soon.If we go iBatis, the folks who want to use Hibernate will ask for the missing Hibernate featuresin iBatis.If I am going to make aconvincing case for my clients about the use of iBatis in adisconnected dataset scenario, I better make a compelling case that it supports the features easily.But I see, you are getting upset.:(
Re: iBatis and ORM's
On Friday 04 Nov 2005 15:17, Clinton Begin wrote: Quick comparison... ORM 1) Maps classes to tables, and columns to fields. 2) Must support Object Identity 3) Generates SQL SQL Mapping 1) Maps objects (not necessarily a custom type, or even the same type) to statements 2) Generally does not support object identity (would be hard to do) 3) Allows complete hand coding of real SQL, with full support for nearly all RDBMS features Wow - thank you very much. I had long been wondering why I was so attracted to iBatis rather than Hibernate given that the latter is obviously the way everyone has been going. Its made a light come on in my head. I have been moved to write a quick note in my blog about it (see http://home.chandlerfamily.org.uk/archive/26/ibatis-v-hiberbate) which I think gives an answer to Abdullah's question. -- Alan Chandler http://www.chandlerfamily.org.uk Open Source. It's the difference between trust and antitrust.
Re: iBatis and ORM's
Clinton Begin wrote: Try this with Hibernate: int i = (Integer) client.queryForObject (countUsersInGroup, MyGroup); select id=countUsersInGroup resultClass=int parameterClass=string SELECT Count(1) FROM Users WHERE GroupName = #groupName# /select So, we're saying Hibernate has to receive results from all (including ad hoc) queries to /map/ to Java classes! An ad hoc query that does not have a Table-to-Class association is /impossible/ to construct in Hibernate? In asking yourself why this isn't possible in Hibernate, you'll answer your first question. To answer the third question, try this with Hibernate: client.delete(deleteUsersInGroup, MyGroup); delete id=deleteUsersInGroup parameterClass=string DELETE FROM Users WHERE GroupName = #groupName# /delete In asking yourself why this isn't possible, you'll answer part of the third question. Understood. The rest of the answer to the third question is this: Generally systems involve many more SELECT statements than INSERT, UPDATE and DELETE combined. Usually all of the value in a relational database system is realized from the SELECT statements. Nobody makes money on INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very well (as long as you're not talking batch updates and deletes). But ORMs generally do very little for SELECT, and in fact, ORMs often complicate SELECT. Having experienced this myself, I'll say that beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs don't generally help much. Beautiful, I like this answer. g What ORMs do very well though is manage the relationships between objects and how the impact a change to one object should (or should not) imact related objects. ORMs also tend allow for much more effective caching of objects (thanks to OID). Yup. But anyway, this is an old discussion that's become way to old. Old, yes - but certainly not /concluded/ by a long shot! :-) The real answer to your question is another question: why are you comparing an ORM to iBATIS? For two reasons: 1. I am compiling a document that identifies a few ORM and data abstraction tools on a spectrum that looks like this: SET BASED OO BASED I then want to enumerate /characteristics/ of the different tools and give flavours to these characteristics by saying: ah, this one leans towards SET semantics or this one has a putrid stench of OO mentality. (You can see my bias! But I am not against OO! g) The second reason is based on my defense for the use of iBatis in our project. If I get asked why iBatis is /NOT/ an ORM tool, I need to answer that question in a cogent and decisive manner. Otherwise I will be faced with the task of defending the /lack/ of ORM type of functionality in iBatis! It's like comparing a Spreadsheet tool to a Word Processor. Love that! :) (So, where's my disconnected resultset - or spreadsheet in iBatis, Clinton!!! g) http://issues.apache.org/jira/browse/IBATIS-206
Re: iBatis and ORM's
Alan Chandler wrote: Wow - thank you very much. I had long been wondering why I was so attracted to iBatis rather than Hibernate given that the latter is obviously the way everyone has been going. Its made a light come on in my head. Yeah, I like the way Clinton writes about these things too! :) I have been moved to write a quick note in my blog about it (see http://home.chandlerfamily.org.uk/archive/26/ibatis-v-hiberbate) which I think gives an answer to Abdullah's question. Thanks, I am reading it right now!
Re: iBatis and ORM's
Alan Chandler wrote: http://home.chandlerfamily.org.uk/archive/26/ibatis-v-hiberbate) Quote In simple terms, Hibernate maps Java Objects to database tables. iBatis maps Java Objects to SQL statements. /Quote Hang on a sec here, don't we also map Java Classes to database tables with iBatis? A User class in my design maps to a User table in the database. Isn't this exactly how the iBatis docs tell us we should map our result beans? Even though we have the ability to get results like COUNT, AVERAGE etc from separate statements in iBatis, 90% of our usage will be based on the Class-to-Table mapping mentality - exactly the starting point of an ORM tool. So, given that situation, we are left with the challenges inherent in the Class-to-Table paradigm. (IMO, the remainder of the ORM conundrum!) :-) A challenge that arises when departing from the concept of handling data as SETS not objects!
Re: iBatis and ORM's
On Saturday 05 Nov 2005 09:38, Abdullah Kauchali wrote: Alan Chandler wrote: http://home.chandlerfamily.org.uk/archive/26/ibatis-v-hiberbate) Quote In simple terms, Hibernate maps Java Objects to database tables. iBatis maps Java Objects to SQL statements. /Quote Hang on a sec here, don't we also map Java Classes to database tables with iBatis? A User class in my design maps to a User table in the database. Isn't this exactly how the iBatis docs tell us we should map our result beans? Well a) I was simplifying, but yes we map to beans not objects - but I have a message that I want to get across b) We do NOT map directly to tables, only to the results of a SQL statement (which - as you say - might be a table). But the crux of my arguement is that although for simple CRUD you might have that simple mapping, any real application is more complex than that. Even though we have the ability to get results like COUNT, AVERAGE etc from separate statements in iBatis, 90% of our usage will be based on the Class-to-Table mapping mentality - exactly the starting point of an ORM tool. I disagree if you design your database with proper normalisation. In my recent family tree application of the 12 SELECT statements only 2 mapped directly to the table and 2 others half did (I added a dynamic where clause to limit the search via a filter). So, given that situation, we are left with the challenges inherent in the Class-to-Table paradigm. (IMO, the remainder of the ORM conundrum!) :-) A challenge that arises when departing from the concept of handling data as SETS not objects! As above, I think your premise to this bit is false -- Alan Chandler http://www.chandlerfamily.org.uk Open Source. It's the difference between trust and antitrust.
Re: iBatis and ORM's
What iBatis lets ME do is create a DAO base class that I can re-use. Eventualy DAO maps to a ... model suchas as TableModel (wahtever else... and TableModel maps to a jTableView. And TableModel is my disconected row set/data set that matheces my view requirment). The pooint of OO is to increase produtivity via reuse. I can write more OO w/ iBatis. Also, to me, relational and set (aka Collection) is more mathenmticaly correct view to the business problem I solve. ORM... thinks OO is having an instance of Object in some docs they have. So if I have an array[] of People... it does not match my business problem, I have to look how to rig it in. I don't have OO. And... I don't have SQL to make it fast. Yet another ex, Master Detail. In iBatis/datasets I retrieve a List of (a few fields) Maps for jTable (w/ page offsets in SQL). When user clicks on a row, I retrive a Map (of all or most fields) that coresposd to my Form. 2 hits to SQL, to get 2 sets, each optimized and tuned to what I want, /w DBA help. Matches my mock up of screen shots in requirments and I can unit test any and reproduce. In ORM... I keep an array of People[] is some ORM engine. It gives me a subset of People objects (w/ all the fields even if I don't need them in memory, each person object is a CRUD) and ORM computes page ofsets, etc. (ORM's have years of exeprience tunint request, SQL has decades of experrience tuning selects). When I click on a row, it does not hit the DB again, the row is there in array[]. To unit test... well, it depends what you had in ORM before, harder to break out a module (for those that think unit testing speads you up) You could ... force manaual SQL for each Person object and deltas and.. It does not fit and no OO and no PT (performance and tuing by DBA). If you work large sites... they could also have other lanages, .NET, PHP. The ORM architecture is just less portable to other tech stacks. .V Abdullah Kauchali wrote: 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. -- thx, .V Your Roomity Broadband Community http://roomity.com/demo.jsp cell: 917 825 3035 in DFW email: netsql at roomity.com
Re: iBatis and ORM's
Getting kind of philosophical here... On 11/5/05, Alan Chandler [EMAIL PROTECTED] wrote: Wow - thank you very much. I had long been wondering why I was so attracted to iBatis rather than Hibernate given that the latter is obviously the way everyone has been going. Its made a light come on in my head. You know...I have been wondering about that, too. I keep reading more and more about people using Hibernate with (struts/jsf/blah/whatever) on the lists that I am on, and I find myself wondering two things. The first is this: Are we seeing these messages because Hibernate is more difficult (i.e., people need help to implement) or becuase there are more people using it? By that, I mean are we seeing the noisy minority here? Having tried Hibernate before settling into iBATIS..I know my opinion on the matter. ;-) The second thing I find myself asking is why are we seeing so many ports of iBATIS into other languages...but not Hibernate? Where is the PHP version of hibernate? How about Ruby? I know there is NHibernate, but from what I have seen, it is not used nearly as much as iBATIS.NET is. Now, all of this could just be my perspective - I am in the iBATIS world, so I see iBATIS everywhere, but I do not think that is all there is too it. I keep waiting to see the JavaScript version to pop up with all the hype surrounding AJAX. ;-) OK, I need to get back to work now. :) Larry
Re: iBatis and ORM's
This is really good discussion. I hope you guys help Kim with the FAQ, and post your feature requests to JIRA (I think use iBATIS as a spreadsheet is already in there). ;-) Cheers, ClintonOn 11/5/05, Alan Chandler [EMAIL PROTECTED] wrote: On Saturday 05 Nov 2005 09:38, Abdullah Kauchali wrote: Alan Chandler wrote: http://home.chandlerfamily.org.uk/archive/26/ibatis-v-hiberbate) Quote In simple terms, Hibernate maps Java Objects to database tables. iBatis maps Java Objects to SQL statements. /Quote Hang on a sec here, don't we also map Java Classes to database tables with iBatis?A User class in my design maps to a User table in the database. Isn't this exactly how the iBatis docs tell us we should map our result beans?Wella) I was simplifying, but yes we map to beans not objects - but I have a message that I want to get acrossb) We do NOT map directly to tables, only to the results of a SQL statement(which - as you say - might be a table).But the crux of my arguement isthat although for simple CRUD you might have that simple mapping, any real application is more complex than that. Even though we have the ability to get results like COUNT, AVERAGE etc from separate statements in iBatis, 90% of our usage will be based on the Class-to-Table mapping mentality - exactly the starting point of an ORM tool.I disagree if you design your database with proper normalisation.In myrecent family tree application of the 12 SELECT statements only 2 mapped directly to the table and 2 others half did (I added a dynamic where clauseto limit the search via a filter). So, given that situation, we are left with the challenges inherent in the Class-to-Table paradigm.(IMO, the remainder of the ORM conundrum!):-)A challenge that arises when departing from the concept of handling data as SETS not objects!As above, I think your premise to this bit is false-- Alan Chandlerhttp://www.chandlerfamily.org.ukOpen Source. It's the difference between trust and antitrust.
Re: iBatis and ORM's
On Saturday 05 Nov 2005 14:51, Clinton Begin wrote: This is really good discussion. I hope you guys help Kim with the FAQ, and post your feature requests to JIRA (I think use iBATIS as a spreadsheet is already in there). ;-) Just dumped a simplified example of use of groupBy clause into the Wiki, because that was the main thing in the documentation that I never got, and had to ask about here. -- Alan Chandler http://www.chandlerfamily.org.uk Open Source. It's the difference between trust and antitrust.
RE: iBatis and ORM's
Here are is a record of my experiences with Hibernate on a recent web project where I was the team lead and had complete control over choice of technology. This message is in the spirit of theory vs. practice. A wise programmer once told me that Simple things should be simple and hard things should be doable. I was recently on a new project where I was the team lead and I made the choice to use hibernate. This was my first serious hibernate project and I found out that in Hibernate simple things are not so simple but the hard things are theoretically made easy by hibernate. However, I needed the simple things 80% and the hard stuff about 20% of the time. In my particular situation I had a very well designed data model that was built by a highly experienced data modeler. The data model was built a couple of weeks before I joined this project as the team lead and it had about 90 tables. The task of mapping this data model to hibernate was not very easy, in the end we went with a one table one class mapping. We had many association tables that carried the reasons why the association was there in the first place. So we had to expose the association tables as mapped hibernate objects (This was also the recommendation of the Hibernate in Action book). Developer productivity was the number one priority on this project, because we had a very tight deadline which we met). The idea behind ORM is that the developers would have only had to deal with the Java Objects but alas that was not doable they all ended up with print outs of the data model on their desks. After my experience with this project I do not sure that the goal of cleanly separating the Also many of our web pages had data on them that was very easy to grab via SQL however it would have required a lot of code to traverse from one java object to another to present those pages. Following the advice of the Hibernate in Action book we ended up using report queries to get our data out of the database. Almost every screen that we did had one or two report queries. The interesting thing is that the report queries in Hibernate turned out to be more complex to write and figure out. We frequently had to write queries in SQL then convert them to HQL. The whole idea of hibernate taking care of generating the SQL for you did not pan out. We still had to write a lot of queries. Many of the tables we had a lot of relationships to many other tables and I frequently found out that I could not map those relationships very easily to hibernate. At first I was tempted to go to the data modeler and ask him to change the relationships to make the hibernate mapping easier. The more I understood the business problem the more I figured out that he had done a great job and it was pointless to change the data model to try and make it more hibernate friendly. For the record the data modeler was great to work and he did not object to any changes that we requested. So I made the decision not to map the complex relationships to hibernate. Only simple relationships got mapped to hibernate, and this another disappointment for me with ORM Hibernate. It just seemed that I was always trying to fit a square into a circle. In the end I had one java class for each table in the database, only simple relationships were mapped. Complex relationships were not mapped and that simplified our project quite a bit and allowed us to get in on time. So we needed up with a lot of report queries in HQL which made use of the new operator in the HQL to stuff the results into java objects. At the time I started this project I did not know much about iBATIS and I knew a lot more about Hibernate. Developer productivity was one my keys goals and I figured that it would be easier for me and my team to have access to books on hibernate and there were more learning resources for hibernate. If I was doing this project again I would have probably gone with iBATIS since I eneded up using hiberante the iBATIS way! My intuition as a programmer is that mapping statements to classes is better than mapping classes to tables, simple because it more naturally fits the principle that simple things should be simple to do and hard things should be double. One of the key features of SQL is its clousure property every SQL query returns a table. If some one was making an Object Query language they would not be able to keep the colsure property or do projection in way that makes sense. This is why I think that mapping objects to statements is a better approach than mapping objects to tables. I hope the write up of my experience was worth the time you spent reading it. Adib
Re: iBatis and ORM's
Fantastic. Thanks for sharing Adib! I may even forward this on to a few people. Cheers, ClintonOn 11/5/05, Adib Saikali [EMAIL PROTECTED] wrote: Here are is a record of my experiences with Hibernate on a recent webproject where I was the team lead and had complete control over choice oftechnology. This message is in the spirit of theory vs. practice. A wise programmer once told me that Simple things should be simple and hardthings should be doable. I was recently on a new project where I was theteam lead and I made the choice to use hibernate. This was my first serious hibernate project and I found out that in Hibernate simple things are not sosimple but the hard things are theoretically made easy by hibernate.However, I needed the simple things 80% and the hard stuff about 20% of the time.In my particular situation I had a very well designed data model that wasbuilt by a highly experienced data modeler. The data model was built acouple of weeks before I joined this project as the team lead and it had about 90 tables.The task of mapping this data model to hibernate was not very easy, in theend we went with a one table one class mapping. We had many associationtables that carried the reasons why the association was there in the first place. So we had to expose the association tables as mapped hibernateobjects (This was also the recommendation of the Hibernate in Action book).Developer productivity was the number one priority on this project, because we had a very tight deadline which we met). The idea behind ORM is that thedevelopers would have only had to deal with the Java Objects but alas thatwas not doable they all ended up with print outs of the data model on their desks. After my experience with this project I do not sure that the goal ofcleanly separating theAlso many of our web pages had data on them that was very easy to grab viaSQL however it would have required a lot of code to traverse from one java object to another to present those pages. Following the advice of theHibernate in Action book we ended up using report queries to get our dataout of the database. Almost every screen that we did had one or two report queries.The interesting thing is that the report queries in Hibernate turned out tobe more complex to write and figure out. We frequently had to write queriesin SQL then convert them to HQL. The whole idea of hibernate taking care of generating the SQL for you did not pan out. We still had to write a lot ofqueries.Many of the tables we had a lot of relationships to many other tables and Ifrequently found out that I could not map those relationships very easily to hibernate. At first I was tempted to go to the data modeler and ask him tochange the relationships to make the hibernate mapping easier. The more Iunderstood the business problem the more I figured out that he had done a great job and it was pointless to change the data model to try and make itmore hibernate friendly. For the record the data modeler was great to workand he did not object to any changes that we requested. So I made the decision not to map the complex relationships to hibernate.Only simple relationships got mapped to hibernate, and this anotherdisappointment for me with ORM Hibernate. It just seemed that I was always trying to fit a square into a circle.In the end I had one java class for each table in the database, only simplerelationships were mapped. Complex relationships were not mapped and thatsimplified our project quite a bit and allowed us to get in on time. So we needed up with a lot of report queries in HQL which made use of the newoperator in the HQL to stuff the results into java objects.At the time I started this project I did not know much about iBATIS and I knew a lot more about Hibernate. Developer productivity was one my keysgoals and I figured that it would be easier for me and my team to haveaccess to books on hibernate and there were more learning resources for hibernate. If I was doing this project again I would have probably gone withiBATIS since I eneded up using hiberante the iBATIS way!My intuition as a programmer is that mapping statements to classes is better than mapping classes to tables, simple because it more naturally fits theprinciple that simple things should be simple to do and hard things shouldbe double.One of the key features of SQL is its clousure property every SQL query returns a table. If some one was making an Object Query language they wouldnot be able to keep the colsure property or do projection in way that makessense. This is why I think that mapping objects to statements is a better approach than mapping objects to tables.I hope the write up of my experience was worth the time you spent readingit.Adib
Re: iBatis and ORM's
Does iBATIS have a free wiki? There should be a section for good and bad testimonials. This is one worth keeping. __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: iBatis and ORM's
Yep, we have a wiki. It's linked from the homepage (Wiki in the sidebar). I've added this to the Feedback and Experiences section. Cheers, ClintonOn 11/5/05, Paul Benedict [EMAIL PROTECTED] wrote: Does iBATIS have a free wiki? There should be asection for good and bad testimonials. This is oneworth keeping.__Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com
Re: iBatis and ORM's
Man, this is a big one, and i am late already..i'll get it started. The question is not DAO vs ORM, it is ORM vs Data Mapping. ORM = mapping database objects to java objects (or c#, whatever). Data mapping = mapping sql *statements* to java objects (c#, blah, whatever). DAO can be used with either ORM or Data Mapping. More later... Larry On 11/4/05, Abdullah Kauchali [EMAIL PROTECTED] wrote: So, iBatis is /not/ an ORM. What makes Hibernate an ORM and iBatis not? or a corollary: What makes iBatis a DAO implementation and Hiberate not? (Is this a valid question, to begin with?) What are the /decisive/ qualities of each (viz. DAO vs ORM) that classify them appropriately? I am looking for the mosst important /distinguishing/ (different) characteristics of each approach so that when I now see a myriad of tools presented to me, I can say ah, but this one does it like this, so it /leans/ towards an ORM approach ... Kind regards Abdullah
Re: iBatis and ORM's
Quick comparison... ORM 1) Maps classes to tables, and columns to fields. 2) Must support Object Identity 3) Generates SQL SQL Mapping 1) Maps objects (not necessarily a custom type, or even the same type) to statements 2) Generally does not support object identity (would be hard to do) 3) Allows complete hand coding of real SQL, with full support for nearly all RDBMS features DAO Irrelevant. DAO is an abstraction pattern. It serves a different design purpose entirely. Cheers, Clinton On 11/4/05, Abdullah Kauchali [EMAIL PROTECTED] wrote: So, iBatis is /not/ an ORM.What makes Hibernate an ORM and iBatis not?or a corollary:What makes iBatis a DAO implementation and Hiberate not? (Is this avalid question, tobegin with?) What are the /decisive/ qualities of each (viz. DAO vs ORM) thatclassify them appropriately?I am looking for the mosst important /distinguishing/ (different)characteristics of each approachso that when I now see a myriad of tools presented to me, I can say ah, but this one does itlike this, so it /leans/ towards an ORM approach ...Kind regardsAbdullah
Re: iBatis and ORM's
Fantastic. Some more questions in-line. g Clinton Begin wrote: ORM 1) Maps classes to tables, and columns to fields. Don't we do that with iBatis too? Are we saying that mapping classes to tables, and columns to fields is generally a bad idea? 2) Must support Object Identity Yes, of course. Excellent point, thanks! 3) Generates SQL Agreed. But tools like Hibernate allow for adhoc queries. Could the fact that this escape hatch (to allow for ad hoc or hand written queries) be taken as an argument that such tools are in fact exactly like iBatis but with /more/ features? (Did I phrase that right?) I guess, what I really want to ask is: what is the trade-off or compromise in the design when Hibernate users begin to use the ad hoc query facilty? (There has to be a cost! :-) ) SQL Mapping 1) Maps objects (not necessarily a custom type, or even the same type) to statements Clinton, I am trying to understand this carefully. Don't you mean map objects to rows of a resultset created from a statement? If so, how is this any different from what Hibernate does with the ad hoc facility. 2) Generally does not support object identity (would be hard to do) Ok, great. Excellent point. 3) Allows complete hand coding of real SQL, with full support for nearly all RDBMS features Fantastic! Regards, Abdullah
Re: iBatis and ORM's
Larry Meadors wrote: Man, this is a big one, and i am late already..i'll get it started. Sorry. :) I know Friday's almost over, but I need some ammo for something I am preparing for next week. The question is not DAO vs ORM, it is ORM vs Data Mapping. Got it! ORM = mapping database objects to java objects (or c#, whatever). Yeah, tables to java objects. Cool. Data mapping = mapping sql *statements* to java objects (c#, blah, whatever). This is what I am trying to understand. How's this any different from what Hibernate does? DAO can be used with either ORM or Data Mapping. Yup. Much like what Spring does by allowing either iBatis or Hibernate to operate as the data layer? More later... Much appreciated! Believe me! I love you guys! :-D
Re: iBatis and ORM's
Try this with Hibernate: int i = (Integer) client.queryForObject (countUsersInGroup, MyGroup); select id=countUsersInGroup resultClass=int parameterClass=string SELECT Count(1) FROM Users WHERE GroupName = #groupName# /select In asking yourself why this isn't possible in Hibernate, you'll answer your first question. To answer the third question, try this with Hibernate: client.delete(deleteUsersInGroup, MyGroup); delete id=deleteUsersInGroup parameterClass=string DELETE FROM Users WHERE GroupName = #groupName# /delete In asking yourself why this isn't possible, you'll answer part of the third question. The rest of the answer to the third question is this: Generally systems involve many more SELECT statements than INSERT, UPDATE and DELETE combined. Usually all of the value in a relational database system is realized from the SELECT statements. Nobody makes money on INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very well (as long as you're not talking batch updates and deletes). But ORMs generally do very little for SELECT, and in fact, ORMs often complicate SELECT. Having experienced this myself, I'll say that beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs don't generally help much. What ORMs do very well though is manage the relationships between objects and how the impact a change to one object should (or should not) imact related objects. ORMs also tend allow for much more effective caching of objects (thanks to OID). But anyway, this is an old discussion that's become way to old. The real answer to your question is another question: why are you comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool to a Word Processor. Cheers, Clinton On 11/4/05, Abdullah Kauchali [EMAIL PROTECTED] wrote: Fantastic.Some more questions in-line. gClinton Begin wrote: ORM 1) Maps classes to tables, and columns to fields.Don't we do that with iBatis too? Are we saying that mapping classes to tables, and columns tofields is generally a bad idea? 2) Must support Object IdentityYes, of course.Excellent point, thanks! 3) Generates SQLAgreed.But tools like Hibernate allow for adhoc queries.Could the fact that this escape hatch(to allow for ad hoc or hand written queries) be taken as an argumentthat such tools are in factexactly like iBatis but with /more/ features?(Did I phrase that right?)I guess, what I really want toask is:what is the trade-off or compromise in the design whenHibernate users begin to use thead hoc query facilty?(There has to be a cost!:-)) SQL Mapping 1) Maps objects (not necessarily a custom type, or even the same type) to statementsClinton, I am trying to understand this carefully.Don't you mean mapobjects to rows of a resultset created from a statement?If so, how is this any different from what Hibernate does with the adhoc facility. 2) Generally does not support object identity (would be hard to do)Ok, great.Excellent point. 3) Allows complete hand coding of real SQL, with full support for nearly all RDBMS featuresFantastic!Regards,Abdullah
Re: iBatis and ORM's
Preamble/disclaimer: It is late on friday afternoon. On 11/4/05, Kim Goings [EMAIL PROTECTED] wrote: Clinton - This discussion is probably far too old for you since you've been around it for so long. :) I think it's still valid. I've Clinton, Kim just called you OLD, I think. ;-) started to become quite the iBatis evangelist and when people ask why I think it is better or how it is different than Hibernate, the points you (and others) have made here are what I need to back me up. Like it or not, when people are deciding what to use on a project, it's not uncommon for iBatis and Hibernate to be the top two contenders. Maybe that's a growing trend stemming from painful Hibernate experiences. I think in many cases, people have realized they don't really need an ORM, but are fearful of pulling away because Hibernate is the hip way to go these days. H, does that make iBATIS a hip-replacement? Interesting notion..I sense a lot of old humor here... They are different things and, as always, the best choice really does depend on the project. But for the most part, I think the decision often lies in the answer to Are you comfortable with SQL? or Do you have a DBA? (who presumably wants more control over what your app does to the db than Hibernate allows). AnywayI love iBatis and would be hard-pressed to find any situation where it wasn't the best, or at least sufficient, choice. I agree. 100% Larry
Re: iBatis and ORM's
Sorry everyone. I didn't mean to sound like I don't care about such comparisons. I think it is old for me, and I'm able to look at situation objectively and decide whether Hibernate or iBATIS (or neither) is the best choice. To me, it seems obvious. Perhaps this is a VERY long overdue FAQ that we need to add. Anyone care to start it and begin collecting these thoughts? I would, but apparently I'm too jaded. ;-) Cheers, Clinton On 11/4/05, Kim Goings [EMAIL PROTECTED] wrote: Clinton - This discussion is probably far too old for you since you'vebeen around it for so long.:)I think it's still valid.I'vestarted to become quite the iBatis evangelist and when people ask why Ithink it is better or how it is different than Hibernate, the points you (and others) have made here are what I need to back me up.Like it or not, when people are deciding what to use on a project, it'snot uncommon for iBatis and Hibernate to be the top two contenders.Maybe that's a growing trend stemming from painful Hibernate experiences.I think in many cases, people have realized they don'treally need an ORM, but are fearful of pulling away because Hibernateis the hip way to go these days.They are different things and, as always, the best choice really does depend on the project.But for the most part, I think the decisionoften lies in the answer to Are you comfortable with SQL?or Do youhave a DBA?(who presumably wants more control over what your app does to the db than Hibernate allows).AnywayI love iBatis and would be hard-pressed to find any situationwhere it wasn't the best, or at least sufficient, choice.KimOn Nov 4, 2005, at 4:55 PM, Clinton Begin wrote: Try this with Hibernate:int i = (Integer) client.queryForObject (countUsersInGroup, MyGroup);select id=countUsersInGroup resultClass=int parameterClass=string SELECT Count(1) FROM Users WHERE GroupName = #groupName#/select In asking yourself why this isn't possible in Hibernate, you'll answer your first question.To answer the third question, try this with Hibernate:client.delete(deleteUsersInGroup, MyGroup);delete id=deleteUsersInGroup parameterClass=string DELETE FROM Users WHERE GroupName = #groupName#/deleteIn asking yourself why this isn't possible, you'll answer part of the third question.The rest of the answer to the third question is this: Generally systems involve many more SELECT statements than INSERT, UPDATE and DELETE combined. Usually all of the value in a relational database system is realized from the SELECT statements. Nobody makes money on INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very well (as long as you're not talking batch updates and deletes). But ORMs generally do very little for SELECT, and in fact, ORMs often complicate SELECT. Having experienced this myself, I'll say that beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs don't generally help much.What ORMs do very well though is manage the relationships between objects and how the impact a change to one object should (or should not) imact related objects. ORMs also tend allow for much more effective caching of objects (thanks to OID).But anyway, this is an old discussion that's become way to old. The real answer to your question is another question: why are you comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool to a Word Processor.Cheers,Clinton On 11/4/05, Abdullah Kauchali [EMAIL PROTECTED] wrote: Clinton Begin wrote: ORM 1) Maps classes to tables, and columns to fields. Don't we do that with iBatis too? Are we saying that mapping classes to tables, and columns to fields is generally a bad idea? 2) Must support Object Identity Yes, of course.Excellent point, thanks! 3) Generates SQL Agreed.But tools like Hibernate allow for adhoc queries.Could the fact that this escape hatch (to allow for ad hoc or hand written queries) be taken as an argument that such tools are in fact exactly like iBatis but with /more/ features?(Did I phrase that right?)I guess, what I really want to ask is:what is the trade-off or compromise in the design when Hibernate users begin to use the ad hoc query facilty?(There has to be a cost!:-)) SQL Mapping 1) Maps objects (not necessarily a custom type, or even the same type) to statements Clinton, I am trying to understand this carefully.Don't you mean map objects to rows of a resultset created from a statement? If so, how is this any different from what Hibernate does with the ad hoc facility. 2) Generally does not support object identity (would be hard to do) Ok, great.Excellent point. 3) Allows complete hand coding of real SQL, with full support for nearly all RDBMS features Fantastic! Regards, Abdullah
Re: iBatis and ORM's
Clinton, Kim just called you OLD, I think. ;-) Yeah, but in dog years, I'm only 4. ClintonOn 11/4/05, Larry Meadors [EMAIL PROTECTED] wrote: Preamble/disclaimer: It is late on friday afternoon.On 11/4/05, Kim Goings [EMAIL PROTECTED] wrote: Clinton - This discussion is probably far too old for you since you've been around it for so long.:)I think it's still valid.I'veClinton, Kim just called you OLD, I think. ;-) started to become quite the iBatis evangelist and when people ask why I think it is better or how it is different than Hibernate, the points you (and others) have made here are what I need to back me up. Like it or not, when people are deciding what to use on a project, it's not uncommon for iBatis and Hibernate to be the top two contenders. Maybe that's a growing trend stemming from painful Hibernate experiences.I think in many cases, people have realized they don't really need an ORM, but are fearful of pulling away because Hibernate is the hip way to go these days.H, does that make iBATIS a hip-replacement? Interestingnotion..I sense a lot of old humor here... They are different things and, as always, the best choice really does depend on the project.But for the most part, I think the decision often lies in the answer to Are you comfortable with SQL?or Do you have a DBA?(who presumably wants more control over what your app does to the db than Hibernate allows). AnywayI love iBatis and would be hard-pressed to find any situation where it wasn't the best, or at least sufficient, choice.I agree. 100% Larry
Re: iBatis and ORM's
I will try. I've only been able to convert 2 people so far and would love to reach more. :) Kim On Nov 4, 2005, at 5:49 PM, Clinton Begin wrote: Sorry everyone. I didn't mean to sound like I don't care about such comparisons. I think it is old for me, and I'm able to look at situation objectively and decide whether Hibernate or iBATIS (or neither) is the best choice. To me, it seems obvious. Perhaps this is a VERY long overdue FAQ that we need to add. Anyone care to start it and begin collecting these thoughts? I would, but apparently I'm too jaded. ;-) Cheers, Clinton On 11/4/05, Kim Goings [EMAIL PROTECTED]> wrote: been around it for so long. :) I think it's still valid. I've started to become quite the iBatis evangelist and when people ask why I think it is better or how it is different than Hibernate, the points you (and others) have made here are what I need to back me up. Like it or not, when people are deciding what to use on a project, it's not uncommon for iBatis and Hibernate to be the top two contenders. Maybe that's a growing trend stemming from painful Hibernate experiences. I think in many cases, people have realized they don't really need an ORM, but are fearful of pulling away because Hibernate is the hip way to go these days. They are different things and, as always, the best choice really does depend on the project. But for the most part, I think the decision often lies in the answer to Are you comfortable with SQL? or Do you have a DBA? (who presumably wants more control over what your app does to the db than Hibernate allows). AnywayI love iBatis and would be hard-pressed to find any situation where it wasn't the best, or at least sufficient, choice. Kim On Nov 4, 2005, at 4:55 PM, Clinton Begin wrote: > > Try this with Hibernate: > > int i = (Integer) client.queryForObject (countUsersInGroup, > MyGroup); > > select id=countUsersInGroup resultClass=int > parameterClass=string> > SELECT Count(1) FROM Users WHERE GroupName = #groupName# > /select> > > In asking yourself why this isn't possible in Hibernate, you'll answer > your first question. > > To answer the third question, try this with Hibernate: > > client.delete(deleteUsersInGroup, MyGroup); > > delete id=deleteUsersInGroup parameterClass=string> > DELETE FROM Users WHERE GroupName = #groupName# > /delete> > > In asking yourself why this isn't possible, you'll answer part of the > third question. > > The rest of the answer to the third question is this: Generally > systems involve many more SELECT statements than INSERT, UPDATE and > DELETE combined. Usually all of the value in a relational database > system is realized from the SELECT statements. Nobody makes money on > INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very > well (as long as you're not talking batch updates and deletes). But > ORMs generally do very little for SELECT, and in fact, ORMs often > complicate SELECT. Having experienced this myself, I'll say that > beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs > don't generally help much. > > What ORMs do very well though is manage the relationships between > objects and how the impact a change to one object should (or should > not) imact related objects. ORMs also tend allow for much more > effective caching of objects (thanks to OID). > > But anyway, this is an old discussion that's become way to old. The > real answer to your question is another question: why are you > comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool to > a Word Processor. > > Cheers, > Clinton > > > > > > On 11/4/05, Abdullah Kauchali [EMAIL PROTECTED]> wrote: >> >> Clinton Begin wrote: >> >> > ORM >> > >> > 1) Maps classes to tables, and columns to fields. >> >> Don't we do that with iBatis too? Are we saying that mapping classes >> to tables, and columns to >> fields is generally a bad idea? >> >> > 2) Must support Object Identity >> >> Yes, of course.Excellent point, thanks! >> >> > 3) Generates SQL >> >> Agreed.But tools like Hibernate allow for adhoc queries.Could the >> fact that this escape hatch >> (to allow for ad hoc or hand written queries) be taken as an >> argument >> that such tools are in fact >> exactly like iBatis but with /more/ features?(Did I phrase that >> right?)I guess, what I really want to >> ask is:what is the trade-off or compromise in the design when >> Hibernate users begin to use the >> ad hoc query facilty?(There has to be a cost!:-)) >> >> > >> > SQL Mapping >> > >> > 1) Maps objects (not necessarily a custom type, or even the same >> type) >> > to statements >> >> Clinton, I am trying to understand this carefully.Don't you mean >> map >> objects to rows of a resultset >> created from a statement? >> >> If so, how is this any different from what Hibernate does with the ad >> hoc facility. >> >> > 2) Generally does not support object identity (would be hard to do) >> >> Ok, great.Excellent
Re: iBatis and ORM's
But if those two people convert two people each.exponential growth!On 11/4/05, Kim Goings [EMAIL PROTECTED] wrote:I will try.I've only been able to convert 2 people so far and would love to reach more.:)KimOn Nov 4, 2005, at 5:49 PM, Clinton Begin wrote:Sorry everyone. I didn't mean to sound like I don't care about such comparisons.I think it is old for me, and I'm able to look at situation objectively and decide whether Hibernate or iBATIS (or neither) is the best choice. To me, it seems obvious.Perhaps this is a VERY long overdue FAQ that we need to add. Anyone care to start it and begin collecting these thoughts? I would, but apparently I'm too jaded. ;-)Cheers,Clinton On 11/4/05, Kim Goings [EMAIL PROTECTED] wrote: been around it for so long.:)I think it's still valid.I've started to become quite the iBatis evangelist and when people ask why I think it is better or how it is different than Hibernate, the points you (and others) have made here are what I need to back me up. Like it or not, when people are deciding what to use on a project, it's not uncommon for iBatis and Hibernate to be the top two contenders. Maybe that's a growing trend stemming from painful Hibernate experiences.I think in many cases, people have realized they don't really need an ORM, but are fearful of pulling away because Hibernate is the hip way to go these days. They are different things and, as always, the best choice really does depend on the project.But for the most part, I think the decision often lies in the answer to Are you comfortable with SQL?or Do you have a DBA?(who presumably wants more control over what your app does to the db than Hibernate allows). AnywayI love iBatis and would be hard-pressed to find any situation where it wasn't the best, or at least sufficient, choice. Kim On Nov 4, 2005, at 4:55 PM, Clinton Begin wrote: Try this with Hibernate: int i = (Integer) client.queryForObject (countUsersInGroup, MyGroup); select id=countUsersInGroup resultClass=int parameterClass=string SELECT Count(1) FROM Users WHERE GroupName = #groupName# /select In asking yourself why this isn't possible in Hibernate, you'll answer your first question. To answer the third question, try this with Hibernate: client.delete(deleteUsersInGroup, MyGroup); delete id=deleteUsersInGroup parameterClass=string DELETE FROM Users WHERE GroupName = #groupName# /delete In asking yourself why this isn't possible, you'll answer part of the third question. The rest of the answer to the third question is this: Generally systems involve many more SELECT statements than INSERT, UPDATE and DELETE combined. Usually all of the value in a relational database system is realized from the SELECT statements. Nobody makes money on INSERT, UPDATE and DELETE. ORM solves INSERT, UPDATE and DELETE very well (as long as you're not talking batch updates and deletes). But ORMs generally do very little for SELECT, and in fact, ORMs often complicate SELECT. Having experienced this myself, I'll say that beyond INSERT, UPDATE by PK, DELETE by PK and SELECT by PKORMs don't generally help much. What ORMs do very well though is manage the relationships between objects and how the impact a change to one object should (or should not) imact related objects. ORMs also tend allow for much more effective caching of objects (thanks to OID). But anyway, this is an old discussion that's become way to old. The real answer to your question is another question: why are you comparing an ORM to iBATIS? It's like comparing a Spreadsheet tool to a Word Processor. Cheers, Clinton On 11/4/05, Abdullah Kauchali [EMAIL PROTECTED] wrote: Clinton Begin wrote:ORM 1) Maps classes to tables, and columns to fields. Don't we do that with iBatis too? Are we saying that mapping classes to tables, and columns to fields is generally a bad idea? 2) Must support Object Identity Yes, of course.Excellent point, thanks!3) Generates SQL Agreed.But tools like Hibernate allow for adhoc queries.Could the fact that this escape hatch (to allow for ad hoc or hand written queries) be taken as an argument that such tools are in fact exactly like iBatis but with /more/ features?(Did I phrase that right?)I guess, what I really want to ask is:what is the trade-off or compromise in the design when Hibernate users begin to use the ad hoc query facilty?(There has to be a cost!:-)) SQL Mapping 1) Maps objects (not necessarily a custom type, or even the same type) to statements Clinton, I am trying to understand this carefully.Don't you mean map objects to rows of a resultset created from a statement? If so, how is this any different from what Hibernate does with the ad hoc facility.2) Generally does not support object identity (would be hard to do) Ok, great.Excellent point.3) Allows complete hand coding of real SQL, with full support for nearly all RDBMS features Fantastic!
Re: iBatis and ORM's
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 PT, 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
