Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 21999 invoked from network); 15 Feb 2007 22:25:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Feb 2007 22:25:41 -0000 Received: (qmail 16014 invoked by uid 500); 15 Feb 2007 22:25:46 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 16002 invoked by uid 500); 15 Feb 2007 22:25:46 -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 15991 invoked by uid 99); 15 Feb 2007 22:25:46 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Feb 2007 14:25:46 -0800 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of jeffgbutler@gmail.com designates 64.233.184.232 as permitted sender) Received: from [64.233.184.232] (HELO wr-out-0506.google.com) (64.233.184.232) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 15 Feb 2007 14:25:36 -0800 Received: by wr-out-0506.google.com with SMTP id 36so926647wra for ; Thu, 15 Feb 2007 14:25:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=hX/pf+9/hKOIUWjDg5gTjkqzPi5maGfoA+ijy3YwoCXCfQi4Mvrr4TzH9JR+nqjF8dUMtB6iPSOcBTx7q6/8foXobigwtdPTXgH6L7xLvrvRQr6kuLNACJQLkZCdFMa3HjRuxMAxobYN858JEJXrYBrwsBpwJfbBHC9ZQwi8SuU= Received: by 10.114.210.2 with SMTP id i2mr1526191wag.1171578314495; Thu, 15 Feb 2007 14:25:14 -0800 (PST) Received: by 10.115.111.7 with HTTP; Thu, 15 Feb 2007 14:25:14 -0800 (PST) Message-ID: Date: Thu, 15 Feb 2007 16:25:14 -0600 From: "Jeff Butler" To: user-java@ibatis.apache.org Subject: Re: silly question regarding cast from char to int In-Reply-To: <94c6c2b70702151411s4ad497bbs65cbd3862d75fcd7@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_122133_16034515.1171578314170" References: <94c6c2b70702151411s4ad497bbs65cbd3862d75fcd7@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org ------=_Part_122133_16034515.1171578314170 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline The easiest resolution is to store numbers in number fields in the database! But I understand if you can't change the database. It's really best to change the DAOs. As an alternative, you could change the SQL with some database specific code. For example, in DB2 you could do this: select * from some_table where integer(database_id) = #java_id# However be warned that this is a very poor performer and will cause table scans. So it's best to change it in the DAO. Jeff Butler On 2/15/07, Andy Thompson wrote: > > in my database - i've got a value that's of type char. for example > "0000009". the dao is passing back a request by id where id is 9. So > there's no match. > > so select * from some_column where database_id = #java_id# returns null. > but select * from some_column where database_id="0000009" returns true. > > I'd prefer to not have to modify the dao making the request to add 0s to > it cause that seems dumb and I can't change the database. > what's the easiest resolution here? > > -- > Andrew R. Thompson > Currently in D.C. Consulting ------=_Part_122133_16034515.1171578314170 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
The easiest resolution is to store numbers in number fields in the database!  But I understand if you can't change the database.
 
It's really best to change the DAOs.  As an alternative, you could change the SQL with some database specific code.  For example, in DB2 you could do this:
 
select *
from some_table
where integer(database_id) = #java_id#
 
However be warned that this is a very poor performer and will cause table scans.  So it's best to change it in the DAO.
 
Jeff Butler
 
 
 
 


 
On 2/15/07, Andy Thompson <arthomps@gmail.com> wrote:
in my database - i've got a value that's of type char.  for example "0000009".  the dao is passing back a request by id where id is 9.  So there's no match.

so select * from some_column where database_id = #java_id# returns null.  but select * from some_column where database_id="0000009" returns true.
 
I'd prefer to not have to modify the dao making the request to add 0s to it cause that seems dumb and I can't change the database. 
what's the easiest resolution here?

--
Andrew R. Thompson
Currently in D.C. Consulting

------=_Part_122133_16034515.1171578314170--