Open NZTSL opened 9 years ago
I would initially suggest that you make your byte array have a length of 16.
Although I know there is a reason you are using a hash as an id field, wouldn't life be a lot simpler if you used it as property and a plain-old-int as an id?
Hi, thanks for your answer.
Actually i'm using the column to store around 200 millions SHA-1 hash (20 bytes), so I can't store it in a int, and I think a string would be pretty slow to index, what do you think ?
The range of int on sql server is: -2^31 (-2,147,483,648) to 2^31-1 (2,147,483,647) or 4 bytes storage size. The C# is int or System.Int32 and is the same size. So, I think int would work in your situation for a while. There are also bigint types, etc. for MSSS.
I would still suggest that you make the length of the array involved fixed.
Dapper Extensions is setup to work well with identity fields, and an int identity field would make life a lot easier.
Because your hash field ends in Id, DE automatically declares it a key field whether you want it to or not.
You can download the source code and examine it for what it does, and I would recommend doing that to see how the wrapper works in your particular situation.
I also don't think the code authors respond to issues any more, so good luck with that.
not sure if you still have this problem. The problem is that DapperExtension predicate sees the value as an array so it is translating it to an IN statement.
I don't think that we have support for this kind of field in all database supported by DapperExtension. As tmsmith told before as it is an array it goes to an in not a single value.
I'm looking into it but it'll probably require you to inform this on the map
Hi, So if I have this table:
With the corresponding POCO:
Then this code will return null:
So I have to use this one instead:
Indeed the generated SQL code for the Get() looks a bit strange to me:
Regards, Nick.