This syntax:
#propertyName,type=string,dbype=Varchar,direction=Input,nullValue=N/A,handler=string#
is good if you need to process a few properties differently. If you
need to do custom processing on _every_ string sent to the database you
have to use that syntax wherever there is a string in your sql map
files:
<update id="Update" parameterClass="User">
UPDATE [User] SET
[Login] = #Login,handler=UpperCaseStringTypeHandler#,
[Password] = #Password,handler=UpperCaseStringTypeHandler#,
[PasswordHint] = #PasswordHint,handler=UpperCaseStringTypeHandler#,
[FirstName] = #FirstName,handler=UpperCaseStringTypeHandler#,
[MiddleName] = #MiddleName,handler=UpperCaseStringTypeHanlder#,
[LastName] = #LastName,handler=UpperCaseStringTypeHanlder#,
[EmailAddress] = #EmailAddress,handler=UpperCaseStringTypeHandler#,
[DateLastUpdated ]= ${NOW}
WHERE
[UserId] = #UserId#
</update>
I would have to update _every_ property in _every_ sql map file. That's
a lot of unncessary typing. In my current project I would have to
update ~130 lines of code. A cleaner solution would be to allow the
user to add a line to the sqlMap.config file.
Imagine if something changed and now all the strings sent to the
database needed to be in lower case. You would have to do a
find/replace and change ~130 lines of code to use this:
<update id="Update" parameterClass="User">
UPDATE [User] SET
[Login] = #Login,handler=LowerCaseStringTypeHandler#,
[Password] = #Password,handler=LowerCaseStringTypeHandler#,
[PasswordHint] = #PasswordHint,handler=LowerCaseStringTypeHandler#,
[FirstName] = #FirstName,handler=LowerCaseStringTypeHandler#,
[MiddleName] = #MiddleName,handler=LowerCaseStringTypeHandler#,
[LastName] = #LastName,handler=LowerCaseStringTypeHandler#,
[EmailAddress] = #EmailAddress,handler=LowerCaseStringTypeHandler#,
[DateLastUpdated ]= ${NOW}
WHERE
[UserId] = #UserId#
</update>
If there was support for overriding the default type handler you would
have had to change just one line in the sqlMap.config file:
<typeHandlers>
<typeHandler
type="System.String"
handler="UpperCaseStringTypeHanlder" />
</typeHandlers>
--- Gilles Bayon <[EMAIL PROTECTED]> wrote:
> For inline parameter you can specify null value and handler
>
>
#propertyName,type=string,dbype=Varchar,direction=Input,nullValue=N/A,handler=string#
> On 10/4/05, Ron Grabowski <[EMAIL PROTECTED]> wrote:
> >
> > I think the "01/01/0001 00:00:00" is ugly. Who has the value of
> > double.MinValue memorized?
> >
> > I don't use parameterMaps. I use the standard #Property# syntax:
> >
> > <update id="Update" parameterClass="User">
> > UPDATE [User] SET
> > [Login] = #Login#,
> > [Password] = #Password#,
> > [Name] = #Name#,
> > [EmailAddress] = #EmailAddress#,
> > [DateLastUpdated ]= ${NOW}
> > WHERE
> > [UserId] = #UserId#
> > </update>
> >
> > In my current project, if I were to switch over to using
> parameterMaps
> > I would have to make 15 parameterMap nodes with at least 130
> parameter
> > nodes. That's a lot of typing! If I were working on a larger
> project
> > those numbers could be much higer. I don't want to have go through
> all
> > of my resultMaps and make sure I changed all the DateTime
> properties
> > correctly.
> >
> > There's nothing special about the default type handlers that ship
> with
> > IBatisNet other than the fact that they're the default handlers.
> Some
> > people may not like the default implementation or the default
> > implementation may not work with their project or database.
> >
> > Some other good reasons to support the ability to globally replace
> > certain default type handlers:
> >
> > Replace the default string type handler with one that automatically
> > converts all strings sent to/from the database to upper case.
> >
> > Replace the default DateTime type handler with one that
> automatically
> > translates a DateTime object into its Ticks representation (i.e.
> store
> > DateTime object as long).
> >
> > Replace the default string type handler with one that automatically
> > encrypts and decrypts values sent to the database.
> >
> > Replace the default string type handler with one that automatically
> > calls Trim() before sending values to the database so values in the
> > database never have leading or trailing whitespace.
> >
> > Replace the default double type handler with one that recognizes
> > double.NaN and automatically stores that as NULL in the database.
> >
> > Replace the default int type handler with one that recognizes
> > int.MinValue and automatically stores that as NULL in the database.
> >
> > Replace the default string handler with one that automatically
> converts
> > string.Empty to NULL when sending information to the database.
> >
> > Replace the default boolean handler with one that automatically
> > translates true/false into "Y" and "N" in the database.
> >
> > Replace the default boolean type hanlder that reverses the role of
> true
> > and false. When true is encountered it sends false to the database.
> > When false is encountered it sends true to the database.
> >
> > Replace the default int type handler with one that translates a
> > positive number into true, zero to NULL, and a negative number to
> > false.
> >
> > Replace the default string type handler with one that removes curse
> > words before storing data in the database.
> >
> > Replace the default string type handler with one that strips out
> > malicious html when storing data in the database (i.e. run a
> regular
> > expression on the string before sending it to the database)
> >
> > Replace the default double type handler with one that converts the
> > value to an integer before storing it in the database.
> >
> > Replace the default string type handler with one that reverses the
> > string before sending it to the database.
> >
> > Replace the default DateTime type handler that one that ignores the
> > time fields and only stores the Date part of the object in the
> > database.
> >
> > And of course what would a long post be a weird reference to
> > logginer...replace the default string type handler with one that
> emits
> > a log message if a certain value exists in ThreadContext or
> > HttpContext.
> >
> > --- Gilles Bayon <[EMAIL PROTECTED]> wrote:
> >
> > > Why don't you use nullValue attribute
> > > <result property="DateTransmissionPrevue"
> > > column="DateTransmissionPrevue"
> > > nullValue="01/01/0001 00:00:00" />
> > > <parameter property="DateLimiteTraitement" column="DateLimite"
> > > nullValue="01/01/0001 00:00:00" />
> > > -Gilles
> > >
> >
> >
>
