Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 93417 invoked from network); 26 Jun 2006 07:38:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 26 Jun 2006 07:38:02 -0000 Received: (qmail 64994 invoked by uid 500); 26 Jun 2006 07:38:01 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 64458 invoked by uid 500); 26 Jun 2006 07:38:00 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 64447 invoked by uid 99); 26 Jun 2006 07:38:00 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 26 Jun 2006 00:38:00 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy includes SPF record at spf.trusted-forwarder.org) Received: from [217.146.176.246] (HELO web25813.mail.ukl.yahoo.com) (217.146.176.246) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 26 Jun 2006 00:37:58 -0700 Received: (qmail 25039 invoked by uid 60001); 26 Jun 2006 07:37:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=uuaewvKnPgZkEJOsoowi4AyixX9Qp8+s7g5AnplIhqU3KDcPgVPNvWh8acPiHvXHhgNN//otzgnB6u6HCudnFwjvSzhBl+8Zx+AiTCNj06/cRq10qOCwkefk0GNx8khVyJdUFcTHbEHZ9O5oU7yvmYMjUGni9CJQsNosrJJQ4B4= ; Message-ID: <20060626073736.25037.qmail@web25813.mail.ukl.yahoo.com> Received: from [82.109.70.230] by web25813.mail.ukl.yahoo.com via HTTP; Mon, 26 Jun 2006 07:37:36 GMT Date: Mon, 26 Jun 2006 07:37:36 +0000 (GMT) From: Gareth Moorst Reply-To: Gareth Moorst Subject: Re: Abator wishlist To: user-java@ibatis.apache.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2137134003-1151307456=:24403" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --0-2137134003-1151307456=:24403 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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 mak= e 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 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 select= ByPrimaryKey and deleteByPrimaryKey can only require the primary key, and n= ot the class that represents the entire row. I did it that way because I h= ave strong dislike of using half empty objects. For example, if the delete= ByPrimaryKey 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 jus= t contains any BLOB fields that are in the table.=20 =20 Here are some thought on the other suggestions: =20 1. generate a selectAll method - easy. =20 2. Override the naming convention for DAO methods - probably not too diffi= cult, I'll look into it further =20 3. Pseudo primary keys - you can write your own selectByTeamId type of met= hods 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 inte= rnally 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 met= hods private in the DAO classes so that no programmer would be tempted to u= se them directly. Then you could just use them internally.=20 =20 Thoughts??? Jeff Butler =20 =20 =20 On 6/23/06, erlend.bjorge@aftenposten.no w= rote: Hi there! =20 =20 >Gareth wrote:=20 >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 n= o >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 f= or those >tables where primary keys are present and just use flat objects? =20 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 mo= del beans ? =20 Not sure why that should be good for ? News for me, can anyone tell me why= ? J =20 =20 Btw, not heard about Abator before, that sound interesting J=20 =20 Thanks, Erlend Bj=F8rge =20 --0-2137134003-1151307456=:24403 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
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 ha= d some thoughts about being able to use the selectByExample methods to impl= ement the selectByTeamId, but I couldn't see past the fact that I didn't wa= nt the selectByExample methods visible - it never occurred to me to make th= em private! Doh!

Thanks for taking the time to read my long and ramb= ling 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@i= batis.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 re= quire the primary key, and not the class that represents the entire row.&nb= sp; I did it that way because I have strong dislike of using half empt= y objects.  For example, if the deleteByPrimaryKey method took th= e entire row as a parameter, everyone would have to remember what fields ar= e in the primary key and only set those fields - yuck.  For the same r= eason, Abator will generate a seperate class that just contains any BLOB fi= elds that are in the table.=0A
=0A
 
=0A
Here are so= me thought on the other suggestions:
=0A
 
=0A
1. ge= nerate a selectAll method - easy.
=0A
 
=0A
2. = Override the naming convention for DAO methods - probably not too difficult= , I'll look into it further
=0A
 
=0A
3. Pseudo= primary keys - you can write your own selectByTeamId type of methods now u= sing the example class.  I write extra DAO methods like this all the t= ime in my projects.  You could write your own updateByTeamId method if= I implement an updateByExample method (which I hope to do).  I unders= tand that you're not too excited about the example methods because they mig= ht be hard to duplicate in other frameworks - but why would you ever want t= o use another framework? :-)  However, if you just used the example cl= asses internally to your DAO and added the extra methods you wanted then yo= u 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 interna= lly.=0A
=0A
 
=0A
Thoughts???
=0A
Jeff Butl= er
=0A
 
=0A

 
=0A
On 6/23/06, erlend.bjorge@aftenposten.no <erle= nd.bjorge@aftenposten.no=0A> wrote:=0A
=0A
=0A
=0A
= =0A

Hi there!

=0A<= div>
=0A
=0A

 

=0A

>Gareth wrote:= =0A
>Most of the hand writt= en domain objects I have are completely flat POJOs - there is no separate c= lass for primary key - most of the time, there are no = =0A>primary keys on the datab= ase - so I'd like all of the Abator generated objects to be the same. Can w= e turn off generation of primary key classes for those =0A>tables where primary key= s are present and just use flat objects?

=0A

 

=0A=0A

I have been usi= ng Ibatis for 2 years (and Hibernate for 1 year) now and I'm not sure why y= ou "want" to have separate primary key classes for your model beans ? =0A

=0A

= Not sure why that should be good for ? News for me, can anyone tell me why = ? =0AJ <= /span>=0A

=0A

 

=0A

Btw, not heard about Abator before, that sound interesting =0A= J=0A

=0A

=  

=0A

Thanks,

=0A

Erlend Bj=F8rge

=0A






--0-2137134003-1151307456=:24403--