You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When writing extensions for EF it's actually incredibly hard to find out what DB engine is being used. You end up checking the connection which is a problem if that is wrapped because of things like profiling. (Don't get me started on what I feel about the IConnection design)
Simply being able to get the info about the db or the provider being used would solve this.
The text was updated successfully, but these errors were encountered:
This should indeed be possible without a lot of hoops.
I've planned to factor out the DB engines, I don't think they'll be placed in different assemblies, as they'll use DbProviderFactory. Additionally, there will be compatibility modes, so the engine can be set into compatibility mode X so it will generate SQL matching the DBs of vX, e.g. compatibility mode for SQL server 2005 or 2008 or 2012. So combined this info should give you what you want. Though in general I think this should be taken into account for extensibility points to the engine: it's of no use if data is available but there are no ways to extend the engine to begin with ;).
When writing extensions for EF it's actually incredibly hard to find out what DB engine is being used. You end up checking the connection which is a problem if that is wrapped because of things like profiling. (Don't get me started on what I feel about the IConnection design)
Simply being able to get the info about the db or the provider being used would solve this.
The text was updated successfully, but these errors were encountered: