uncarman / dapper-dot-net

Automatically exported from code.google.com/p/dapper-dot-net
Other
0 stars 0 forks source link

List Support doesn't work with 'Id IN (@Ids)' #114

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Example 'Id IN (@Ids)' where @Ids is IEnumerable parameter

What is the expected output? What do you see instead?
Expecting it to work like 'Id IN @Ids'
Instead Dapper crashes with System.Data.SqlClient.SqlException : Incorrect 
syntax near ','.

What version of the product are you using? On what operating system?
Microsoft SQL Server 2008 R2

Please provide any additional information below.
I use external .sql files with Dapper. It's a bit of an annoyance that those 
.sql files syntax doesn't validate in Visual Studio 2010, because 'Id IN @Ids' 
is not valid sql.
In visual studio validation stops to first error so after I use IN @Ids syntax 
validation stops to that place in my .sql file.

If 'Id IN (@Ids)' would work as well those .sql files syntax would validate 
just fine.

Original issue reported on code.google.com by jussi.ha...@gmail.com on 26 Sep 2012 at 10:25

GoogleCodeExporter commented 9 years ago
What is it an enumerable *of* ? Is it actually a `byte[]` by any chance?

Original comment by marc.gravell on 26 Sep 2012 at 12:25

GoogleCodeExporter commented 9 years ago
Array or ints

Original comment by jussi.ha...@gmail.com on 26 Sep 2012 at 1:15

GoogleCodeExporter commented 9 years ago
Oh, right; I see what you mean now - the difference between " in @ids" and " in 
(@ids)". There's a bit of a problem in that the latter could *technically* be 
legal, but intended to mean something else - hence we deliberately only do evil 
expansion  voodoo if the SQL intent is clear. In particular, because we're 
changing the syntax it seems a bit dangerous for it to *pretend* that it is 
behaving like an IN on a single value.

I can see that this might cause a little bit of visual clutter when editing, 
but this only presents itself when the file is open for editing, no? If we 
changed this (to work with parentheses) I would have to think very carefully to 
see if there are edge-cases where this could change the behavior.

Original comment by marc.gravell on 26 Sep 2012 at 1:37

GoogleCodeExporter commented 9 years ago
True problem is only when I edit my .sql files because syntax checking breaks 
when it encounters that.
It's not that big of deal but it would nice to see with syntax checker if wrote 
something wrong. But I can always comment out those parts temporarily to see if 
other parts are ok ;)
But if you can think of a way to remedy this I would grateful but if not, I can 
live with it :)

Original comment by jussi.ha...@gmail.com on 26 Sep 2012 at 2:12