Server_1 | .exc.InvalidDefinitionException: No serializer found for class .bytebuddy.ByteBuddyInterceptor and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: com.uuid_1.UserProfile$HibernateProxy$Ixbdxk4D) : rvice() for servlet in context with path threw exception nested exception is .exc.InvalidDefinitionException: No serializer found for class .bytebuddy.ByteBuddyInterceptor and no properties discovered to create BeanSerializer (to avoid exception, disable SerializationFeature.FAIL_ON_EMPTY_BEANS) (through reference chain: com.uuid_1.UserProfile$HibernateProxy$Ixbdxk4D)] with root cause So you might consider using an auto-increment sequence or something for the primary key - DB will be able to do it and you won't need to bother.Hibernate: select userprofil0_.id as id1_0_0_, userprofil0_.display_name as display_2_0_0_ from user_profile userprofil0_ where userprofil0_.id=? In general, using the UUID is not always a good idea - it's hard to deal with them in day-to-day life, and in general they introduce an overhead that might be significant if there are many rows in the table. For example, Postgresql allows generating UUID keys with the help of extension: You haven't specified which database do you use. Of course, the best approach would be to let the DB deal with the ID generation. Value = "id", updatable = false, nullable = false)įor more information read here for example Well, Hibernate is able to generate the UUID in a way that also uses an IP of the machine as a parameter of generation: class SampleEntity = "UUID", Now the real question is whether there is something else that can be done here? If your system can deal with collision (re-create a UUID for example, assuming that performance penalty is negligible because this will happen in extremely rare cases) then no problem of course. I'm not a hibernate specialist, however, if you do it like this, in general, it should be kind of ok, which means that the probability of collision is low, however "what if" there is a collision? In other words, you can't be 100% sure that you're "guaranteed to avoid collision".
#Generate uuid java spring boot code
Not because of collisions from randomly-generated duplicates, but because of collision from the all-too-human possibilities such as a bug in your code that double-posts the record to database, or a DBA who mistakenly loads back-up data twice, and so on. Either way, Version 1 or Version 4, I would sleep well.ĭespite saying the above, you should still ensure that your code is written to be robust in the face of collisions.
Personally, I consider the point-in-space-and-time versions such as Version 1 to be even less of a concern for collisions.
(See valid rant by Linus Torvalds on the issue.) Top in my mind: Cosmic rays flipping bits in non- EEC memory. If you want to worry, apply your worry to things that are much more likely to happen.
Assuming your UUID is being generated with a cryptographically-strong random number generator, you have no practical concerns with using a randomly-generated UUID.įor details, see the Collisions section on Wikipedia.
My doubt is this: Is this approach safe? Can I be sure ids will always be unique?Ī UUID Version 4 has 122 bits of randomly generated data.
0 kommentar(er)
