ibatis-user-cs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Clough, Samuel \(USPC.PRG.Atlanta\)" <Samuel_Clo...@princetonrg.com>
Subject RE: Parameter Class Usage
Date Wed, 09 May 2007 16:13:05 GMT
I didn't totally understand the original question.  If you have a custom
object (like Tom's Product example below), then the code below works
perfectly.  If you just need to pass a few parameters to a sql statement
and it isn't related to a logical, custom type and you don't want to
create one, you can just use an Idictionary for your parameter class
like I mentioned.  

Try reading this page in the documentation, I think it's pretty clear.

If you're trying to do the latter, your code would look like:

Dictionary<String, String> params = new Dictionary<String, String>();

Params["ID"] = "testid";
Params["Name"] = "testname";

                , params);

The mapping is documented at the end of the link I sent you.  It's
basically the same as Tom's except that your

-----Original Message-----
From: Nguyen, Tom [mailto:Tom.Nguyen@rels.info] 
Sent: Wednesday, May 09, 2007 11:44 AM
To: user-cs@ibatis.apache.org
Subject: RE: Parameter Class Usage

Rough example:

1st.  You should define a typeAlias for your parameter class so iBatis
can create property getter and setter on.

    <typeAlias alias="Project" type="Noogen.Test.Project, Noogen.Test"

Then you can map it like this:

    <select id="Noogen.Test.Project.IsValid" 
        parameterClass="Project" resultClass="System.Int32">
      FROM [dbo].[Project] (READUNCOMMITTED)
      WHERE DeletedDate IS NULL
      	AND ProjectID = #ID#
      	AND ProjectName = #Name#

The Project class would of course have two property (ID and Name).


Project p = new Project();
p.ID = 1;
p.Name = "test";
int? result =
                , p);

Of course you can also use hashtable or dictionary as your parameter
class.  In this case, you don't really need to create alias.

Instead of: parameterClass="Project"
Change to: parameterClass="System.Collections.IDictionary"

Dictionary<string, object> d = new Dictionary<string, object>();
d.Add("ID", 1);
d.Add("Name", "test");

int? result =
                , d);


Tom Nguyen 
Sr. Developer

-----Original Message-----
From: Garth Keesler [mailto:garthk@gdcjk.com] 
Sent: Wednesday, May 09, 2007 10:05 AM
To: user-cs@ibatis.apache.org
Subject: Re: Parameter Class Usage

I've been searching the docs and came across ArrayList as a mechanism 
for parameter passing that should work "out of the box" but I found no 
examples of using it so I kept looking and happened across the Parameter

Class. Further searching turned up no examples of using it either so I 
posed the question. I'll keep searching the docs/web.


Clough, Samuel (USPC.PRG.Atlanta) wrote:
> If I understand your question, what you want to use is a dictionary
> your parameter class which lets you set whatever parameters you want.
> believe this is fairly well documented in the documentation. 
> -----Original Message-----
> From: Garth Keesler [mailto:garthk@gdcjk.com] 
> Sent: Wednesday, May 09, 2007 10:47 AM
> To: user-cs@ibatis.apache.org
> Subject: Parameter Class Usage
> I'm probably way off on this but it appears that the Parameter Class
> designed to allow the convenient passing in of parameters for
> SQL statements without having to create dedicated classes for each 
> combination of parameters needed by the different statements. If this
> so, can anyone point me to an example of their use? In particular, I 
> need to pass in two string values to the SELECT statement. I've been 
> using the  result class as the source of the parameters but I would 
> prefer not to do that in general. Both the XML and c# would be greatly

> appreciated.
> Thanx,
> Garth 
> --------------------------------------------------------
> Princeton Retirement Group, Inc - Important Terms 
> This E-mail is not intended for distribution to, or use by, any person
or entity in any location where such distribution or use would be
contrary to law or regulation, or which would subject Princeton
Retirement Group, Inc. or any affiliate to any registration requirement
within such location. 
> This E-mail may contain privileged or confidential information or may
otherwise be protected by work product immunity or other legal rules. No
confidentiality or privilege is waived or lost by any mistransmission.
Access, copying or re-use of information by non-intended or
non-authorized recipients is prohibited. If you are not an intended
recipient of this E-mail, please notify the sender, delete it and do not
read, act upon, print, disclose, copy, retain or redistribute any
portion of this E-mail. 
> The transmission and content of this E-mail cannot be guaranteed to be
secure or error-free. Therefore, we cannot represent that the
information in this E-mail is complete, accurate, uncorrupted, timely or
free of viruses, and Princeton Retirement Group, Inc. cannot accept any
liability for E-mails that have been altered in the course of delivery.
Princeton Retirement Group, Inc. reserves the right to monitor, review
and retain all electronic communications, including E-mail, traveling
through its networks and systems (subject to and in accordance with
local laws). If any of your details are incorrect or if you no longer
wish to receive mailings such as this by E-mail please contact the
sender by reply E-mail. 
> --------------------------------------------------------
> .

This e-mail message and any files transmitted herewith, are intended
solely for the
use of the individual(s) addressed and may contain confidential,
proprietary or 
privileged information.  If you are not the addressee indicated in this
(or responsible for delivery of this message to such person) you may not
use, disclose or distribute this message or any files transmitted
herewith.  If you 
receive this message in error, please contact the sender by reply e-mail
and delete
this message and all copies of it from your system.

View raw message