Very well stated Jeff, and I like your suggested
implementation.
To add more to the argument of having separate PrimaryKey classes, my
last project we I was using EJB's for persistence and started by using the
simple Java wrapper classes around the primitives, such as Integer for int and
of course String. Seemed like the correct thing to do, after all why would you
write a wrapper around these classes? That question I answered rather quickly
when several months into the project we needed to change the datatypes of the
primary key field on several of the tables from String to Integer. Because I
used these classes as the PrimaryKey of the object I needed to touch all of the
code that made reference to the PrimaryKey field of the entity objects. What a
painful experience. While I had WSAD to facilitate these changes, it was still
painful and did nothing to help the changes that needed to be made to all of the
JSP's. Had we a PrimaryKey class in the first place the impact would have been
greatly reduced and almost negligible. I learned my lesson and now
always create a PrimaryKey class for every Domain object. And as you stated
below, it provides a much cleaner interface to the selectByPrimaryKey and
deleteByPrimaryKey methods.
Thanks for all the hard work Jeff. It's greatly
appreciated.
From: "Jeff Butler" <[EMAIL PROTECTED]> [mailto:"Jeff Butler" <[EMAIL PROTECTED]>]
Sent: Friday, June 23, 2006 10:01 AM
To: user-java@ibatis.apache.org
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
