[ http://issues.apache.org/jira/browse/IBATIS-358?page=all ]
Jeff Butler closed IBATIS-358.
------------------------------
Resolution: Fixed
I added a section to the PDF regarding substitution strings, and reworded some
of the sections on inline parameter maps. Hopefully, this helps.
The iterate tag does support Collection, Iterator, or an array. See the
com.ibatis.sqlmap.engine.mapping.sql.dynamic.elements.IterateContext class.
> Wrong description of how inline parameters are handled
> ------------------------------------------------------
>
> Key: IBATIS-358
> URL: http://issues.apache.org/jira/browse/IBATIS-358
> Project: iBatis for Java
> Issue Type: Bug
> Components: Documentation
> Environment: iBatis Data Mapper Development Guide Version 2.0, August
> 9, 2006
> Reporter: Robert Jäschke
> Assigned To: Jeff Butler
>
> The description of how inline parameters are handled (compare pages 23 and
> 28) is wrong.
> On page 23 it is written that they are used "to populate the statement
> parameter in-place" and
> on page that they are "coded directly into the SQL". But this is not true:
> using something like "#id#"
> actually creates a PreparedStatement with "?" which is filled with "id"
> later.
> This should be made clear on these sections!
> Furthermore I could not find a description of the difference between using
> "#id#" and "$id$" in
> the manual. It first occurs (?) on page 50, where dynamic elements are
> described. The difference
> is, that "$id$" does, what is said on pages 23/28, that the value is directly
> coded into the SQL
> (in which way? Is it quoted, if neccessary, or not?) and that "#id#" makes it
> a parameter of a
> prepared statement. In this occasion I must say I could not find out from the
> manual, if iBatis
> uses PreparedStatements or not or when it uses them (a look into SqlExecutor
> revealed, that
> it always uses PreparedStatements?!).
> As a sidenode: On page 49 it is said, that the "iterate" attribute "property"
> does also allow
> java.util.Iterator, but tests and a look into the source revealed, that this
> is not the case (it
> always checks, if it is a collection or an array?!).
> Just my 2 cents, hoping that I haven't overlooked something.
--
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
