2.0Beta1: Determine T from T?

[n8wrl@arrl.net]

Good afternoon!

I have a method that adds a SQL parameter with the right SQLtype based
on a CLR type:

public void AddParam<T>(str ing name, T value)
{
...
}

I translate 'T' to a valid DbType. The problem is when T is Nullable,
as in

AddParam<int?>( name, x);

How can I get the 'int' from 'int?' inside AddParam() so I can
translate the type & handle NULLs properly?

Things I've tried:

* Nullable.ToObje ct<T>(value) returns a boxed object.
* value ?? value returns a T?
* Nullable.ValueO rDefault<T>(val ue) returns a boxed object.
* Try a Nullable-specific AddParam<T>(... ) where T : Nullable but that
complains about static structures as a constraint.
* Assign value directly to the SQL procedure but I get a "No mapping
exists from object type System.Nullable to a known managed provider
native type."

Thanks!

-Brian

[Sylvain Lafontaine]

Re: 2.0Beta1: Determine T from T?

Why aren't you using a SqlTypes like SqlInt32 instead of « int? » ?

int? has not be introduced with the intent of replacing SqlTypes like
SqlInt32.

S. L.

<n8wrl@arrl.net > wrote in message
news:1111438163 .933615.302740@ l41g2000cwc.goo glegroups.com.. .[color=blue]
> Good afternoon!
>
> I have a method that adds a SQL parameter with the right SQLtype based
> on a CLR type:
>
> public void AddParam<T>(str ing name, T value)
> {
> ...
> }
>
> I translate 'T' to a valid DbType. The problem is when T is Nullable,
> as in
>
> AddParam<int?>( name, x);
>
> How can I get the 'int' from 'int?' inside AddParam() so I can
> translate the type & handle NULLs properly?
>
> Things I've tried:
>
> * Nullable.ToObje ct<T>(value) returns a boxed object.
> * value ?? value returns a T?
> * Nullable.ValueO rDefault<T>(val ue) returns a boxed object.
> * Try a Nullable-specific AddParam<T>(... ) where T : Nullable but that
> complains about static structures as a constraint.
> * Assign value directly to the SQL procedure but I get a "No mapping
> exists from object type System.Nullable to a known managed provider
> native type."
>
> Thanks!
>
> -Brian
>[/color]

[BrianS]

Re: 2.0Beta1: Determine T from T?

At some point I have to interface SQL types to 'real' types on business
objects - types clients are familiar with, like int, string, etc. This
is the place I chose to do that.

Thanks for the reply!

[Alexander Shirshov]

Re: 2.0Beta1: Determine T from T?

Brian,

Probably I'm missing something, but I don't understand what are you trying
to achieve.

Since you're passing a value, you already have type information in it and
you can simply call GetType():

void AddParam(string name, object value)
{
if (value.GetType( ) == typeof(string))
{
...
}
....
}

If you want to give callers some degree of control over parameter's data
type (like in AddParam("int_c olumn", "123")) then you could add an overload
with datatype parameter:

void AddParam(string name, object value, Type dataType)


HTH,
Alexander

<n8wrl@arrl.net > wrote in message
news:1111438163 .933615.302740@ l41g2000cwc.goo glegroups.com.. .[color=blue]
> Good afternoon!
>
> I have a method that adds a SQL parameter with the right SQLtype based
> on a CLR type:
>
> public void AddParam<T>(str ing name, T value)
> {
> ...
> }
>
> I translate 'T' to a valid DbType. The problem is when T is Nullable,
> as in
>
> AddParam<int?>( name, x);
>
> How can I get the 'int' from 'int?' inside AddParam() so I can
> translate the type & handle NULLs properly?
>
> Things I've tried:
>
> * Nullable.ToObje ct<T>(value) returns a boxed object.
> * value ?? value returns a T?
> * Nullable.ValueO rDefault<T>(val ue) returns a boxed object.
> * Try a Nullable-specific AddParam<T>(... ) where T : Nullable but that
> complains about static structures as a constraint.
> * Assign value directly to the SQL procedure but I get a "No mapping
> exists from object type System.Nullable to a known managed provider
> native type."
>
> Thanks!
>
> -Brian
>[/color]

