Gauthier Segay - 08/Aug/08 03:28 PM I vote for this patch being applied. Note: It would be great to have specific string serialization applied within nh log instead of Byte[], I think the best option would be @p0 = 0xfff... notation so that's easier to check against the DB, I'm unsure if it can be done only for oracle driver?

Michael Hanney - 13/Aug/08 07:36 PM Logging the System.byte[] values would be useful, but like Gauthier said, I do not know if it is possible to test what dialect is in use, or if it is possible to differentiate between the binary value being a guid, or a huge binary object. Nevertheless, the second patch (OracleGuidToRaw16-BytesArrayLogged.patch) also logs the byte[] as 16 hex values using a built in .NET method - SoapHexBinary().ToString(), but only if it is 16 bytes in length. I don't like this much, but it was useful for testing. It would probably NOT be ok to assume the DbType.Binary value is a guid in NHibernate.AdoNet.AbstractBatcher.GetCommandLogString as the DyType.Binary is used for many other types incluing long blobs I believe. Nor would it be ok to echo the entire contents of a DbType.Binary value incase the value is a long blob. If the length of the byte[] == 16, it may be ok to write it to the log. The second patch does this lenght check. I am not sure if it ok to assume the DbType.Binary bytes are Hex values. The patch outputs the byte array values in sequential order using SoapHexBinary().ToString(). The output will match the value stored in the db. If the test GUID is {01234567-abcd-abcd-abcd-0123456789ab} the values in the byte[] and in the raw(16) field in the db will be: 67,45,23,01,CD,AB,CD,AB,AB,CD,01,23,45,67,89,AB because the value was set using Guid.ToByteArray() which returns the Guid bytes in the following order: 3,2,1,0,5,4,7,6,8,9,10,11,12,13,14,15

Fabio Maulo - 07/Sep/08 10:49 PM Taken a decision for this issue after various consideration (and a walk): - Oracle don't support a native Guid type - Somebody, perhaps, want a string type to store the Guid using Oracle - Managing Guid as Raw(16) mean an ugly and dangerous patch in GuidType A good solution for who want this behavior is: - Inherit from Oracle9Dialect and register the Guid as Raw(16) - Create a custom class for OracleGuidType to manage Guid as Raw(16) Probably we can do something in Contrib or you can share this solution in the users wiki of www.nhforge.org The Users wiki area is here http://www.nhforge.org/groups/nhusers/wiki/default.aspx Hope you understand. BTW very thank for the feedback.

Miguel Vale - 08/Sep/08 02:25 AM Hi. Just to say that Oracle has a sys_guid() method that generates RAW(16) Guids. So, for me, Oracle was an native guid type that is RAW(16). I propose a more complex solution that involve support Native Guid generation on NH-1479. Note that now in my system i can change my connection string an my system runs on SQLServer or Oracle without changing anything more. My system use Guids in primary keys with native generation (more secure). Regards, Miguel.