ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Grabowski <rongrabow...@yahoo.com>
Subject RE: calling trim() on sql map returned strings
Date Wed, 26 Oct 2005 16:23:07 GMT
Custom type handler support has been around for a while. One draw back
is that you can't say "use this type handler for all strings". You have
to specify the special type handler per each item in your
parameterMap/resultMap. A lot of people don't use parameter maps. Its a
pain to have to specify a type handler for each and ever String in your
sql map files. Being able to set the type handlers globally cuts down
on the amount of extra clutter in your sql map files.

--- Gareth Moorst <Gareth.Moorst@Phones4u.co.uk> wrote:

> That's interesting... I'll have a look at that tomorrow- The
> sqlmapconfig dtd does have a typehandler child..
> 
> Cheers
> 
> -----Original Message-----
> From: Ron Grabowski [mailto:rongrabowski@yahoo.com]
> Sent: 26 October 2005 17:13
> To: user-java@ibatis.apache.org
> Subject: RE: calling trim() on sql map returned strings
> 
> 
> IBatisNet has support for replacing the built-in type handlers:
> 
>  <typeHandlers>
>   <typeHandler type="String" callback="TrimStringTypeHandlerCallback"
> />
>  </typeHandlers>
> 
> TrimStringTypeHandlerCallback could be implemented in such a way that
> it automatically calls trim() before sending values to the database.
> You could continue to use the normal #property# syntax without having
> to specify the type handler using parameter maps and/or inline
> parameter settings.
> 
> Here's a list of some other useful default type handler replacements
> I
> thought of:
> 
> 
> http://www.mail-archive.com/user-cs%40ibatis.apache.org/msg00392.html
> 
> I don't believe the Java version has this functionality.
> 
> --- Gareth Moorst <Gareth.Moorst@Phones4u.co.uk> wrote:
> 
> > Before acting on this e-mail or opening any attachments you are
> > advised to read 
> > The Caudwell Holdings group of companies' disclaimer at the end of
> > this e-mail.
> > =======================================================
> > 
> > So it does... I hadnn't spotted that.
> >  
> > One downside of doing it that way is that I can't use select *
> > anymore, but suppose I'll have to live with that.
> > 
> > Ta.
> > 
> > -----Original Message-----
> > From: Daniel Henrique Ferreira e Silva [mailto:dhsilva@gmail.com]
> > Sent: 26 October 2005 13:34
> > To: user-java@ibatis.apache.org
> > Subject: Re: calling trim() on sql map returned strings
> > 
> > 
> > Hi Gareth,
> > 
> > Doesn't Informix have a trim-like function you could apply in your
> > query?
> > 
> > Like:
> > 
> > select trim(mycolumn) as mycolumn from mytable
> > 
> > Doing that kind of stuff in the database is the best pick IMHO.
> > 
> > Cheers,
> > Daniel Silva.
> > 
> > On 10/26/05, Gareth Moorst <Gareth.Moorst@phones4u.co.uk> wrote:
> > > 
> > > It would appear that I didn't make myself at all clear in that
> last
> > email - it must still be too early in the day for rational
> thought...
> > >
> > > what I want to do is call trim() on all the strings I return from
> > the db.
> > >
> > > -----Original Message-----
> > > From: Gareth Moorst
> > > Sent: 26 October 2005 10:01
> > > To: user-java@ibatis.apache.org
> > > Subject: calling trim() on sql map returned strings
> > > Hi
> > >
> > > All my iBatis created objects have large amounts of spaces in
> their
> > string properties, because that is what my informix db returns - I
> > was just wondering if I need to make a custom type handler to do
> this
> > for me, or is there an easier way?
> > >
> > > Cheers
> 
> =======================================================
> Confidentiality Notice
> This e-mail is confidential and intended for the use of the named
> recipient only.  If you are not the intended recipient please notify
> us by telephone immediately on +44(0)1782 600600 or return it to us
> by e-mail.  Please then delete it from your system and note that any
> use, dissemination, forwarding, printing or copying is strictly
> prohibited. Any views or opinions are solely those of the author and
> do not necessarily represent those of The Caudwell Holdings group of
> companies.
> 
> Encryptions and Viruses
> Please note that this e-mail and any attachments have not been
> encrypted.  They may therefore be liable to be compromised.  Please
> also note that it is your responsibility to scan this e-mail and any
> attachments for viruses.  We do not, to the extent permitted by law,
> accept any liability (whether in contract, negligence or otherwise)
> for any virus infection and/or external compromise of security and/or
> confidentiality in relation to transmissions sent by e-mail.
> 
> Monitoring 
> Activity and use of The Caudwell Holdings group of companies' systems
> is monitored to secure its effective use and operation and for other
> lawful business purposes.  Communications using these systems will
> also be monitored and may be recorded to secure effective use and
> operation and for other lawful business purposes.
> 
> 


Mime
View raw message