[Jon Skeet [C# MVP]]

Re: 2.0Beta1: Determine T from T?

Alexander Shirshov <alexander@omni talented.com> wrote:[color=blue]
> Probably I'm missing something, but I don't understand what are you trying
> to achieve.
>
> Since you're passing a value, you already have type information in it and
> you can simply call GetType():
>
> void AddParam(string name, object value)
> {
> if (value.GetType( ) == typeof(string))
> {
> ...
> }
> ....
> }[/color]

Note that that's a lot slower (and less readable, IMO) than:

if (value is string)

or

string valAsString = value as string;
if (valAsString != null)
{
....
}

--
Jon Skeet - <skeet@pobox.co m>

http://www.pobox.com/~skeet

If replying to the group, please do not mail me too

[Alexander Shirshov]

Re: 2.0Beta1: Determine T from T?


"Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
news:MPG.1ca9d4 0faa8621f198beb 5@msnews.micros oft.com...[color=blue]
> Note that that's a lot slower (and less readable, IMO) than:
>
> if (value is string)[/color]

Is uniformity important for readability? "is" will not work for value types.

And I don't think the performance is an issue for the original poster. DB
operations are many orders of magnitude slower and I don't think anyone
would be adding query parameters by thousands.

[Daniel O'Connell [C# MVP]]

Re: 2.0Beta1: Determine T from T?


"Alexander Shirshov" <alexander@omni talented.com> wrote in message
news:%23RCCvDrL FHA.132@TK2MSFT NGP10.phx.gbl.. .[color=blue]
>
> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
> news:MPG.1ca9d4 0faa8621f198beb 5@msnews.micros oft.com...[color=green]
>> Note that that's a lot slower (and less readable, IMO) than:
>>
>> if (value is string)[/color]
>
> Is uniformity important for readability? "is" will not work for value
> types.
>[/color]

I believe you are mistaken. "as" will not work for value types, but is will
work perfectly well. "is" will(atleast in the 2.0 beta) issue a warning
informing you that the expression will always be true if you apply is to a
value type variable(ie meaning a non-boxed value type), but it still works.

[BrianS]

Re: 2.0Beta1: Determine T from T?

You're probably right. I was trying to use generics to avoid boxing and
a dozen type-specific methods that are all pretty much the same. But
since It's assigned to SqlParameter.Va lue we box anyway.

The other problem is even if value is an int?, for example, 'if (value
is Nullable)' returns false, so it's not easy to figure that out in a
generic <T> way.

Thanks for the input!

-Brian

[Alexander Shirshov]

Re: 2.0Beta1: Determine T from T?

Yes, I quoted and commented not the sentence I intended. Thanks for
correcting.

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:OY4VrirLFH A.3380@TK2MSFTN GP15.phx.gbl...[color=blue]
>
> "Alexander Shirshov" <alexander@omni talented.com> wrote in message
> news:%23RCCvDrL FHA.132@TK2MSFT NGP10.phx.gbl.. .[color=green]
>>
>> "Jon Skeet [C# MVP]" <skeet@pobox.co m> wrote in message
>> news:MPG.1ca9d4 0faa8621f198beb 5@msnews.micros oft.com...[color=darkred]
>>> Note that that's a lot slower (and less readable, IMO) than:
>>>
>>> if (value is string)[/color]
>>
>> Is uniformity important for readability? "is" will not work for value
>> types.
>>[/color]
>
> I believe you are mistaken. "as" will not work for value types, but is
> will work perfectly well. "is" will(atleast in the 2.0 beta) issue a
> warning informing you that the expression will always be true if you apply
> is to a value type variable(ie meaning a non-boxed value type), but it
> still works.
>
>[/color]