Hi,
I'm trying to get Guid columns from Oracle Database (RAW: Generated by Entity Framework code first), and is thrown an exception. Is there some method to achieve it?
Thank you!
What is the exact error message? I'm hoping it gives a hint as to the data
type coming back. If it is a byte[]
, and specifically a byte[16]
, then
yes, I think can can and should support that. If it is something more
exotic... less obvious.
On 3 November 2016 at 09:10, Rojiferio [email protected] wrote:
Hi,
I'm trying to get Guid columns from Oracle Database (RAW: Generated by
Entity Framework code first), and is thrown an exception. Is there some
method to achieve it?Thank you!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/637, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AABDsNtrp0j7xi3R3-jKCml7rk8zdbOQks5q6aUBgaJpZM4KoIEs
.
Regards,
Marc
Thanks for response,
the error doesn't give me too much information:
Message: "Specified cast is not valid"
Target site: "Deserialize3c1a1cf8-4ac3-44b7-add5-d45d0c40cbfc(System.Data.IDataReader)"
The column is defined as RAW in Oracle, and I want to load in a Guid property. If I get the info using EF works....
Thanks again!
Can you show me the code that you're using there? Because in many cases, the library injects a lot more context. I'm curious as to why that's being bypassed...
[TestMethod]
public void DapperOracle()
{
try
{
var factProvDb = ProviderDatabaseFactory.GetProviderDatabase("Oracle.ManagedDataAccess.Client", "");
using (var ctx = DPMContextFactory.CreateDPMContext(factProvDb))
{
var sql = @"SELECT * from ""Units""";
var aux = ctx.Database.Connection.Query<PersistenceModel.Entities.Unit>(sql);
}
}
catch (Exception ex)
{
var aux = ex.Message;
}
}
And the query should returs that info: (Data columns defined as RAW (16))
K, I'll see what I can do. There's a slight complication, because .NET Guid
does something incredibly stupid I like to call "crazy-endianness", where the byte-order from the byte[]
-based methods is essentially random. For giggles. So I need to be very careful to ensure that what we actually get is what you expected.
Here's an illustration:
var guid = Guid.Parse("00112233-4455-6677-8899-aabbccddeeff");
var bytes = guid.ToByteArray();
// shows "33-22-11-00-55-44-77-66-88-99-AA-BB-CC-DD-EE-FF"
Console.WriteLine(BitConverter.ToString(bytes));
var guid2 = new Guid(bytes);
// shows "00112233-4455-6677-8899-aabbccddeeff"
Console.WriteLine(guid2);
That is not .NET-specific, is it? That is just native Microsoft GUID format, differing in the endianness of the first three pieces from the RFC 4122 format, AFAICT.
Why method GetGuid is not suported in OracleDataReader Class?????
http://docs.oracle.com/cd/E51173_01/win.122/e17732/OracleDataReaderClass.htm#ODPNT1185
¿is this the problem?
Error parsing column 0 (Id=System.Byte[] - Object)
en Dapper.SqlMapper.ThrowDataException(Exception ex, Int32 index, IDataReader reader, Object value)
en Deserializecf1bf2a6-f889-4904-8c6e-d2c993e5e67d(IDataReader )
en Dapper.SqlMapper.1.MoveNext()
en System.Collections.Generic.List
1..ctor(IEnumerable1 collection)
en System.Linq.Enumerable.ToList[TSource](IEnumerable
1 source)
en Dapper.SqlMapper.QueryT
en PersistenceUnitTes
I'm so deseperated...
I hope to look at this tomorrow.
I saw your post and was interested. It looks like the answer is that the first 3 sets of the guid are integer types which are independently subject to big endian formatting. The remaining sets of the guid are a byte array and are not subject to endian formatting.
I'm have built and uploaded 1.50.3-beta1 that tries to address this. Is there any chance you could try it and let me know if it works?
Thanks!
I expect to can ckeck your release this week , I solved my issue implmenting a custom TypeHandler for Guid:
class GuidTypeHandler : SqlMapper.TypeHandler<Guid>
{
public override Guid Parse(object value)
{
var inVal = (byte[])value;
return new Guid(inVal);
}
With this code I can read data without problem.
I'll answer you as soon as possible.
Thank you again!
@Rojiferio just looking to close this out if we're all good here - can you please let us know when you get a chance? Thanks!
I need to revert
https://github.com/StackExchange/dapper-dot-net/commit/91725fb309a9e5948f760fac420dd805659f0749;
the upshot if this is that there is no reliable cross-provider mechanism
that works well for this.
On 3 Dec 2016 12:36 p.m., "Nick Craver" notifications@github.com wrote:
@Rojiferio https://github.com/Rojiferio just looking to close this out
if we're all good here - can you please let us know when you get a
chance? Thanks!—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/StackExchange/dapper-dot-net/issues/637#issuecomment-264636845,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABDsNoYwMUQimLuRSateLPg22N6msL8ks5rEWJAgaJpZM4KoIEs
.
Reverted; sorry, closing this down since we can't support it natively in the lib due to the incompatibility between backends
Most helpful comment
K, I'll see what I can do. There's a slight complication, because .NET
Guid
does something incredibly stupid I like to call "crazy-endianness", where the byte-order from thebyte[]
-based methods is essentially random. For giggles. So I need to be very careful to ensure that what we actually get is what you expected.Here's an illustration: