3:14 p.m.
I just noticed that the ORM testsuite seems to consistently set this
option to "true".
The default being false, the "new" kind is available since ORM 3.2
according to javadoc.
Would this be a good time to switch the default?
5:55 p.m.
The problem is legacy databases and how to help users migrate the id
generation strategies. Or are you thinking that existing users would have
to disable this on upgrade?
On Fri, May 15, 2015 at 3:14 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
I just noticed that the ORM testsuite seems to consistently set this
option to "true".
The default being false, the "new" kind is available since ORM 3.2
according to javadoc.
Would this be a good time to switch the default?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
9:16 a.m.
On 15 May 2015 at 23:55, Steve Ebersole <steve(a)hibernate.org> wrote:
The problem is legacy databases and how to help users migrate the id
generation strategies. Or are you thinking that existing users would have
to disable this on upgrade?
I would expect that yes. Or is there no reasonable benefit in using
the new ones?
It's a tradeoff which I can't judge, I just pointed it out as it
seemed a forgotten detail.
-- Sanne
On Fri, May 15, 2015 at 3:14 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
>
> I just noticed that the ORM testsuite seems to consistently set this
> option to "true".
>
> The default being false, the "new" kind is available since ORM 3.2
> according to javadoc.
>
> Would this be a good time to switch the default?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:02 p.m.
From a performance and maintainability perspective I think there is a
big
win in moving to the new generators. But the problem is people migrating
and the change in expectations. 2 specific examples:
1) User migrating where the legacy code picked "identity" generation. The
new code would pick "sequence style" generation. How do these users
migrate or update their schemas? I am pretty sure our schema update tool
does not support de-IDENTITY-fying columns. In fact I don't even know how
to do that in any db, let along in any kind of standard way.
2) Users migrating where the legacy code picked any of the "hilo"
generations. The new code would pick "sequence style" generation. Here
the problem is the values stored in the sequence/id-table versus how those
are translated to id values stored in the entity tables. How would users
migrate those values?
On Sat, May 16, 2015 at 9:16 AM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
On 15 May 2015 at 23:55, Steve Ebersole <steve(a)hibernate.org>
wrote:
> The problem is legacy databases and how to help users migrate the id
> generation strategies. Or are you thinking that existing users would
have
> to disable this on upgrade?
I would expect that yes. Or is there no reasonable benefit in using
the new ones?
It's a tradeoff which I can't judge, I just pointed it out as it
seemed a forgotten detail.
-- Sanne
>
> On Fri, May 15, 2015 at 3:14 PM, Sanne Grinovero <sanne(a)hibernate.org>
> wrote:
>>
>> I just noticed that the ORM testsuite seems to consistently set this
>> option to "true".
>>
>> The default being false, the "new" kind is available since ORM 3.2
>> according to javadoc.
>>
>> Would this be a good time to switch the default?
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3265
days inactive
3266
days old
3 comments
2 participants
participants (2)
-
Sanne Grinovero -
Steve Ebersole