The EntitySpaces Community

Share and learn about the EntitySpaces Architecture.
Welcome to The EntitySpaces Community Sign in | Join | Help
in
Home Forums Photos

MySQL and real GUID type

Last post 08-31-2008, 10:41 AM by econner. 11 replies.
Sort Posts: Previous Next
  •  06-02-2008, 5:48 PM 9580

    MySQL and real GUID type

    Mike,

    Did you post anything to the MySQL forum regarding the request for a real GUID type as per your latest blog post?

    Thanks

  •  06-03-2008, 9:20 AM 9590 in reply to 9580

    Re: MySQL and real GUID type

    I'm sorry, I haven't gotten to that, I've actually been quite ill, hopefully getting better, there was supposed to be a release candidate out last weekend but I have been totally derailed, the last two days have been better, hopefully I'm out of the woods, but it's been 10 days now.

    EntitySpaces | Twitter | BLOG | Please honor our Software License
  •  06-12-2008, 5:17 PM 9795 in reply to 9590

    Re: MySQL and real GUID type

    Mike,

    Have you been able to get the Binary(16) GUID in MySQL to work? From a performance standpoint will it be better than using a varchar(36) field that is indexed? What about compatibility from MySQL to MS SQL or VistaDB?

     

  •  06-12-2008, 5:30 PM 9796 in reply to 9795

    Re: MySQL and real GUID type

    Well, I know you're going to be disappointed and we almost hacked it in but decided it was too risky. Let me give you some reasoning. Our meta data engine performs its mapping on the core database column type. For instance, we map a CHAR to a' string' (via the esLanguages..xml) mapping file. We don't map against the full datatype name, i.e., CHAR(1) - however, if we did we could say map a CHAR(1) to a 'char' and CHAR(2)+ to a 'string'. I started to put the code in actually for you and it got nasty as I was adding exceptions all over in the code. MySQL's decision is unfortunate it's like say we're going to use NVARCHAR(8) as a LONG and doing conversions rather than adding a true LONG column type in the database.

    That being said, all is not lost. I have an email from Reggie Burnett in my inbox and I will be replying to him soon, if all else fails we will enhance our metadata engine to deal with this awkward way of wedging a new datatype into a database via it's data provider alone. In the end, the pressure to get ES2008 released so folks can go live on it took precedence. We do plan to add this in a maintenance release however. We know how important Guids are for doing cross db work and such. Again, my apologies, I really did want to add this for you.

     - Mike
     


    EntitySpaces | Twitter | BLOG | Please honor our Software License
  •  06-12-2008, 5:46 PM 9797 in reply to 9796

    Re: MySQL and real GUID type

    No problem. I agree that it would be best to make this as straight forward and compatible without hacks. I just wanted to follow up. If possible, please give an update after you talk with Reggie from MySQL.

     Thanks

  •  08-02-2008, 6:57 AM 10530 in reply to 9797

    Re: MySQL and real GUID type

    I wanted to see if you could give an update and see if you were you able to contact Reggie Burnett at MySQL.

     

  •  08-10-2008, 7:56 PM 10662 in reply to 10530

    Re: MySQL and real GUID type

    Has there been any luck in getting the MySQL provider working with Guids? Did you get a chance to contact MySQL regarding your suggestion about a real implimentation of a GUID type?

    Thanks

  •  08-24-2008, 8:44 PM 10893 in reply to 10662

    Re: MySQL and real GUID type

    I just wanted to check and see if any changes have been made to ES since the new Meta Engine has been added.

    Also, was Reggie able to provide any more information?

  •  08-25-2008, 5:04 AM 10898 in reply to 10893

    Re: MySQL and real GUID type

    I promise to crack this back open on this maintenance release.

    EntitySpaces | Twitter | BLOG | Please honor our Software License
  •  08-30-2008, 4:49 PM 11048 in reply to 10898

    Re: MySQL and real GUID type

    Well, I'm 4 hours into this tonight and as confused as ever, it does appear a Binary(16) will come back in a DataTable as a Guid (thanks to a specific version of the provider) but it seems like it's to stupid to know how to convert it back for you? There is no MySqlDbType.Guid so you have to store it back as a Binary. So I don't think it can be a true property, ie, you can read it as a Guid but have to set it as a byte[], very confusing, no samples, very suprising that MySql would take this path. Anyway, I'm still on it, but the provide no samples. Sorry, I'm ranting but imagine if microsoft introduced new types through the provider only and you used binary's of different lengths for the datatypes? They wouldn't be taking seriously, ok, ok, I'm shutting up, perhaps tonight something will click?  I'm thinking at this point we might have to treat them as type objects and you'll have to typecast and convert then before set.

    See this guys conversion? http://forums.mysql.com/read.php?38,74352

     


    EntitySpaces | Twitter | BLOG | Please honor our Software License
  •  08-30-2008, 5:43 PM 11049 in reply to 11048

    Re: MySQL and real GUID type

    Okay, here's my progress, after adding a Binary(16) to my employees table and hand tweaking the generated code such that it should have worked, only I receive the message "Data too long for column 'TheGuid' at row 1" and no matter what I tried still the same message. So I tried some stuff with the raw MySQL provider.

    Here is the raw provider code:

     

    Code:
    MySqlConnectionStringBuilder csb = new MySqlConnectionStringBuilder();

    csb.Database = "test";
    csb.UserID = "root";
    csb.Password = "yada";
    csb.Server = "localhost";
    csb.Port = 3306;

    MySqlConnection conn = new MySqlConnection(csb.ToString());

    conn.Open();
    MySqlCommand cmd = new MySqlCommand(@"select * from employees", conn);

    DataTable dt = new DataTable();
    MySqlDataAdapter adapter = new MySqlDataAdapter(cmd);

    try
    {
    adapter.Fill(dt);

    MySqlCommandBuilder bb = new MySql.Data.MySqlClient.MySqlCommandBuilder(adapter);

    MySqlCommand iCmd = bb.GetInsertCommand();

    // Give it a guid value
    dt.Rows[0]["TheGuid"] = Guid.NewGuid();

    adapter.InsertCommand = iCmd;

    adapter.Update(dt);
    }
    catch (Exception ex)
    {
    System.Console.WriteLine(ex.Message);
    }

    conn.Close();

     

    Guess what, I still received the same error message. I check the parameter for my Guid column to in the generated Command received back from the CommandBuilder which is what I really wanted to see, ie, what were the settings. To my suprise the raw MySQL provider code will not work either. At this point I'm not sure MySQL truly supports the guid datatype. The code above normally works on all providers.

    PS: I emailed Reggie through his blog and alerted him to this thread.


    EntitySpaces | Twitter | BLOG | Please honor our Software License
  •  08-31-2008, 10:41 AM 11058 in reply to 11049

    Re: MySQL and real GUID type

    Ok. Lets see what Reggie says. It would be great if they would add a "TRUE" GUID field type.

    When I do research for using GUIDs with MySQL, most suggest using a varchar(38) field type to store the GUID. This was before the provider was to support the binary(16) change . I am wondering what the performance difference (selects, joins) is with MySQL with varchar(38) fields to Binary(16) field type. It seems that Binary(16) is a work around to the issue.

    Thanks 

     

     

View as RSS news feed in XML