Thank you, Nathan,
But for
<update id="updateProduct" parameterClass="product">
update PRODUCT set
PRD_ID = "#id:NUMBERIC",
PRD_DESCRIPTION #description:VARCHAR#
</update>
I find that if you change:
PRD_DESCRIPTION #description:VA%%$$--0099# or
PRD_DESCRIPTION #description:a# .....
it is still working without any exception. However in Insertion, it strictly
complies with the iBatis syntax/role. So I don't think that the inline type
declaring works in update case. Any idea? Thanks.
Tim
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 30, 2005 1:47 PM
To: [email protected]
Subject: Re: [jira] Created: (IBATIS-215) BSF for dynamic queries
It is identical to the insert. I would also suggest using the more specific
maps like <insert> and <update> instead of the catch all <statement>.
<insert id="insertProduct" parameterClass="product">
insert into PRODUCT (
PRD_ID,
PRD_DESCRIPTION
) values (
#id:NUMERIC#,
#description:VARCHAR#
)
</insert>
<update id="updateProduct" parameterClass="product">
update PRODUCT set
PRD_ID = "#id:NUMBERIC",
PRD_DESCRIPTION #description:VARCHAR#
</update>
Nathan
On Nov 30, 2005, at 9:57 AM, Tim Ding wrote:
> Good Morning, My friends,
>
> Is there Inline Type Declaring for Update in iBatis? I know for
> Insertion that there is something like:
>
> <statement id="insertProduct" parameterClass="product">
> insert into PRODUCT (PRD_ID, PRD_DESCRIPTION)
> values (#id:NUMERIC#, #description:VARCHAR#); </statement>
>
> But how about for Update case?
>
> Thanks!
> Tim Ding
>
> -----Original Message-----
> From: Paul Benedict (JIRA) [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, November 02, 2005 4:43 PM
> To: [email protected]
> Subject: [jira] Created: (IBATIS-215) BSF for dynamic queries
>
> BSF for dynamic queries
> -----------------------
>
> Key: IBATIS-215
> URL: http://issues.apache.org/jira/browse/IBATIS-215
> Project: iBatis for Java
> Type: New Feature
> Components: SQL Maps
> Reporter: Paul Benedict
>
>
> While the list of tags to form dynamic queries is suitable, they are
> limiting because they stop the "dreamer from dreaming." More complex
> logic cannot be addressed without creating a barrage of new tags.
>
> I propose a new tag called <script> (or something similar) which is
> backed by the Apache Bean Scripting Framework. The parameter map
> passed in to the <statement> should load it into the scripting
> Interpreter object and expose it for the <script> tag so that dynamic
> Java or JavaScript can return boolean parameters. Obviously there is a
> performance hit for this and the previous tags would be much simpler
> for common boolean operations, but the sky is the limit when it comes
> to what you can compare inside the script.
>
> Example:
> <select id="dynamicGetAccountList" cacheModel="resultMap="account-
> result" >
> select * from ACCOUNT
> <script><expression>obj.id != null && obj.id > 0 &&
> obj.lastName.startsWith("B")"</expression>
> where ACC_ID = #id# and
> ACC_NAME = #lastName#
> </script>
> order by ACC_LAST_NAME
> </select>
>
> If BSF is not suitable, please look into OGNL which is popular within
> Apache Tapestry and is a very good alternative.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the
> administrators:
> http://issues.apache.org/jira/secure/Administrators.jspa
> -
> For more information on JIRA, see:
> http://www.atlassian.com/software/jira
>
