ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gareth Moorst <gazj...@yahoo.co.uk>
Subject Re: Abator wishlist
Date Mon, 26 Jun 2006 07:37:36 GMT
Hammer, nail, hit.

You're spot on there - that all sounds excellent.

I see your point about the primary key class - we don't have that problem, as we don't have
any primary keys.

I had some thoughts about being able to use the selectByExample methods to implement the selectByTeamId,
but I couldn't see past the fact that I didn't want the selectByExample methods visible -
it never occurred to me to make them private! Doh!

Thanks for taking the time to read my long and rambling email.

Need any help with any Abator work? You're doing a great job with it so far...

Cheers,
Gareth Moorst

----- Original Message ----
From: Jeff Butler <jeffgbutler@gmail.com>
To: user-java@ibatis.apache.org
Sent: Friday, 23 June, 2006 6:01:29 PM
Subject: Re: Abator wishlist

The primary key class is seperated so that the method signatures for selectByPrimaryKey and
deleteByPrimaryKey can only require the primary key, and not the class that represents the
entire row.  I did it that way because I have strong dislike of using half empty objects.
 For example, if the deleteByPrimaryKey method took the entire row as a parameter, everyone
would have to remember what fields are in the primary key and only set those fields - yuck.
 For the same reason, Abator will generate a seperate class that just contains any BLOB fields
that are in the table. 
  
 Here are some thought on the other suggestions:
  
 1. generate a selectAll method - easy.
  
 2. Override the naming convention for DAO methods - probably not too difficult, I'll look
into it further
  
 3. Pseudo primary keys - you can write your own selectByTeamId type of methods now using
the example class.  I write extra DAO methods like this all the time in my projects.  You
could write your own updateByTeamId method if I implement an updateByExample method (which
I hope to do).  I understand that you're not too excited about the example methods because
they might be hard to duplicate in other frameworks - but why would you ever want to use another
framework? :-)  However, if you just used the example classes internally to your DAO and added
the extra methods you wanted then you could do whatever you need to do.  I could add an option
to make the by example methods private in the DAO classes so that no programmer would be tempted
to use them directly.  Then you could just use them internally. 
  
 Thoughts???
 Jeff Butler
  
 
 
 On 6/23/06, erlend.bjorge@aftenposten.no <erlend.bjorge@aftenposten.no > wrote:   
 Hi there!
 
   
 >Gareth wrote: 
>Most of the hand written domain objects I have are completely flat POJOs - there is no
separate class for primary key - most of the time, there are no  >primary keys on the database
- so I'd like all of the Abator generated objects to be the same. Can we turn off generation
of primary key classes for those  >tables where primary keys are present and just use flat
objects?
  

  I have been using Ibatis for 2 years (and Hibernate for 1 year) now and I'm not sure why
you "want" to have separate primary key classes for your model beans ?  
 Not sure why that should be good for ? News for me, can anyone tell me why ?  J  
  
 Btw, not heard about Abator before, that sound interesting  J 
  
 Thanks,
 Erlend Bjørge
 













Mime
View raw message