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
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 <[EMAIL PROTECTED]>
To: user-java@ibatis.apache.org
Sent: Friday, 23 June, 2006 6:01:29 PM
Subject: Re: Abator wishlist
From: Jeff Butler <[EMAIL PROTECTED]>
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, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> 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
