I am using Hibernate 2.1.6 in conjunction with an old legacy database transferred to HSQLDB for testing purposes. Since all primary keys are strings I found that I have to use either uuid.hex or uuid.string for generating my primary keys. I decided upon uuid.string.

My DAOs use Spring's HibernateTemplate initialized with a singleton SessionFactory, in my test cases I use Spring's TransactionTemplate for associating a transaction with the current session. The code in question is



where tt is Spring's TransactionTemplate. Now if I run this code I get

[code]
net.sf.hibernate.NonUniqueObjectException: a different object with the same identifier value was already associated with the session:

um. this should not be possible

do you get the same thing happening with uuid.hex?

perhaps I have a bug in BytesHelper.toBytes(), I'm not good at bits...

Gavin, thanks for your quick response.



No, indeed uuid.hex does the trick. Have been running the whole slew of test cases several times after switching to uuid.hex. No problems thus far. So thanks for a quick solution.

One hint: the problem with uuid.string is not deterministic, i.e. it might happen that one, two or even more test cases pass before Hibernate chokes on a duplicate identifier.

For what it's worth: I am not good at bits either.

Cheers,

Olaf

OK, so what seems to happen is this:

apparently some byte values map to the same character when I create a string using new String(byte[]) - I was not aware of this! I'm guessing this behavior depends upon the character set.

So even though the array of bytes I am generating is unique, the resulting Strings are not.

Does anyone know anyway to fix this? for example, can I specify a character set where all bytes will map to unique characters?

ok, problem seems to only occur when i pass negative bytes .... so I guess a negative byte value is not a valid character...

You have to be a bit careful with most charsets, the default one will most likely be ASCII so any characters above 255 could end up being similar. One thing I know for sure for Unicode character set is that there is a cutoff ( somewhere around 55K ) where all byte values above that map to the same character. This is supposed to be where the really exotic languages that have a lot of different characters.

Well, I rully expected that some byte values would not have unique *glyphs* - what I was not expecting was that when converting to a String, some of the actual information would be thrown away. ie. new String(bytes).getBytes() is destructive. I had assumed you would just get stuf converted to some chars that may of may not have corresponding glyphs in the current character set.

Sorry didn't explain myself very well.

nvarchar ( SQLServer and Oracle ) exhibit the cutoff behaviour. If you put any char/byte value in above the cutoff it goes into the database and comes out as the cutoff value. All values above this point do this for nvarchar columns. I have a brute force test for unicode on our databases that just builds strings containing everything possible character value and save()/get() each one. What goes in matches what comes out up until the 55K ish point so maybe it is something to do with this?

ah, that would be bad too. though i think the immediate problem i'm observing happens purely in memory


I think we should probably get rid of uuid.string - does anyone use it? I'm guessing the answer is "no".

LOL, funny that you mention that as we were planning on using it to generate some unique values for Workspace names for Oracle Workspace Manager. It goes into a table under Oracle's control and the field is < 32 chars so we couldn't use the Hex generator.

But it is interesting to know that the string one doesn't work :(