score:0

With the generator, you specified you generate UUIDs on the application side and send them to the database where they are stored in an efficient format which most certainly doesn't include any information about upper and lower case because it is just a number.

I suspect the difference you see in your selects probably comes from the Session cache and doesn't really have much to do with the method you use: If the entity is found in the cache it get's returned and if it was just saved it contains the UUID in the format the Hibernator generated it (so upper-lower case depends on a toString() method in Hibernate).

If the entity is not found in the cache it is returned as it comes from the database which most likely depends on an implementation detail in the JDBC driver you use.

So how to fix this:

The easy way: Use guid as the generator. It will hit the database so the UUID will always be in the format provided by the database. If performance is critical this is probably not a viable option. Note: I couldn't find this generator in the current documentation, no idea if it is deprecated or something.

The hard way: Find or create a UUID generator that creates the UUIDs in the exact format that is returned by the database.

There seems to be a surprising amount of wiggle room for the generation of UUIDs so here is a list of links for further reading:

Vlad Mihalcea about UUIDs: https://vladmihalcea.com/hibernate-and-uuid-identifiers/

A somewhat similar issue: Different representation of UUID in Java Hibernate and SQL Server

The current version of the Hibernate documentation about UUID.

score:0

Why not just convert all the strings to the same case (which doesn't matter) before comparing them?

Still, this doesn't seem ideal; comparing two strings that are 36 characters long is going to take more time (and handling them will take more space) than 16-byte numbers, and since the database is (you hope) storing them as binary, you have the extra cost of conversions to that less efficient form. Oh, and the string comparison will be slower even for the same number of bytes because it doesn't know they're fixed length, it it probably has to compare a byte at a time rather than using wider compares.


More questions

More questions with similar tag