Since we have split queries again, SqlServer may fail without MARS.
We could add DbOption configuration for users to tell us if they have MARS on or not.
smitpatel
All 6 comments
Is MARS not already specified in the connection string?
ErikEJ
on 26 Jun 2020
Yes, it is. I guess we can just evaluate the connection string and determine too. I don't know how we did in 2.x.
Mainly in query we need flag that if MARS is on or not so we can appropriately buffer for split query scenario so exception is not thrown.
smitpatel
on 26 Jun 2020
smitpatel
on 26 Jun 2020
Note from triage: we will try bringing back the 2.2 code for this. We should also decide whether or not to assume that a provider can do MARS.
ajcvickers
on 26 Jun 2020
For other providers implementing preview6, the current implementation of query splitting assumes MARS capabilities by default, and so will fail if the provider doesn't support them. To make EF Core buffer instead, create your own subclass of RelationalQueryCompilationContext (defining a factory that returns it, and registering that factory with EF Core), with the following:
c#
public override bool IsBuffering => base.IsBuffering || IsSplitQuery;
Since MARS once again is an exception in the provider landscape (although it happens to be supported by Sqlite and SQL Server when enabled), I really think it would be better to not require all providers to do this - discoverability is going to be difficult, and the buffering behavior will always work across all providers, where MARS is strictly-speaking an optimization only. It seems pretty trivial for RelationalQCC to expose a hook that allows Sqlite and SQL Server to opt in, rather than forcing everyone else to opt out.
/cc @lauxjpn
roji
on 26 Jun 2020
Since MARS once again is an exception in the provider landscape (although it happens to be supported by Sqlite and SQL Server when enabled), I really think it would be better to not require all providers to do this - discoverability is going to be difficult, and the buffering behavior will always work across all providers, where MARS is strictly-speaking an optimization only. It seems pretty trivial for RelationalQCC to expose a hook that allows Sqlite and SQL Server to opt in, rather than forcing everyone else to opt out.
I second that. EF Core should default to the most common/reasonable approach across the provider landscape, not the SQL Server implementation.
lauxjpn
on 1 Jul 2020
Related issues
ericvb
路
3Comments
spottedmahn
路
3Comments
ghost
路
3Comments
divega
路
3Comments
januszj
路
3Comments
Most helpful comment
For other providers implementing preview6, the current implementation of query splitting assumes MARS capabilities by default, and so will fail if the provider doesn't support them. To make EF Core buffer instead, create your own subclass of RelationalQueryCompilationContext (defining a factory that returns it, and registering that factory with EF Core), with the following:
c# public override bool IsBuffering => base.IsBuffering || IsSplitQuery;Since MARS once again is an exception in the provider landscape (although it happens to be supported by Sqlite and SQL Server when enabled), I really think it would be better to not require all providers to do this - discoverability is going to be difficult, and the buffering behavior will always work across all providers, where MARS is strictly-speaking an optimization only. It seems pretty trivial for RelationalQCC to expose a hook that allows Sqlite and SQL Server to opt in, rather than forcing everyone else to opt out.
/cc @lauxjpn