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.

On Tue, Apr 15, 2008 at 11:22 AM, Jeff Butler <jeffgbutler@gmail.com> 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();
    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 <ashok.madhavan@gmail.com> 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.


On Tue, Apr 15, 2008 at 9:09 AM, Jeff Butler <jeffgbutler@gmail.com> 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 <clinton.begin@gmail.com> 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.


On Tue, Apr 15, 2008 at 12:04 AM, Jeff Butler <jeffgbutler@gmail.com> 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