forked from dallasbeek/Dapper.Database
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Oracle #1
Closed
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I just realized the |
Also adding test suite SQL file in Oracle syntax.
This came up in their Docker offering. https://stackoverflow.com/questions/6134006/are-table-names-in-mysql-case-sensitive
* Now overriding Exists to use SELECT 1 FROM DUAL because Oracle needs a FROM. * Adding a wrapper for OracleCommand (and by extension, OracleConnection) that parses out '@' binds and replaces them with ':' binds ODP.NET can digest.
The ODP.NET driver apparently half-supports Guids -- for EF only. When it does, it always does little-endian...
Oracle supports using bind variables for its pagination offset/size, so I am modifying Dapper.Database to support this. There are probably other database engines that support it, but I don't know which ones, so I am not having the others bind their parameters...
Apparently they fixed something in 12.2 to handle the bind variable names I've chosen...
I hate to introduce ReSharper stuff into someone else's project, but in this case the tests flat-out fail if run in parallel, if only because you have multiple runtimes initializing the same databases with the same DDL.
Oracle does it that way, and from what I can tell, all the other drivers do, too.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added support for Oracle to Dapper.Database -- barely.
The problem
While this addresses a number of problems that we were having with our Dapper fork (vauto/Dapper#1) by virtue of there being more overrides (and fixing the caching bug in Dapper.Contrib as well!), there's still a number of problems caused by Oracle itself:
Guid
Oracle's drivers (unmanaged, managed full framework, managed .NET Core) all reject
DbType.Guid
as an input type.Specifying an alternate type is problematic for two main reasons:
IDbConnection.Execute(...)
extension methods resolveDbType
via thetypeMap
and not type handlers, so the only way to change it for Oracle is to change it globally withinSqlMapper
. While fortunately this can be done via theSqlMapper.AddTypeMap
method, this change effectively prevents any other databases from working properly, which means as a general-purpose solution for users using multiple database types in the same process, it's a non-starter.Guid
tobyte[]
viaToByteArray()
andGuid(byte[])
respectively. This results in the bytes being "flipped" due to Microsoft choosing to make Guid little-endian. However, per this StackOverflow article, big-endian storage may be preferred. In fact, the tests in Dapper.Database convertGuid
toBinary
in big-endian format.varchar
column instead ofchar
).Bind variables
Despite most databases not supporting the SQL Server bind variable format (
@foo
), most .NET adapters seem to have gone out of their way to work with bind variables named this way. All the tests in the Dapper.Database project show this. Even Npgsql (the PostgreSQL driver) does this.However, there is one major, glaring exception -- ODP.NET. No implementation of the Oracle driver makes any attempt to pre-parse SQL, so the bind variables are passed all the way down to Oracle as specified. This results in unclear errors like
ORA-00936: missing expression
,ORA-00923: FROM keyword not found where expected
, and many more.This means most of the tests in Dapper.Database fail simply on account of using the at-sign to denote bind variables, despite working with everything else.
The solution
Unfortunately there is no good solution that will please everyone. This appears to be what @mgravell was referring to in DapperLib/Dapper#637:
and again in DapperLib/Dapper#633:
So there really isn't a solution that will work for everyone. The basis of all the solutions is very similar, but simply won't work in a simple, turnkey fashion.
I am going to close out this branch and simply make an in-house library that implements Oracle how we (vAuto) use it by overriding the adapter resolution by hooking into
SqlMapperExtensions.GetDatabaseType
. If there is a way to release this as a globally available library, it will require a nontrivial amount of Oracle-specific code, which is probably not what the maintainers of Dapper or Dapper.Database want.