ibatis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Goodin" <brandon.goo...@gmail.com>
Subject Re: Abator..
Date Mon, 26 Jun 2006 15:19:10 GMT
Hey guys,

I have to say that I had a similar experience as Larry. I fired it up for a
recent project and then deleted it. It was too much code for me.

Issues I had:
- The size of the sqlmaps
 * "query by example" stuff is overwhelming... glad to hear it can be turned

- The number of domain objects per table.
* Blob Objects, Primary Key Objects, Example Object, Normal Domain Objects
* This comes too close to tying my domain to the database. Not something I
feel is a good idea.
* I have read Jeff's explanation for the Primary Key Object. I would
respectfully disagree with it. This seems to be something that would be
better addressed by providing constructor based initialization rather than a
whole other domain object. Again tying my domain semantic to my database.
* I've never had a need for more than one domain object to represent a
simple table.

In the end my feeling is that if we need code generation to be a regular
part of the process then it points to a deficiency in our framework. This is
a deficiency that I believe can be addressed largely without code gen. I
enjoy using code gen when I have a quarter ton of boiler plate code i always
have to write. This appears to be one of those cases. So, since code gen is
always a step ahead of addressing the real problem... I think it will remain
a need. However, I'd like to see it become a need that really has to be
considered rather than a no brainer.

Let's make code gen less compelling by fixing our framework. Then we can
work on providing a tool to our iBATIS users that is more about making their
use of the framework more productive rather than helping them generate a
metric ton of code to make up for our deficiency. :)

I think it would be cool to see Abator move in a direction where it can read
sqlmaps and provide the ability to pass in paramter objects during
development and view what sql is produced. Even go as far as interaction
with the database. These type of issues are what I think of when I think of
productivity tools.

Jeff, thanks for all your hard work and for filling a niche with the users.
Let's continue to refine Abator and iBATIS to the point that we have a tight
framework and an excellent toolset.


On 6/26/06, Jeff Butler <jeffgbutler@gmail.com> wrote:
> Another thing to look at - the new version in SVN.  With the fix to nested
> iterate tags, the generated XML for the by example methods gets down to
> about 15 lines total - down from the current 20-25 lines per column in a
> table.  But with the new version, the example class is still complex because
> it can do virtually any WHERE clause you can imagine.
> Also, there's much better documentation in SVN now too.  That should help.
> Jeff Butler
> On 6/26/06, Larry Meadors <lmeadors@apache.org> wrote:
> > OK, I tried abator this weekend to see what it was like - it seems to
> > be generating alot of traffic, which got me wondering what I was
> > missing.
> >
> > So, I downloaded and unzipped it (no eclipse for me, thanks), and
> > tweaked out a config file for a project I am working on and ran it on
> > a couple of tables.
> >
> > It ran OK, so I popped open the code to see what I had.
> >
> > I am not sure how to say this, and I do not mean to be discouraging,
> > but I was shocked to see so much code. Like not in a good way - 7,777
> > lines of code and xml in 10 files for 2 medium sized tables.
> > Extrapolating that out to a system with 50-60 tables put me in the
> > 200,000 - 250,000 line range.
> >
> > If I were an iBATIS beginner, it would have been so intimidating that
> > I'd have moved on to another tool like hibernate or db-commons without
> > a second look at iBATIS.
> >
> > With that in mind, I re-evaluated the mail that has been coming about
> > it, and got started thinking about it. Obviously, people are using it,
> > so it's not all bad, I just think we can find a better solution.
> >
> > While I think that Abator does address a problem with iBATIS (i.e.
> > creating simple sql by hand sucks), it is not a tool I'd recommend or
> > use in it's current state for a couple of reasons. First is the sheer
> > amount of code it creates - 200,000 lines for 50 tables is
> > unmanageable. Second is the amount of duplication in the generated
> > code - the dao implementation was 3,000 lines long, and nearly all
> > repetitive.
> >
> > Jeff, I hope you don't read this and take it personally or get
> > discouraged by it, I think you are fun guy to have on the team, and a
> > very practical problem-solver (both great traits in a developer). I
> > just brought this up, because I want everyone to look at it as it
> > grows, and make sure that it matures into something that fits with the
> > philosophy of iBATIS, and improves the framework.
> >
> > Larry
> >

View raw message