Abator..

[Larry Meadors <lm...@apache.org>]

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

Re: Abator..

[Jeff Butler <je...@gmail.com>]

Hi Larry,

No offense taken - I'm glad someone else is finally looking at it!

The massive amounts of code come from the "by example" methods.  If you turn
them off, it will eliminate the vast majority of the code and the generated
code will be very simple.

I've been working on new ways to make these methods shorter, but given that
people want all kinds of flexability with them (like specifying type
handlers), it's difficult to do.

Maybe I should make the "by example" methods not generate by default, then
it wouldn't be so intimidating.

With flexability comes complexity - no way around it.

Jeff



On 6/26/06, Larry Meadors <lm...@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
>

Re: Abator..

[Larry Meadors <lm...@apache.org>]

On 6/26/06, Jeff Butler <je...@gmail.com> wrote:
> 4. Abator generates code that matches database tables, rather than a rich
> domain model.

I agree with your philosophy 100% on this.

> 5. Useful code gen implies that something is wrong with iBATIS.
>
> ...

I think that we could provide some cached runtime codegen to offset
this. What I mean by that is that using dbmetadata, we could generate
simple CRUD stuff pretty easily at runtime, and simplify the creation
of beans as a developer task.

Larry

Re: Abator..

[Brandon Goodin <br...@gmail.com>]

"but turn it off if you don't like it"

Fair enough. This seems to fit with the iBATIS philosophy. Querying by
example is a complex task. Hopefully one that we can solve better in the
future. But, for now... so be it.


"Because this is style related, it's hard to know what to do."

This is the very point where i feel like this tool may be trying to reach
too far. We don't want a gen tool that is going to do everything that
everyone wants to do. We want a tool that is going to generate things that
are common to acceptable iBATIS practices. If people want to write tools
that reach outside of that then I don't think it should be a core iBATIS
tool.


"See this for my thoughts on that subject" and ""Abator generates code that
matches database tables, rather than a rich domain model.""

I have read your philosophy in the past and i I hear your point. But, again,
I would prefer to avoid supporting various styles of iBATIS useage and
promote a base acceptable practice. To me we should not be generating Key
classes and Blob classes. I am not aware of any of the original developers
who ever considered key clases as a regular part of their development. I'm
happy to be wrong.


"Maybe - but what's the alternative?" and "It's a nice thought to think that
there could be some future version of iBATIS that wouldn't benefit from code
gen"

You are exaggerating my position a bit. Please read carefully what i am
saying. I am saying our goal should be a better iBATIS that doesn't require
"as much" code gen :) I am not saying that we will eliminate the use of code
gen with iBATIS (although that wouldn't be a bad idea). I'm simply saying
that we can make it less. I do not believe this to be a pie in the sky idea.
But, rather it is a goal that we should strive to meet. If we have the time
and energy to solve it with code gen. Then we have the time and energy to
solve it in the core iBATIS where possible.


"This is not the purpose of Abator - but it sounds like a great idea for
another tool.  You should get right on that - but not until after you finish
multiple result set support :)"

Actually, Clinton is working on the multi resultset support now. I need to
reassign it to him :). In regards to other tools... I would prefer to
improve core iBATIS first. The tools are productivity enhancements :) Did i
sense you taking a  jab at me? :)


"But I think the bulk of the objections come from the "by example" methods,
which are entirely optional."

I would say i have objections related to where Abator currently is as well
as where i sense it is headed.  There are a few things i would prefer to see
altered in the current version . For example, the domain model and setting
the default "query by example" generation to off.


"code are asking for more function - which implies more complexity" and "We
could add some options to generate different styles of domain objects if we
could come up with a reasonably small set of permutations."

As a point of historical perspective, we have often pushed back on feature
requests because it would create complexity for the majority while adding
benefit for a small minority. It seems that we need to make sure that Abator
is supporting core iBATIS philosophies FIRST. Secondly would be to build in
extensibility so that developers can mold to their liking. This helps to
guard against feature overload while allowing folks to mold it to their
liking.

RowHandlers are a good example of this.


