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