You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Jeff Butler <je...@gmail.com> on 2008/04/15 06:04:53 UTC
[ANNOUNCE] Abator renamed to iBATOR
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
Re: [ANNOUNCE] Abator renamed to iBATOR
Posted by Zach Visagie <za...@ipay.co.za>.
On Wed, 2008-04-16 at 11:39 +1000, Zoran Avtarovski wrote:
> provide this we would have had 80% maybe 90% functionality done with
> ibator alone.
I agree. I have just worked on a web project where I made a clean
separation between the UI and the data access. I am using abator for the
tables and then manually getting the objects for the relationships.
This one is probably far fetched but I need to create one set of files
which can do the basic's for at least three different db's, postgres,
sybase and oracle. SelectKey and postgres is my problem here since
postgres does not have a select @@identity equivalent.
You can do the following:
select nextval( pg_get_serial_sequence( 'table_name','column_name' ) );
Could this be worked in as a postgres default?
ola
z
Re: [ANNOUNCE] Abator renamed to iBATOR
Posted by Zoran Avtarovski <zo...@sparecreative.com>.
Sorry Jeff,
I lost my mail server yesterday afternoon just found it this morning
hiding under the rug:)
With regards to foreign relationships I thought about what you said and I
think on the whole you¹re right. I don¹t want ibator (to avoid confusion,
I¹ll stick with this name for now on) to become some OR/Hibernate clone.
I spoke to some of my colleagues and what most impressed us about ibator was
that it was able to provide us a with 60% functionality out of the box, so
to speak. This enabled us to focus on the more complex 40% that was left.
So we asked ourselves, do we really want/need foreign table support and why?
It was a really positive discussion and what came about is that we felt the
byExample functionality is the key feature that enabled us to quickly get
our application out the door. What we¹re really looking for is a way to
extend that to handle basic foreign relationships. In our example we felt
that if ibator was able to provide this we would have had 80% maybe 90%
functionality done with ibator alone.
I guess what we¹re looking to do is have the ability to embed one example
object into another where a foreign relationship exists.
The complexity isn¹t in the SQL maps they¹re going to be reasonably straight
forward, it¹s going to be in extending the example objects in a sensible
way. For example lets look at the user/address relationship. They way I
imagine it working is to have two example objects UserExample and
AddressExample and creating a method in say addForeignCriteria which copies
across the criteria from the foreign example object to the main this part
may be easier than I thought????
I did a little more fleshing yesterday before I had to start rebuilding the
mail server here¹s how far I got:
Restrictions (anything beyond what¹s below should be handled on an as needs
basis, not automated)
1. join based sql statements only I¹m not a fan of sub queries
2. one level only
3. only one 1:many relationship per table
4. insert and update functionality only on 1:1 relationships and where the
foreign object is a primitive wrapper
A quick and Dirty summary of functionality needed.
1. Creation of new xml child tag (something like foreignRelation)
2. creation of code to generate necessary xml code for sqmlMaps
3. expanding the example objects to facilitate foreign relationships
4. adding necessary DAO functionality for updates and inserts it doesn¹t
make sense to implement this in SQL
While the idea of doing this as an academic exercise sounds exciting, I¹d
really only start down this road if there was genuine interest in it. At
this stage I¹m looking for feedback.
If there¹s interest there, I¹ll whack together a project plan on the weekend
and post it to the wiki.
Z.
Re: [ANNOUNCE] Abator renamed to iBATOR
Posted by Ashok Madhavan <as...@gmail.com>.
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 <je...@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();
> 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 <as...@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.
> >
> > regards
> > Ashok
> >
> >
> >
> >
> > On Tue, Apr 15, 2008 at 9:09 AM, Jeff Butler <je...@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.
> > > >
> > > > Cheers,
> > > > Clinton
> > > >
> > > >
> > > > On Tue, Apr 15, 2008 at 12:04 AM, Jeff Butler <je...@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
> > > > >
> > > > >
> > > >
> > > >
> > >
> >
>
Re: [ANNOUNCE] Abator renamed to iBATOR
Posted by Jeff Butler <je...@gmail.com>.
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 <as...@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.
>
> regards
> Ashok
>
>
>
>
> On Tue, Apr 15, 2008 at 9:09 AM, Jeff Butler <je...@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 <cl...@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.
> > >
> > > Cheers,
> > > Clinton
> > >
> > >
> > > On Tue, Apr 15, 2008 at 12:04 AM, Jeff Butler <je...@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
> > > >
> > > >
> > >
> > >
> >
>
Re: [ANNOUNCE] Abator renamed to iBATOR
Posted by Ashok Madhavan <as...@gmail.com>.
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 <je...@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 <cl...@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.
> >
> > Cheers,
> > Clinton
> >
> >
> > On Tue, Apr 15, 2008 at 12:04 AM, Jeff Butler <je...@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
> > >
> > >
> >
> >
>
Re: [ANNOUNCE] Abator renamed to iBATOR
Posted by Jeff Butler <je...@gmail.com>.
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 <cl...@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.
>
> Cheers,
> Clinton
>
>
> On Tue, Apr 15, 2008 at 12:04 AM, Jeff Butler <je...@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
> >
> >
>
>
Re: [ANNOUNCE] Abator renamed to iBATOR
Posted by Jeff Butler <je...@gmail.com>.
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 <cl...@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.
>
> Cheers,
> Clinton
>
>
> On Tue, Apr 15, 2008 at 12:04 AM, Jeff Butler <je...@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
> >
> >
>
>
Re: [ANNOUNCE] Abator renamed to iBATOR
Posted by Clinton Begin <cl...@gmail.com>.
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 <je...@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
>
>
Re: [ANNOUNCE] Abator renamed to iBATOR
Posted by Clinton Begin <cl...@gmail.com>.
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 <je...@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
>
>
ibatis and spring
Posted by Henry Lu <zh...@umich.edu>.
in bean configuration file:
<bean id="sqlMapClient"
class="org.springframework.orm.ibatis.SqlMapClientFactoryBean">
<property name="configLocation">
<value>sql-map-config.xml</value>
</property>
</bean>
Is there a way not use sql-map-config.xml file but sql-map.xml file like
the following directly?
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sqlMap
PUBLIC "-//ibatis.apache.org//DTD SQL Map 2.0//EN"
"http://ibatis.apache.org/dtd/sql-map-2.dtd">
<sqlMap namespace="Misc">
...
</sqlMap>
-Henry