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 Rashmi Dave <ra...@persistent.co.in> on 2006/02/16 14:29:58 UTC
Found two bugs in Abator
Hi Jeff,
1. I specified the following mapping in Abator config
<table schema="ONE" tableName="ADDRESS">
<generatedKey column="ADDRESS_ID" sqlStatement="SELECT
EOBONE.ADDRESS_SEQ.NEXTVAL FROM DUAL"
identity="false"/>
</table>
Here, I provided the incorrect column name for the generated Key. Abator
threw an NPE for this.
2. I have a table with a large number of columns - 150. Now I used Abator to
generate the DAO classes. The DAOImpl class for this refused to compile
because the following function
private Map getExampleParms(RemitExample example)
threw an error "code too large"
I had to pull out switch statements create a number of other functions and
call these from here, only then did this error go. Can we generate this
function in another way so that it is made up of calls to smaller functions?
(I am using abator0.6.0.zip)
Thanks
~Rashmi
Re: Found two bugs in Abator
Posted by Jeff Butler <je...@gmail.com>.
Point taken. But I will make a change anyway - I've changed Abator so that
it generates shorter methods for each field in the table. So in Dave's
case, there will be 150 private methods - this will avoid the "too large"
error. The tradeoff is one giant method verses many smaller methods.
Look for a bug fix release (for both bugs Dave reported) later this
evening. I'd release it now, but I'm stuck behind a firewall for the next
few hours. The fixed code is in SVN now if anyone is in a super rush.
Jeff Butler
On 2/16/06, Mark Bennett <ma...@gmail.com> wrote:
>
> Not really exponentially. Its linear with a factor of 70 lines or so in
> the DAOImpl. Or by a factor of the 10 or so possible operations. I just
> didn't want people to get overly worried about it.
>
> Mark
>
>
> On 2/16/06, Jeff Butler <jeffgbutler@gmail.com > wrote:
> >
> > Thanks for reporting these. I'll take a look.
> >
> > The more I think about it, the more I dislike the way that I'm
> > generating the "by example" methods. As you've seen, it creates a tremendous
> > amount of code that grows exponentially as the fields in the table
> > increase. I'll definitiely have to think of a better way. Something else,
> > that doesn't apply in your case, is that the processor cycles required to do
> > a merge in Eclipse are enormous with these huge methods.
> >
> > Jeff Butler
> >
> >
> > On 2/16/06, Rashmi Dave <rashmid@persistent.co.in > wrote:
> > >
> > > Hi Jeff,
> > >
> > > 1. I specified the following mapping in Abator config
> > >
> > > <table schema="ONE" tableName="ADDRESS">
> > > <generatedKey column="ADDRESS_ID" sqlStatement="SELECT
> > > EOBONE.ADDRESS_SEQ.NEXTVAL FROM DUAL"
> > > identity="false"/>
> > > </table>
> > >
> > > Here, I provided the incorrect column name for the generated Key.
> > > Abator
> > > threw an NPE for this.
> > >
> > >
> > > 2. I have a table with a large number of columns - 150. Now I used
> > > Abator to
> > > generate the DAO classes. The DAOImpl class for this refused to
> > > compile
> > > because the following function
> > >
> > > private Map getExampleParms(RemitExample example)
> > >
> > > threw an error "code too large"
> > >
> > > I had to pull out switch statements create a number of other functions
> > > and
> > > call these from here, only then did this error go. Can we generate
> > > this
> > > function in another way so that it is made up of calls to smaller
> > > functions?
> > >
> > > (I am using abator0.6.0.zip)
> > >
> > > Thanks
> > > ~Rashmi
> > >
> > >
> >
>
Re: Found two bugs in Abator
Posted by Mark Bennett <ma...@gmail.com>.
Not really exponentially. Its linear with a factor of 70 lines or so in the
DAOImpl. Or by a factor of the 10 or so possible operations. I just didn't
want people to get overly worried about it.
Mark
On 2/16/06, Jeff Butler <je...@gmail.com> wrote:
>
> Thanks for reporting these. I'll take a look.
>
> The more I think about it, the more I dislike the way that I'm generating
> the "by example" methods. As you've seen, it creates a tremendous amount of
> code that grows exponentially as the fields in the table increase. I'll
> definitiely have to think of a better way. Something else, that doesn't
> apply in your case, is that the processor cycles required to do a merge in
> Eclipse are enormous with these huge methods.
>
> Jeff Butler
>
>
> On 2/16/06, Rashmi Dave <ra...@persistent.co.in> wrote:
> >
> > Hi Jeff,
> >
> > 1. I specified the following mapping in Abator config
> >
> > <table schema="ONE" tableName="ADDRESS">
> > <generatedKey column="ADDRESS_ID" sqlStatement="SELECT
> > EOBONE.ADDRESS_SEQ.NEXTVAL FROM DUAL"
> > identity="false"/>
> > </table>
> >
> > Here, I provided the incorrect column name for the generated Key. Abator
> >
> > threw an NPE for this.
> >
> >
> > 2. I have a table with a large number of columns - 150. Now I used
> > Abator to
> > generate the DAO classes. The DAOImpl class for this refused to compile
> > because the following function
> >
> > private Map getExampleParms(RemitExample example)
> >
> > threw an error "code too large"
> >
> > I had to pull out switch statements create a number of other functions
> > and
> > call these from here, only then did this error go. Can we generate this
> > function in another way so that it is made up of calls to smaller
> > functions?
> >
> > (I am using abator0.6.0.zip)
> >
> > Thanks
> > ~Rashmi
> >
> >
>
Re: Found two bugs in Abator
Posted by Jeff Butler <je...@gmail.com>.
Thanks for reporting these. I'll take a look.
The more I think about it, the more I dislike the way that I'm generating
the "by example" methods. As you've seen, it creates a tremendous amount of
code that grows exponentially as the fields in the table increase. I'll
definitiely have to think of a better way. Something else, that doesn't
apply in your case, is that the processor cycles required to do a merge in
Eclipse are enormous with these huge methods.
Jeff Butler
On 2/16/06, Rashmi Dave <ra...@persistent.co.in> wrote:
>
> Hi Jeff,
>
> 1. I specified the following mapping in Abator config
>
> <table schema="ONE" tableName="ADDRESS">
> <generatedKey column="ADDRESS_ID" sqlStatement="SELECT
> EOBONE.ADDRESS_SEQ.NEXTVAL FROM DUAL"
> identity="false"/>
> </table>
>
> Here, I provided the incorrect column name for the generated Key. Abator
> threw an NPE for this.
>
>
> 2. I have a table with a large number of columns - 150. Now I used Abator
> to
> generate the DAO classes. The DAOImpl class for this refused to compile
> because the following function
>
> private Map getExampleParms(RemitExample example)
>
> threw an error "code too large"
>
> I had to pull out switch statements create a number of other functions and
> call these from here, only then did this error go. Can we generate this
> function in another way so that it is made up of calls to smaller
> functions?
>
> (I am using abator0.6.0.zip)
>
> Thanks
> ~Rashmi
>
>