ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Meadors <larry.mead...@gmail.com>
Subject Re: a few questions
Date Fri, 28 Jan 2005 13:10:57 GMT
I cannot speak for the rest of the team, but if it were up to me,
probably not. :-/

Some of the most attractive things about iBATIS (for many users) are
simplicity, the fact that it does not mess with your SQL unless it is
absolutely neccessary, that it does not impose anything on your
development, and that it is not database specific.

Please do not take my comments the wrong way: I am not saying that
what you are asking for is of no value, but many of them go directly
against those points.

Creating DDL, is VERY database specific, especially when you start
talking about generating keys, datatypes, tablespaces, and so on. The
differences between Oracle, MySQL, and M$SQL alone would be
significant enough to eat up weeks of development time that could be
used to do other things.

The other two things on the list (3 & 4), IMO are more the domain of
the DAO or business logic layer.

But you may be able to convince me otherwise! I am not dead against us
doing that if we can do it in a way that meets the criteria above. :-)

One of the valuable things in iBATIS is that it is powerful, yet
constructed in such a way that you can leverage it without becoming
married to it. Let me see if I can explain that in a way that makes

Before using iBATIS, I used Hibernate. It sounded great - it was very
powerful and did many of the things you described above. It would
generate DDL, do optimistic locking, and inserts like you described
worked. But, the problem was that I had to define my database
according to Hibernate's rules. I also needed to have a stateful
environment to keep persisted objects in to keep them "fresh" for
Hibernate. I also had to implement Hibernate specific interfaces in my
code to make certain features work. Pretty soon, I was not writing
applications according to the standards of the company I worked for,
but instead, according to the standards of Hibernate. That (to me) is
an anti-pattern called "Vendor Lock-in", and to be avoided.

Now, I use iBATIS. My applications could not care less that I am using
iBATIS, because the only part that has to be aware of it is the DAO
layer. Yes, I have to implement the audit trail, and optimistic
locking on my own, but, if I want to use another DAO implementation, I


On Fri, 28 Jan 2005 11:02:06 +0800, Nathan Coast <nathan@codeczar.com> wrote:
> great, thanks for the quick response,  its pretty much as I figured when
> I couldn't find anything covering these in the docs.  Do you know if
> there is any support for these features planned in future releases?
> Larry Meadors wrote:
> > 1) No.
> >
> > 2) Yes, you can do that for either auto-generated or assigned keys.
> >
> > 3) No.
> >
> > 4) No.
> >
> > That said, 3 & 4 can be pretty simple to build, depending on how
> > intricate you want to get with them.
> >
> > Larry
> >
> > On Fri, 28 Jan 2005 10:16:42 +0800, Nathan Coast <nathan@codeczar.com> wrote:
> >
> >>1) ddl - is it possible to define your table structures in ibatis and
> >>have ibatis create the tables?
> >>
> >>2) inserts - is the primary key retuned for all calls to the
> >>SqlMapExecutor.insert method.  I have only seen examples in the docs for
> >>inserts that require a <selectKey> (oracle, ms sql server) what about
> >>auto generated keys (e.g. mysql)?
> >>
> >>3) optimistic locking - is there any declarative support for optimistic
> >>locking - e.g. having a last_modified column in the db / object throw an
> >>error during the update method if the last mod in the value is different
> >>from the db.
> >>
> >>4) audit trail - 4 cols: created_by, created_timestamp, modified_by,
> >>modified_timestamp. again updated by the framework during insert, update
> >>statements.  would require some form of authentication (jaas) from the
> >>enclosing container.  I'm guessing the majority of apps run in one
> >>container or another tomcat, jboss etc so should be possible.
> >>
> >>Just trying to get a feel for what we'd get for free, what we'd have to
> >>build and what may be coming soon.
> >
> >
> >
> --
> Nathan Coast
> Managing Director
> Codeczar Ltd
> mob : (852) 9049 5581
> tel : (852) 2834 8733
> fax : (852) 2834 8755
> web : http://www.codeczar.com

View raw message