In summary, I think code gen will be a part of our life. But, it should be a
part of our life that core iBATIS enhancements are either eliminating or
reducing. So, that being said, I fully support Abator as long as it hold
true to the 80/20 iBATIS philosophy and doesnt attempt to be an uber tool
that will generate whatever flavor of iBATIS useage you want it to.

Brandon

On 6/26/06, Jeff Butler <je...@gmail.com> wrote:
>
> If I can summarize the objections, here's what I see:
>
> 1. Too much code - too many notes :)
>
> The "metric ton" of code comes ONLY from the "by example" methods.  IMHO
> this adds a lot of flexability with the side effect of some complexity - but
> turn it off if you don't like it.  If you turn these methods off you'll only
> see "normal" iBATIS code: very small, very tight.
>
>
> 2. No one, me included, likes the style "by example" methods.
>
> I HATE the current style of these methods too - but iBATIS bugs forced me
> to use that style.  I, with the great help of Christian Poitras, had to fix
> a longstanding bug in iBATIS to make them better (nested iterates).  Once we
> release iBATIS 2.2.0, then I can release a new version of Abator and the
> style of these methods will be MUCH better (the code is already in SVN for
> the new style).  With the next version of Abator all the complexity of the
> "by example" functionality will be encapsulated in one class (the example
> class), and removed from the generated SQL map and DAO class.  The new
> example class has become a pretty complex class, but at least the complexity
> is well encapsulated.  The new style of SQL map and DAO objects are much
> simpler - more like "normal" iBATIS objects.  But if you still can't stand
> it, then you can always turn it off.
>
> I added the "by example" functionality because, in my real life projects,
> it becomes an incredibly useful and reusable set of function.  I end up
> using the "by example" function a lot.
>
> Lastly I'll mention that, to the best of my recollection, there's never
> been a complaint on the user's list about the complexity of the "by example"
> generated code.  Most questions on the "by example" code are asking for more
> function - which implies more complexity.
>
>
> 3. There are style differences related to generated domain classes.
>
> Some like a flat model, some don't.  Some like constructors
> with parameters, some don't.  Because this is style related, it's hard to
> know what to do.  We could add some options to generate different styles of
> domain objects if we could come up with a reasonably small set of
> permutations.
>
>
> 4. Abator generates code that matches database tables, rather than a rich
> domain model.
>
> See this for my thoughts on that subject:
>
> http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/tools/abator/core/htmldoc/philosophy.html
>
> <http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/tools/abator/core/htmldoc/philosophy.html+>
>
>
> 5. Useful code gen implies that something is wrong with iBATIS.
>
> Maybe - but what's the alternative?  EJB 3.0?  As long as our philosphy is
> that humans write better SQL than ORM tools (that is our philisophy, isn't
> it?), I don't see much changing in that area.
>
> Of course, iBATIS doesn't require a code gen - but code gen can make
> things easier (see the definition of the word "Abator" - it abates a
> nuisance).  It's a nice thought to think that there could be some future
> version of iBATIS that wouldn't benefit from code gen, but that's a long way
> off given our current pace of development.
>
>
> 6. Abator should do something different than what it does (like debugging
> sql maps at development time).
>
> This is not the purpose of Abator - but it sounds like a great idea for
> another tool.  You should get right on that - but not until after you finish
> multiple result set support :)
>
>
> Please know that I REALLY appreciate the feedback.  I never meant to be a
> lone ranger on this, so I appreciate all ideas.  But I think the bulk of the
> objections come from the "by example" methods, which are entirely optional.
> If you guys have other ideas for improving the tool then I'd love to work
> together on them!
>
> BTW - I've spent a lot of time recently refining the documentation for
> Abator.  I'd really appreciate any feedback on what could be made clearer.
> Just remember that this set of documentation references features that are
> not generally available yet (except in SVN).  Here's a link:
>
> http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/tools/abator/core/htmldoc/index.html
>
>
>
>
> Jeff Butler
>
>
>
>
> On 6/26/06, Brandon Goodin <brandon.goodin@gmail.com > wrote:
> >
> > 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 off
> >
> > - 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.
> >
> >
> > Brandon
> >
> >
> > 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
> > > >
> > >
> > >
> > >
> >
> >
>

