[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