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).
>>
>> Anyway....I 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
PK....ORMs
>> > 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 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
>> >>
>>
