Regarding the sproc support: Yes, imagine calling a procedure like this:
<procedure parameterClass="MyParameter" ....> dbo.BringMeCoffee #property=BrandID,default=6#, #property=MugSize,default=5# </procedure> Regarding decoupling SqlMappers: No, I don't want to get any deeper than the elegant interface the SqlMapper provides. Imagine, however, that you have many databases with the same schema. You want to use the same SqlMapper against them, but the SqlMapper is tightly coupled to the database it is initially pointed at. The way I got around this problem was to run SqlMap config files through a filter that replaced their connection strings when loaded, but that still means creating parameter caches against each and every DB. Now, it may be an unusual circumstance to be maintaining connection pools against multiple same-schema databases... Thanks for the replies, I'll also check out the other boards. -----Original Message----- From: Ron Grabowski [mailto:[EMAIL PROTECTED] Sent: Thursday, March 30, 2006 4:38 AM To: [email protected] Subject: Re: MySpace.com --- Christopher Bissell <[EMAIL PROTECTED]> wrote: > *Syntactically, better support in the mapping files for stored > procedure parameters. We like the inline parameter methods you can > use with dynamic SQL, would be nice to have a way to use that with > sprocs too. You mean instead of being required to use a parameterMap and use question mark place holders: ?, ?, ? You'd like to use this: #FirstName#, #LastName#, #Age,type=int,dbType=int,handler=FooHandler# The Java and Dev list are also good lists to sign up up and discuss things like this too. They get more traffic than this list. The IBatisNet developers are signed up to all the lists. > *Better decoupling of SqlMappers from physical databases / db > connections. > Decoupling is implicit in the object model, but it's difficult to use > the SqlMapper as 'just' a repository of maps, rather than as an > abstraction in front of a physical database. Do you have cases where you just need the underlying statement: IMappedStatement mappedStatement = sqlMapper.GetMappedStatement("Select"); Then you can execute that statement on your own? // populate IDbCommand and its parameter collection IDbCommand command = mappedStatement.GenerateCommand(); Wouldn't you be missing out on the resultMap engine if you do things that way? - Ron
