MySQL Bugs: #70707: select of database guid reverse first 8th byte

Bug #70707	select of database guid reverse first 8th byte
Submitted:	23 Oct 2013 16:23	Modified:	29 Oct 2013 18:09
Reporter:	Ivan Ivan	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	Connector / NET	Severity:	S2 (Serious)
Version:	6.# 7.#	OS:	Any
Assigned to:	Fernando Gonzalez.Sanchez	CPU Architecture:	Any
Tags:	guid byte 8th binary(16)

Description:
file: \Source\MySql.Data\Types\MySqlGuid.cs
line: 42 
public MySqlGuid(byte[] buff)
{
...
      mValue = new Guid(buff);
...
if use this, first 8th byte reversed. 

var v = new byte[] { 
	0x18, 0xCB, 0xA8, 0x3D, 0x23, 0x82, 0x4B, 0x85, 
	0x93, 0xD8, 0x85, 0x53, 0xA2, 0x11, 0x87, 0x7A };

new Guid(v);
	{3da8cb18-8223-854b-93d8-8553a211877a}

new Guid(v.Take(4).Reverse().Concat(
                v.Take(6).Skip(4).Reverse().Concat(
                v.Take(8).Skip(6).Reverse().Concat(
                v.Skip(8)))).ToArray());
	{18cba83d-2382-4b85-93d8-8553a211877a}

How to repeat:
select binary(16) on database

Suggested fix:
change file: \Source\MySql.Data\Types\MySqlGuid.cs
line: 42

Hi,

Thanks for your bug report.

MySqlGuid uses internally System.Guid.

It is a known issue in System.Guid that is inverts the order for the first 8 bytes when using the constructor Guid(byte[]), this because internally stores the parts of the guid as
    private int _a;
    private short _b;
    private short _c;
    private byte _d;
    private byte _e;
    private byte _f;
    private byte _g;
    private byte _h;
    private byte _i;
    private byte _j;
    private byte _k;

(the first 8 bytes are stored in a int and 2 shorts, both types (int/short) are susceptible of big endianess).

For more details:
http://stackoverflow.com/questions/3320501/why-isnt-guid-tostringn-the-same-as-a-hex-strin...

Now, I wasn't able to reproduce this by reading from plain ADO.NET MySqlCommand & DbFirst Entities to SQL.

Now, from Guids created with another app or SQL itself, Connector/NET reads Guid 
by default as string (so uses Guid(string) constructor and there are no ordering issues).

Only if "Old Guids=true" is used in the connection string, then the guid is read as byte[] and Guid(byte[]) constructor is used, and so ordering issues may happen.

I am closing this as not a bug.

If you have more details on how to repro, please provide them, that will reopen the issue.

Thanks.