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: Dynamic queries w/o using <dynamic> tags in sql?
Date Tue, 13 May 2008 22:16:47 GMT
>> also it's not a business exception if the business allows different
people to update only certain fields...

Again, that's a pretty fundamental separation of concerns.  That is a
security/authorization consideration, which has nothing to do with
concurrency.  And if these records are stored in the same row in the
database, and they're not mutually exclusive, then it is a business
exception.

If they are stored on separate rows in a skinny data model, and/or are
mutually exclusive, then I'd still opt for an optimistic locking model
and just reload the object as necessary.

If this happens frequently, then neither Hibernate nor iBATIS is the
right tool for the job.  You'll want to build a custom solution for
something like that, because you're really dealing with attribute
level transactional behavior, which is far different from the row
based transactional behavior of a relational database.

Best,
Clinton

On Tue, May 13, 2008 at 4:11 PM, Josh Joy <joshjdevl@gmail.com> wrote:
> I guess I'll just look into this further then...I think I have a decent
> enough understanding of concurrency...I'm just of the mood to let the
> database handle the concurrency issues for me as much as possible rather
> bringing it to the java object side...
>
> Going back to the original question...it seems that the answer is no...there
> is no other way to dynamically generate sql for updates for ibatis other
> than specifying the <dynamic> tag in sqll
>
> (also it's not a business exception if the business allows different people
> to update only certain fields....)
>
> Thanks for info,
> Josh
>
>
>
> On Tue, May 13, 2008 at 4:55 PM, Clinton Begin <clinton.begin@gmail.com>
> wrote:
> > Josh...
> >
> > I think you really need to look into this further, as you have a
> > fundamental misunderstanding of concurrency issues and databases.
> >
> > * Separating the updates at the column level will NOT solve any
> > concurrency problem
> > * Concurrency issues are solved using either an optimistic or
> > pessimistic locking model at the row level
> >
> > I recommend optimistic for most systems.
> >
> >
> > Table Josh
> >  id
> >  name
> >  weburl
> >  timestamp
> >
> > update josh set ..., timestamp = now() where id = ? and timestamp = ?
> >
> > If the timestamps don't match, it's not simply a technical problem of
> > reloading the object. You have to tell the user what happened... it's
> > a business exception. What if the user would have changed the name
> > differently if the URL was different or vice versa?
> >
> > Pessimistic locking would lock the record so that it could not be
> > updated (and in some cases not even read) until it's unlocked.  It's
> > rare to need this type of locking in most business applications.
> >
> > This is a pretty core concept in database programming that you should
> > understand before using iBATIS, Hibernate or even just JDBC.  One book
> > I can recommend is Java Transaction Processing (Mark Little), page 11
> > - 12.
> >
> > Any other book recommendations from anyone else?
> >
> > Cheers,
> > Clinton
> >
> >
> >
> >
> > On Tue, May 13, 2008 at 3:36 PM, Josh Joy <joshjdevl@gmail.com> wrote:
> > >
> > > Table Josh
> > >   id
> > >   name
> > >   weburl
> > >
> > > If one user wants to update the name, and another user wants to update
> the
> > > weburl...how to avoid concurrency issues if I have to do a reload of the
> > > entire object?
> > > Please let me know how to configure Ibatis to handle state concurrency
> > > issues if I have to fetch the entire object...
> > >
> > >
> > > Thanks,
> > > Josh
> > >
> > >
> > >
> > >
> > > On Tue, May 13, 2008 at 4:25 PM, Clinton Begin <clinton.begin@gmail.com>
> > > wrote:
> > > > So is it completely out of the question to just load up the whole
> > > > object and save the whole object?  Why do you ever need any
> > > > conditionals or partial updates at all?  The only reason is
> > > > performance (and even that really depends on the details).
> > > >
> > > > I don't see the problem here... :-/
> > > >
> > > > Clinton
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, May 13, 2008 at 3:11 PM, Josh Joy <joshjdevl@gmail.com>
wrote:
> > > > > Thanks Clinton for your reply.
> > > > >
> > > > > Just to clarify...I'm not looking for any performance
> > > optimizations...when I
> > > > > say best practices I'm referring to dynamically choosing which
> fields to
> > > > > update...
> > > > >
> > > > > it comes down strictly to simplicity and readability...I don't see
a
> > > reason
> > > > > to fetch the latest entries for a row just so I can do an update
> (and
> > > how
> > > > > can I possibly guarantee it's the latest entry) nor do I see a
> reason to
> > > > > write multiple update statements or an if statement laden sql for
> all
> > > the
> > > > > possible update situations that can occur...
> > > > >
> > > > > I'll start poking around the api to see if I can wrap something up
> for
> > > my
> > > > > needs for now I guess... (unless anyone has any other suggestions,
> code
> > > > > snippets, or patches to share...)
> > > > >
> > > > > Thanks,
> > > > > Josh
> > > > >
> > > > >
> > > > >
> > > > >  On Tue, May 13, 2008 at 3:53 PM, Clinton Begin
> > > <clinton.begin@gmail.com>
> > > > > wrote:
> > > > > > Wow, I managed to lay down 3 or 4 run-on sentences in a row
> there...
> > > > > > Sorry Mr. McMillan...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, May 13, 2008 at 2:52 PM, Clinton Begin
> > > <clinton.begin@gmail.com>
> > > > > wrote:
> > > > > > > Josh,
> > > > > > >
> > > > > > >  Some people do care enough about this to do something
about it.
> > > And
> > > > > > >  yes, Hibernate is able to support it easily, because it
has
> dirty
> > > > > > >  checking, object identity and generates the SQL for the
update.
> > > > > > >
> > > > > > >  iBATIS is a SQL based framework.  It does not generate
the SQL
> for
> > > > > > >  you, nor does it track dirty state or object identity
etc.
> It's
> > > > > > >  pretty safe to say that iBATIS will never support this
in any
> way,
> > > > > > >  even if we do add SQL generation for convenience, the
lack of
> dirty
> > > > > > >  checking etc. will keep this from ever being a practical
> > > possibility.
> > > > > > >
> > > > > > >  I recommend looking into your particular situation.  I'd
bet
> that
> > > it
> > > > > > >  doesn't matter as much as you think it does, or if it
does
> matter
> > > in
> > > > > > >  one or two cases -- handle those cases as a performance
tweak.
> > > > > > >
> > > > > > >  To answer your question about best practices, I'm not
sure
> anyone
> > > has
> > > > > > >  ever told me that this was a fully agreed upon best practice,
> but I
> > > do
> > > > > > >  know a lot of people that think that premature performance
> > > > > > >  optimization is a practice to avoid...
> > > > > > >
> > > > > > >  Cheers,
> > > > > > >  Clinton
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >  On Tue, May 13, 2008 at 2:37 PM, Josh Joy <joshjdevl@gmail.com>
> > > wrote:
> > > > > > >  >
> > > > > > >  >
> > > > > > >  > Hi,
> > > > > > >  >
> > > > > > >  >
> > > > > > >  >
> > > > > > >  >
> > > > > > >  > If I have an sql like the following...
> > > > > > >  >
> > > > > > >  >
> > > > > > >  >
> > > > > > >  >
> > > > > > >  > <select id="updateEmployees" >
> > > > > > >  >
> > > > > > >  >      Update  emp
> > > > > > >  >
> > > > > > >  >       <dynamic prepend="WHERE">
> > > > > > >  >
> > > > > > >  >               set
> > > > > > >  >
> > > > > > >  >
> > > > > > >  >             <isNotEmpty prepend="AND" property="id">
> > > > > > >  >
> > > > > > >  >                   empno=#id#
> > > > > > >  >
> > > > > > >  >             </isNotEmpty>
> > > > > > >  >
> > > > > > >  >             <isNotEmpty prepend="OR" property="name">
> > > > > > >  >
> > > > > > >  >                   ename=#name#
> > > > > > >  >
> > > > > > >  >             </isNotEmpty>
> > > > > > >  >
> > > > > > >  >       </dynamic>
> > > > > > >  >
> > > > > > >  > </select>
> > > > > > >  >
> > > > > > >  >
> > > > > > >  >
> > > > > > >  >
> > > > > > >  > Is there a way to instruct Ibatis to ignore nulls
without
> having
> > > to
> > > > > actually
> > > > > > >  > use a dynamic tag? I would just like to set my bean
entity
> with
> > > the
> > > > > > >  > properties that I want updated, and leave null the
ones I
> want to
> > > > > ignore...
> > > > > > >  >
> > > > > > >  > I know in Hibernate there is a way to do this, is
there an
> > > equivalent
> > > > > in
> > > > > > >  > Ibatis? It seems like a lot of xml code to write
for all my
> > > > > updates...
> > > > > > >  >
> > > > > > >  > Is this not a best practice not to have dynamic updates,
> because
> > > I'm
> > > > > unsure
> > > > > > >  > why I would have to explicitly set this in the XML?
As far as
> I
> > > know,
> > > > > SQL
> > > > > > >  > updates (unless using a specific database vendor
call) are on
> a
> > > per
> > > > > table
> > > > > > >  > basis. Is it not recommended to have an entity and
not always
> > > have to
> > > > > update
> > > > > > >  > all the fields? If I wanted to modify the Ibatis
API for my
> own
> > > needs
> > > > > for
> > > > > > >  > the updates, where would someone recommend I start?
> > > > > > >  >
> > > > > > >  >
> > > > > > >  >
> > > > > > >  >
> > > > > > >  > Thanks,
> > > > > > >  >
> > > > > > >  > Josh
> > > > > > >  >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

Mime
View raw message