Re: Abator..

[Jeff Butler <je...@gmail.com>]

If I can summarize the objections, here's what I see:

1. Too much code - too many notes :)

The "metric ton" of code comes ONLY from the "by example" methods.  IMHO
this adds a lot of flexability with the side effect of some complexity - but
turn it off if you don't like it.  If you turn these methods off you'll only
see "normal" iBATIS code: very small, very tight.


2. No one, me included, likes the style "by example" methods.

I HATE the current style of these methods too - but iBATIS bugs forced me to
use that style.  I, with the great help of Christian Poitras, had to fix a
longstanding bug in iBATIS to make them better (nested iterates).  Once we
release iBATIS 2.2.0, then I can release a new version of Abator and the
style of these methods will be MUCH better (the code is already in SVN for
the new style).  With the next version of Abator all the complexity of the
"by example" functionality will be encapsulated in one class (the example
class), and removed from the generated SQL map and DAO class.  The new
example class has become a pretty complex class, but at least the complexity
is well encapsulated.  The new style of SQL map and DAO objects are much
simpler - more like "normal" iBATIS objects.  But if you still can't stand
it, then you can always turn it off.

I added the "by example" functionality because, in my real life projects, it
becomes an incredibly useful and reusable set of function.  I end up using
the "by example" function a lot.

Lastly I'll mention that, to the best of my recollection, there's never been
a complaint on the user's list about the complexity of the "by example"
generated code.  Most questions on the "by example" code are asking for more
function - which implies more complexity.


3. There are style differences related to generated domain classes.

Some like a flat model, some don't.  Some like constructors with parameters,
some don't.  Because this is style related, it's hard to know what to
do.  We could add some options to generate different styles of domain
objects if we could come up with a reasonably small set of permutations.


4. Abator generates code that matches database tables, rather than a rich
domain model.

See this for my thoughts on that subject:

http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/tools/abator/core/htmldoc/philosophy.html
<http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/tools/abator/core/htmldoc/philosophy.html+>


5. Useful code gen implies that something is wrong with iBATIS.

Maybe - but what's the alternative?  EJB 3.0?  As long as our philosphy is
that humans write better SQL than ORM tools (that is our philisophy, isn't
it?), I don't see much changing in that area.

Of course, iBATIS doesn't require a code gen - but code gen can make things
easier (see the definition of the word "Abator" - it abates a nuisance).
It's a nice thought to think that there could be some future version of
iBATIS that wouldn't benefit from code gen, but that's a long way off given
our current pace of development.


6. Abator should do something different than what it does (like debugging
sql maps at development time).

This is not the purpose of Abator - but it sounds like a great idea for
another tool.  You should get right on that - but not until after you finish
multiple result set support :)


Please know that I REALLY appreciate the feedback.  I never meant to be a
lone ranger on this, so I appreciate all ideas.  But I think the bulk of the
objections come from the "by example" methods, which are entirely optional.
If you guys have other ideas for improving the tool then I'd love to work
together on them!

BTW - I've spent a lot of time recently refining the documentation for
Abator.  I'd really appreciate any feedback on what could be made clearer.
Just remember that this set of documentation references features that are
not generally available yet (except in SVN).  Here's a link:

http://svn.apache.org/repos/asf/ibatis/trunk/java/mapper/mapper2/tools/abator/core/htmldoc/index.html




Jeff Butler




On 6/26/06, Brandon Goodin <brandon.goodin@gmail.com > wrote:
>
> 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 off
>
> - 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.
>
>
> Brandon
>
>
> 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
> > >
> >
> >
> >
>
>

Re: Abator..

[Brandon Goodin <br...@gmail.com>]

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
off

- 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.

Brandon

On 6/26/06, Jeff Butler <je...@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 <lm...@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
> >
>
>

Re: Abator..

[Jeff Butler <je...@gmail.com>]

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 <lm...@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
>