On Tue, 2010-01-19 at 23:05 -0800, Toby Johnson wrote: > 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.
I think I'm mis-understanding lots of things, unfortunately. The big one: how would stored procedure return type detection work? > 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. Right, but again, how do we tell this? From some googling around, it looks like what SqlMetal does is extract the actual SQL used in the stored procedure, parse it, and try to determine the structure of the data returned. I'm sure this is a cool piece of coding, but I don't see DbLinq doing that anytime soon... > 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. Right, and this requires manual intervention (hence your helper script). > 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. So it's a matter of tradeoffs. Just to easily support `DbMetal /sprocs` now, we need to support DataSet as the return type for the "no manual intervention required" scenario. For a manual mapping, that presents (at least) two solutions: 1. Add a DbMetal option to allow the user to specify a return type for a stored procedure. DbMetal could then provide a decent return type. 2. Take advantage of the fact that all DbMetal-generated types are partial classes, and just add new methods that use your nice return types in separate partial class definitions. The advantage of (2) over (1) is that DbMetal doesn't need to do anything to support it. :-) (Yay less code!) It can also be done today. Of course the disadvantage is that DbMetal will thus be generating methods that will show up in IntelliSense/etc. that you may not want to be shown, and there's no existing mechanism to hide these methods (except for dropping /sprocs, which will prevent any stored procedure from being generated, and perhaps /generate-type so you could generate/not generate stored procedures on a per-type basis). Of these, I'm inclined toward the "less code" solution, though it might also be possible to always generate some internal helper methods in the generated DataContext/etc. to more easily support wrapping the stored procedure calls. - Jon
-- 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.
