ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject Re: iBatis and ORM's
Date Fri, 04 Nov 2005 22:55:31 GMT
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 <abdullah.kauchali@isanusi.com> wrote:
>
> 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
>
>

Mime
View raw message