I was thinking more like using timestamp or version field in the ibator
config. That way we give the developer the option. If you have quite a few
tables for creating CRUD, this will be a useful configuration.
will wait to see zoran's ideas on relationships.
regards
Ashok
On Tue, Apr 15, 2008 at 11:22 AM, Jeff Butler <[EMAIL PROTECTED]> wrote:
> Hi Ashok,
>
> Regarding optimistic locking - ibator supports optimistic locking with the
> "updateByExample" method already introduced in version 1.1. You could
> easily write a DAO method that included a timestamp or version count in the
> where clause of an update. For example, something like this:
>
> public MyDao extends GeneratedDAO {
> int updateOptimistically(Record record, Timestamp oldTimeStamp) {
> Example example = new Example();
> example.createCriteria()
> .andIdEquals(record.getId());
> .andTimestampEquals(oldTimeStamp)
>
> return updateByExample(record, example);
> // if 0 is returned, then rollback in your service layer
> }
> }
>
> I would be hesitent to try automatically generating optimistic locking
> code - because there are so many ways to do it. One way would be the "state
> comparison" method where we read the old record and do a field by field
> compare before doing an update. This is not optimal of course - better to
> use timestamps or version counts if they exist in the table, but ibator
> would not know about that.
>
> Another way to do it would be to designate a timestamp or version field in
> the ibator config - and then generate a method like I described above. But,
> honestly, it isn't much work to write it manually and I wonder if you would
> really want ibator to generate it given all the possible ways to do it?
>
> Anyway - let me know what you're thinking, and maybe we can hear from some
> others about this too.
>
> Regarding relationships - this is a big question and I've been having
> another side conversation about it too with Zoran. Zoran has some
> interesting ideas - we need to gather them in one place and have a public
> debate about it. I'll put a wiki page together in the next few days where
> we can have a public discussion about it. I have many concerns about doing
> this, but we should discuss openly.
>
> Jeff Butler
>
>
>
> On Tue, Apr 15, 2008 at 11:58 AM, Ashok Madhavan <[EMAIL PROTECTED]>
> wrote:
>
> > Hi Jeff,
> >
> > can we add the following new features :
> >
> > can we add optimistic locking support in ibator. this could be a
> > optional feature.
> > Table relationships would be awesome.
> >
> > regards
> > Ashok
> >
> >
> >
> >
> > On Tue, Apr 15, 2008 at 9:09 AM, Jeff Butler <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Thanks for the advice - I'll take it! I was already getting weary of
> > > typing iBATOR - ibator it is.
> > >
> > > Thanks for the freedom to do this - and the encouragement about
> > > ibator.
> > >
> > > Jeff Butler
> > >
> > > On Tue, Apr 15, 2008 at 8:21 AM, Clinton Begin <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > Sorry, I forgot to mention this sooner... It's a minor
> > > > recommendation for your own sanity.
> > > >
> > > > I suggest avoiding the reverse title case used by iBATIS... It's a
> > > > decision I wish I hadn't made. I would suggest simply using Ibator or
> > > > even
> > > > better: ibator. In hindsight, I wish I had used all lowercase:
> > > > ibatis.
> > > > It might also look better and be easier to read when written in its full
> > > > form: Apache iBATIS ibator.
> > > >
> > > > While unique, it presents a lot of challenges in typing, naming, and
> > > > general writing. Totally your call though.
> > > >
> > > > Other than that, I love the new name, despite the reason for the
> > > > change. :-)
> > > >
> > > > Congratulations again on building a kick ass product that is
> > > > gathering attention of all kinds.
> > > >
> > > > Cheers,
> > > > Clinton
> > > >
> > > >
> > > > On Tue, Apr 15, 2008 at 12:04 AM, Jeff Butler <[EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > Due to a trade registration dispute, we are renaming Apache iBATIS
> > > > > Abator to Apache iBATIS iBATOR.
> > > > >
> > > > > The new version is still under development - although the core
> > > > > work is almost complete. I have committed an initial version to SVN
> > > > > so you
> > > > > can take a look at what's going on. There will be no further
> > > > > enhancements
> > > > > or changes to Abator - all new work will be in the iBATOR code stream
> > > > > here:
> > > > > http://svn.apache.org/repos/asf/ibatis/trunk/java/tools/ibator/.
> > > > >
> > > > > I will be focusing on some changes to the Eclipse plugin for the
> > > > > new few weeks before doing a formal release. The new version will
> > > > > NOT be
> > > > > 100% compatible with Abator - but will be very close. Transition from
> > > > > Abator to iBATOR should be simple. I've listed some information
> > > > > about the
> > > > > development effort on the iBATOR homepage (
> > > > > http://ibatis.apache.org/ibator.html) if you want more
> > > > > information.
> > > > >
> > > > > This would be a good time to make suggestions for improvements to
> > > > > iBATOR as I am willing to make some breaking changes with the new
> > > > > version -
> > > > > so feel free to let me know if there are things you would like to see
> > > > > added
> > > > > or changed. BTW - I know there is some interest about seeing table
> > > > > relationships handled in iBATOR. This will not make it into the
> > > > > initial
> > > > > release. It's a big job, and I'm still not convinced of the
> > > > > usefulness of
> > > > > doing this.
> > > > >
> > > > > I hope to keep the disruption to a minimum, and I will include a
> > > > > migration guide once the new version is complete. Let me know if you
> > > > > have
> > > > > any good ideas for the future of iBATOR.
> > > > >
> > > > > Jeff Butler
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
