[hibernate-dev] Could UUID be one of the default strategy when AUTO is requested

Emmanuel Bernard emmanuel at hibernate.org
Tue Jan 20 10:33:14 EST 2015


I’ve captured some of it
https://hibernate.atlassian.net/browse/HHH-9577 <https://hibernate.atlassian.net/browse/HHH-9577>

It is probably worth doing two or three issues. Not sure.

> On 20 Jan 2015, at 15:27, Steve Ebersole <steve at hibernate.org> wrote:
> 
> I really like that thought for UUID return.  Not so convinced for String
> return.
> 
> On Mon, Jan 19, 2015 at 3:44 PM, Gail Badner <gbadner at redhat.com> wrote:
> 
>> There are some jiras for using UUIDs (in general, not specifically for
>> IDs) for using a single mapping that would work for different dialects:
>> - https://hibernate.atlassian.net/browse/HHH-9562
>> - https://hibernate.atlassian.net/browse/HHH-9574
>> 
>> It seems that these are related...
>> 
>> ----- Original Message -----
>>> From: "Gunnar Morling" <gunnar at hibernate.org>
>>> To: "Sanne Grinovero" <sanne at hibernate.org>
>>> Cc: "Hibernate Dev" <hibernate-dev at lists.jboss.org>
>>> Sent: Monday, January 19, 2015 8:15:42 AM
>>> Subject: Re: [hibernate-dev] Could UUID be one of the default strategy
>> when AUTO is requested
>>> 
>>> We discussed a while ago whether it should be pluggable how AUTO is
>>> resolved:
>>> 
>> https://lists.jboss.org/pipermail/hibernate-dev/2014-November/011948.html
>>> 
>>> I still think that's a good idea.
>>> 
>>> In the case of OGM, it may even be a bit more complex. For example with
>>> MongoDB the following should result in IDENTITY being used (which is
>> mapped
>>> to store-assigned object ids) rather than UUID:
>>> 
>>>    @Id
>>>    @GeneratedValue(strategy = GenerationType.AUTO)
>>>    @Type(type = "objectid")
>>>    String id;
>>> 
>>> So the @Type would have to be taken into account as well for mapping
>> AUTO.
>>> 
>>>> For String, I wonder if someone would argue that it should actually map
>>> to a string-encoded output of a sequence.. "1", "2" ...
>>> 
>>> I don't think you can use sequences with String (only numeric values), so
>>> anyone having this expectation would also be unhappy as of today.
>>> 
>>> --Gunnar
>>> 
>>> 
>>> 2015-01-19 15:58 GMT+01:00 Sanne Grinovero <sanne at hibernate.org>:
>>> 
>>>> On 19 January 2015 at 13:33, Emmanuel Bernard <emmanuel at hibernate.org>
>>>> wrote:
>>>>> Hey,
>>>>> 
>>>>> I am throwing an idea, let me know what you think.
>>>>> If the return type of the id property of an entity is either String
>> or
>>>> UUID, could we automatically consider one fo the uuid strategy as the
>> one
>>>> matching AUTO?
>>>> 
>>>> +1
>>>> That seems spot-on for the UUID type.
>>>> For String, I wonder if someone would argue that it should actually
>>>> map to a string-encoded output of a sequence.. "1", "2" ...
>>>> I'd personally agree that this is horrible and it should default to
>>>> UUID, just wondering.
>>>> 
>>>> Would this violate any spec?
>>>> 
>>>>> 
>>>>> It would be useful for Hibernate OGM but I am also thinking that it
>>>> makes equal sense to Hibernate ORM users.
>>>>> 
>>>>> Thoughts? I’m sure there are incompatibilities I have not think of.
>>>>> 
>>>>> Emmanuel
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> 
>>>> _______________________________________________
>>>> hibernate-dev mailing list
>>>> hibernate-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>> 
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev



More information about the hibernate-dev mailing list