When using H2 I've no problems with attributes like this:
However, after switching to MySQL, I observed the following:
The generated column type is BINARY(255)
The generated WHERE clause for EntityManager.find(Class, UUID) is, e.g.:
WHERE id = '12345678-1234-1234-1234-123456789012' instead of
WHERE id = '12345678123412341234123456789012', i.e. without -
I also tried to replace Hibernate 5.0.7 inside WildFly by 5.1.0 and 5.0.8, but got the same issue.
UUIDBinaryType is the default mapping for UUID attributes (UUID->BINARY). So I would assume that the dialects for both H2 and MySQL pick that up (pgsql dialects e.g. map UUID differently). Is that what you see?
To be honest I am surprised that this happens with find as described. In fact I am not sure I believe that. I guess you probably mean that you see: WHERE id=? and then binding the UUID value with dashes. But even that I am surprised by. We'd simply bind the UUID as binary data. Maybe you are confusing the logging for what actually gets sent to database? I.e.:
For what it is worth that logging comes from a test that uses exactly the mapping you claim "fails", but the test is perfectly fine. Granted it uses H2 as the back end, but I simply do not see the fundamental difference using MySQL here. Maybe the BINARY(255) comes into play, but that would simply cause no matching I would think if anything.
So assuming you do see an actual failure, I am going to need a test showing that. The test I used is org.hibernate.test.id.uuid.interpretation.UUIDBasedIdInterpretationTest. The output is:
Which looks perfect.