On Jan 16, 1:20 pm, Jonathan Pryor <[email protected]> wrote: > On Fri, 2010-01-15 at 21:08 -0800, Toby Johnson wrote: > > On Jan 10, 4:37 pm, Toby Johnson <[email protected]> wrote: > > > I am using DbMetal with the --sprocs option to generate methods from > > > Stored Procedures but I see that this returns DataSets and not Linq > > > objects. > ... > > I've hacked together a Perl script that reads in a list of Sproc-to- > > type mappings, then goes through the generated file and replaces the > > sproc methods with a call to this method, using the appropriate return > > type and parameters. > > > So, if I actually modified the DbLinq sources to do this instead (say, > > add a command-line parameter to accept a sproc-to-type mapping file > > name, then use that to generate the sproc methods), would such a patch > > be considered for inclusion? > > No. The correct fix is to drop the DataSet and generate a *correct* > binding for the stored procedures. > > For example, .NET's sqlmetal generates the following method for a stored > procedure: > > [Function(Name="dbo.CustOrderHist")] > public ISingleResult<CustOrderHistResult> > CustOrderHist([Parameter(Name="CustomerID", DbType="NChar(5)")] string > customerID) > { > IExecuteResult result = this.ExecuteMethodCall(this, > ((MethodInfo)(MethodInfo.GetCurrentMethod())), customerID); > return > ((ISingleResult<CustOrderHistResult>)(result.ReturnValue)); > } > > // ... > public partial class CustOrderHistResult > { > > private string _ProductName; > > private System.Nullable<int> _Total; >
I think you misunderstood my solution. I completely agree that DataSets are undesirable; that's not what my script does. It's a sort of "halfway-there" solution. Determining the shape of the results would indeed be rather difficult, but in cases where the sproc is returning fields from one table only, it seems better to return a strongly-typed collection of the entities that are already defined. So if my database already has a "Customer" table, dbmetal would have generated a corresponding Customer class. Then if I have (for simplicity sake) a "GetAllCustomers" SP, and I can tell dbmetal that that SP returns Customer rows, then it can instead call ExecuteQuery<Customer> and return an IEnumerable<Customer> collection. Yes, it only solves a subset of SPs, and may be a temporary solution until a better one is found, but still seems better than returning DataSets. Toby
-- You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/dblinq?hl=en.
