On Jan 21, 4:21 pm, Jonathan Pryor <[email protected]> wrote:
> 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).

Thanks for the replies Jon. I'm currently doing a sort of hybrid of
these two approaches, and while it works for me it sounds like it may
not be the most general solution, so I won't worry about trying to
modify the program itself.

However you hadn't replied to my other response... is there any reason
that for SELECT queries, DbMetal can't just run the query (maybe with
adding "WHERE 1=2" to prevent long execution times) and see what
result types it gets? I'd think that this would work for the majority
of cases where the return type is consistent (i.e. the sproc doesn't
use branching logic to return multiple possible result types).

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.

Reply via email to