Allow CommandBehavior.SingleResult and SingleRow

[NickCraver]

We're getting reports in Dapper of breaks after recent optimizations for single-result queries such as this: DapperLib/Dapper#441

While in this case it's CommandBehavior.SingleResult, all behaviors are fair game for ADO.Net Providers. But let's take it one at a time - can Sqlite either ignore this optimization or support it?

Related issue: #114

[divega]

We should already be ignoring SequentialAccess. I agree we should ignore more of these behaviors as long as they are just hints (and assuming we won't be actually taking advantage of them).

[NickCraver]

PR #221 open to ignore the behavior for now - no harm in ignoring for now and adding actual optimizations later.

[mgravell]

after recent optimizations for single-row queries

SingleResult is actually "single grid"; IMO you should also ignore SingleRow, which is a similar hint that can be safely ignored if the library doesn't choose to exploit it.

[divega]

👍 SingleRow is a hint that providers are not required to look at. It is even clearly documented as such.

[mgravell]

Some .NET Framework data providers may, but are not required to, use this information to optimize the performance of the command.

Agreed and cited

[NickCraver]

+1 - PR Updated to ignore both behaviors.

[NickCraver]

Any update on this? I'd really like for this simple change to be folded into the RC2 release.

[mgravell]

+another; pretty please with sprinkles on the top
On 13 Feb 2016 10:46 p.m., "Nick Craver" [email protected] wrote:

Any update on this? I'd really like for this simple change to be folded
into the RC2 release.

—
Reply to this email directly or view it on GitHub
#220 (comment)
.

[bricelam]

Well, since you asked so nicely... 😉

Sorry for the delay. We were waiting to get the OK from one of our partner teams who is going to take a dependency on RC2. I'll go ahead and merge the PR.

[johandanforth]

@bricelam any idea when there will be a 1.0.0-rc2 nuget package which includes this fix?