Re: [hibernate-dev] HHH-11699 Hibernate ignores 'schema' attribute of @SequenceGenerator for Oracle --- and SQL Server --- sequences
by Jason Pyeron
Sorry, accidentally sent to Andrea and not the list.
From: Jason Pyeron [mailto:jpyeron@pdinc.us]
Sent: Tuesday, April 21, 2020 8:56 AM
To: 'andrea boriero' <andrea(a)hibernate.org>
Subject: RE: [hibernate-dev] HHH-11699 Hibernate ignores 'schema' attribute of @SequenceGenerator for Oracle --- and SQL Server --- sequences
That then conflicts with HHH-13939.
Either way, no joy. Lastly, it should not have an effect on definitions like:
@Id
@Column(name = "sid")
@GeneratedValue(generator = "SIGNATURE", strategy = GenerationType.SEQUENCE)
@SequenceGenerator(name = "SIGNATURE", schema = "cresaptown", sequenceName = "signature_seq")
Long sid;
-Jason
From: andrea boriero [mailto:andrea@hibernate.org]
Sent: Tuesday, April 21, 2020 3:07 AM
To: Jason Pyeron <jpyeron(a)pdinc.us <mailto:jpyeron@pdinc.us> >
Subject: Re: [hibernate-dev] HHH-11699 Hibernate ignores 'schema' attribute of @SequenceGenerator for Oracle --- and SQL Server --- sequences
Hi Jason,
in the Jira I explained that the issue seems related to Spring setting the `hibernate.id.new_generator_mappings` value to false.
Have you tried to explicitly change this value to true?
Cheers,
Andrea
On Tue, 21 Apr 2020 at 03:57, Jason Pyeron <jpyeron(a)pdinc.us <mailto:jpyeron@pdinc.us> > wrote:
The issue is impacting current releases for both schema generation and runtime use.
I do not have permissions to update the title/summary.
-Jason
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
3 years, 12 months
Migration to Jakarta API: some practical aspects in dealing with Git and mass replacements
by Sanne Grinovero
Hi all,
the migration to the Jakarta API is rather simple and can be performed
by "find and replace" operations, but it will affect a lot of code and
might get int the way of other work.
To keep things simple and avoid tedious, massive conflict resolutions
for all of us who are having "work in progress" somewhere in branches,
open pull requests, and local work in progress which didn't make it to
pull requests yet, I would suggest to not blindly merge/rebase changes
from master, but take a little special care while this process is
ongoing.
For example, I just pushed the update to Hibernate Validator 7
[HHH-13950], which is done
via the following two commits:
1 - https://github.com/hibernate/hibernate-orm/commit/b9a24f458c6e9c5331b2362...
2 - https://github.com/hibernate/hibernate-orm/commit/60abc8aa764929920478888...
Please note I'm using the commit description space to make notes about
how to port these commits.
I hope this helps; on top of single scripts for the individual
commits, when I'm done I'll also share a "one shot" script which could
be useful to process patches, so to have them apply cleanly for all
the unmerged work in progress we might have around.
Thanks,
Sanne
3 years, 12 months
https://hibernate.atlassian.net/browse/HHH-9798 Unique constraint / not null of @JoinTable for @OneToOne not generated
by Jason Pyeron
I think I have found another corner case on the https://hibernate.atlassian.net/browse/HHH-9798 regression.
The cited example is:
@OneToOne(fetch = FetchType.LAZY)
@JoinTable(
name = "ITEM_SHIPMENT", // Required!
joinColumns =
@JoinColumn(name = "SHIPMENT_ID"), // Defaults to ID
inverseJoinColumns =
@JoinColumn(name = "ITEM_ID", // Defaults to AUCTION_ID
nullable = false,
unique = true)
)
protected Item auction;
but an equally similar case ought to be:
@OneToOne(fetch = FetchType.LAZY)
@JoinTable(
name = "ITEM_SHIPMENT", // Required!
)
protected Item auction;
The rationale here is that a @JoinTable is used to “not have the null rows” that would be present if a @JoinColumn was to be used on an @OneToOne(optional=true). I cannot find in the spec where this is implied, required, or excluded.
Otherwise one would have to say:
@OneToOne(fetch = FetchType.LAZY)
@JoinTable(
name = "ITEM_SHIPMENT", // Required!
inverseJoinColumns =
@JoinColumn(nullable = false,
unique = true)
)
protected Item auction;
Thoughts?
-Jason
4 years
Re: [hibernate-dev] HHH-13916 / WFLY-13259
by Gail Badner
Hi Galder,
Thanks for the response. I agree this would be a good change for H6. I'm
happy to hear that this is on someone's radar for Infinispan.
Sanne, regarding:
> I'd say if you clearly mark the old method deprecated (or even remove
it?) it
will be guaranteed we don't forget about this improvement.
Are you suggesting that
SharedSessionContractImplementor#getSessionIdentifier be deprecated?
If so, it has other uses, so it really can't be deprecated.
I've moved the fix version for HHH-13916 to 6.0.0.Beta1 and created a
wip/6.0 PR: https://github.com/hibernate/hibernate-orm/pull/3341 .
Regards,
Gail
On Wed, Apr 15, 2020 at 7:58 AM Galder Zamarreno <galder(a)redhat.com> wrote:
> Given that there's a workaround for the issue, I'd agree with Sanne to
> make this an ORM 6+ only improvement.
>
> Indeed I'm no longer in the team and hence could not be the maintainer for
> such a module, but I'd be happy to discuss improvements for ORM6 caching.
> I've not been aware of any discussions on that yet.
>
> On the Infinispan side, just a couple of weeks back Tristan was asking me
> about the need for a remote Infinispan cache provider for ORM. Maybe ORM6
> offers a good opportunity to rework the provider and make it easy to
> maintain a local/remote provider.
>
> Galder
>
>
> On Wed, Apr 15, 2020 at 1:42 PM Sanne Grinovero <sanne(a)hibernate.org>
> wrote:
>
>> On Wed, 15 Apr 2020 at 02:16, Gail Badner <gbadner(a)redhat.com> wrote:
>> >
>> > FWIW, there's no point in fixing HHH-13916 unless we hear that
>> Infinispan is going to use the fix.
>>
>> I suppose we can expect that that will eventually happen - I just
>> don't know when and were to best make a note of such a need? I'd say
>> if you clearly mark the old method deprecated (or even remove it?) it
>> will be guaranteed we don't forget about this improvement.
>>
>> As far as I know, there isn't an Infinispan 2LC codebase for ORM6 yet,
>> and there will be more differences likely?
>>
>> Also keep in mind that Galder no longer works on Infinispan, he's now
>> focused on GraalVM and JDK engineering. I'm glad he's still around and
>> we might be able to bother him for suggestions and wisdom, but I'm not
>> sure yet who's going to be responsible to create such a new module.
>> Radim is on the performance team; as always, would be awesome to have
>> his help but I don't know of the performance team will be able to own
>> the module maintenance.
>>
>> Thanks,
>> Sanne
>>
>>
>> >
>> > Radim/Galder, WDYT?
>> >
>> > Thanks,
>> > Gail
>> >
>> > On Tue, Apr 14, 2020 at 3:25 PM Gail Badner <gbadner(a)redhat.com> wrote:
>> >>
>> >> Hi Sanne,
>> >>
>> >> I've reworked HHH-13916 to use this alternative, and set the fix
>> version to 6-wishlist.
>> >>
>> >> Regards,
>> >> Gail
>> >>
>> >> On Tue, Apr 14, 2020 at 1:23 AM Sanne Grinovero <sanne(a)hibernate.org>
>> wrote:
>> >>>
>> >>> Hi Gail,
>> >>>
>> >>> I would go ahead with this improvement for ORM 6 and avoid spending
>> >>> your precious time on a v5 improvement - especially if it's going to
>> >>> require coordination with both the Infinispan and WildFly teams.
>> >>>
>> >>> Thanks
>> >>>
>> >>> On Fri, 10 Apr 2020 at 00:56, Gail Badner <gbadner(a)redhat.com> wrote:
>> >>> >
>> >>> > I've been looking into how to fix this issue:
>> >>> >
>> >>> > https://hibernate.atlassian.net/browse/HHH-13916
>> >>> > https://issues.redhat.com/browse/WFLY-13259
>> >>> >
>> >>> > The crux of the matter is when Hibernate calls
>> CacheHelper.fromSharedCache(
>> >>> > session, cacheKey, cachAccess ), and the entity is not found in the
>> cache,
>> >>> > Infinispan stores a PendingPut containing a
>> >>> > SharedSessionContractImplementor instance.
>> >>> >
>> >>> > IIUC, as an optimization, Infinispan assumes that the entity not
>> found in
>> >>> > the cache will ultimately be added to the cache after it is loaded
>> from the
>> >>> > database. If that doesn't happen, the PendingPut will expire and
>> will
>> >>> > eventually be removed. Until it expires,
>> >>> > the SharedSessionContractImplementor instance cannot be
>> garbage-collected.
>> >>> >
>> >>> > This is particularly a problem if the cache is not disabled while a
>> large
>> >>> > amount of cacheable data is being imported. This is the particular
>> use case
>> >>> > described by WFLY-13259. There is a reproducer attached that
>> >>> > throws OutOfMemoryError.
>> >>> >
>> >>> > The obvious workaround is to set org.hibernate.CacheMode.IGNORE (or
>> >>> > possibly CacheMode.PUT?) while importing data.
>> >>> >
>> >>> > I discussed this briefly with Sanne, and we agree that an
>> improvement would
>> >>> > be to not store a SharedSessionContractImplementor in a PendingPut
>> at all.
>> >>> >
>> >>> > There is already a way to get a UUID for the session by calling
>> >>> > SharedSessionContractImplementor#getSessionIdentifier().
>> Unfortunately, the
>> >>> > implementation in AbstractSharedSessionContract indicates that
>> frequent
>> >>> > "UUID generations will cause a significant amount of contention".
>> >>> >
>> >>> > Sanne has suggested returning a "token" that is just a new Object.
>> I've
>> >>> > created a branch
>> >>> > <https://github.com/gbadner/hibernate-core/tree/HHH-13916_token>
>> [1] that
>> >>> > does this.
>> >>> >
>> >>> > Infinispan would need to be updated so that PendingPut#owner is set
>> >>> > to SharedSessionContractImplementor#getSessionToken() (instead of
>> >>> > the SharedSessionContractImplementor object).
>> >>> >
>> >>> > Looking at the Infinispan code, I see that code that would be
>> affected is
>> >>> > in
>> >>> > org.infinispan.hibernate.cache.commons.access.PutFromLoadValidator,
>> which
>> >>> > is used by infinispan-hibernate-cache-v51.
>> >>> >
>> >>> > IIUC, in order to fix this any time soon for WildFly or EAP 7.x,
>> [1] would
>> >>> > have to be backported to both Hibernate ORM 5.1 and 5.3 branches,
>> and the
>> >>> > Hibernate versions would have to be updated in Infinispan before
>> Infinispan
>> >>> > could be updated to use
>> SharedSessionContractImplementor#getSessionToken().
>> >>> >
>> >>> > Galder/Radim, are there any plans for
>> >>> > dropping infinispan-hibernate-cache-v51?
>> >>> >
>> >>> > Are there other places where the SharedSessionContractImplementor
>> is stored
>> >>> > in the cache?
>> >>> >
>> >>> > Aside from infinispan-hibernate-cache-v51, do you see anything
>> about [1]
>> >>> > that would cause problems?
>> >>> >
>> >>> > If not, when do you think we could coordinate this change? Do we
>> need to
>> >>> > wait for Hibernate ORM 6.0?
>> >>> >
>> >>> > This is considered an improvement, so it's not urgent. It would be
>> nice to
>> >>> > fix this though.
>> >>> >
>> >>> > Galder/Radim, please provide your input so we figure out when it
>> can be
>> >>> > fixed.
>> >>> >
>> >>> > Thanks,
>> >>> > Gail
>> >>> >
>> >>> > [1] https://github.com/gbadner/hibernate-core/tree/HHH-13916_token
>> >>> > [2]
>> >>> > _______________________________________________
>> >>> > hibernate-dev mailing list
>> >>> > hibernate-dev(a)lists.jboss.org
>> >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>> >
>> >>>
>>
>>
4 years
Remove or disable the WildFly feature packs of Hibernate ORM?
by Sanne Grinovero
As we're working to upgrade to Jakarta EE 9, our feature packs for
Wildfly are not going to be functional for a while at least.
Not only do we have to upgrade to JPA 3, but we also need to upgrade
our integrations with a different Validator, a different CDI - none of
these are provided by WildFly yet.
I see several options:
A] I could disable the feature pack generation and its integration tests.
B] Keep generating and releasing a knowingly broken feature pack,
disable its integration tests, document this is work in progress.
C] Delete all this stuff
Frankly it's tempting to just delete it all: WildFly has switched to a
new model which replaces the "feature pack" notion we have, so even if
Wildfly were to provide an Jakarta EE 9 build for us to run
integration tests sometimes soon I'm sadly quite certain that we'll
have to rethink how these packs are generated, and if it's still worth
for us doing this.
Any thoughts?
Thanks,
Sanne
4 years
HHH-13916 / WFLY-13259
by Gail Badner
I've been looking into how to fix this issue:
https://hibernate.atlassian.net/browse/HHH-13916
https://issues.redhat.com/browse/WFLY-13259
The crux of the matter is when Hibernate calls CacheHelper.fromSharedCache(
session, cacheKey, cachAccess ), and the entity is not found in the cache,
Infinispan stores a PendingPut containing a
SharedSessionContractImplementor instance.
IIUC, as an optimization, Infinispan assumes that the entity not found in
the cache will ultimately be added to the cache after it is loaded from the
database. If that doesn't happen, the PendingPut will expire and will
eventually be removed. Until it expires,
the SharedSessionContractImplementor instance cannot be garbage-collected.
This is particularly a problem if the cache is not disabled while a large
amount of cacheable data is being imported. This is the particular use case
described by WFLY-13259. There is a reproducer attached that
throws OutOfMemoryError.
The obvious workaround is to set org.hibernate.CacheMode.IGNORE (or
possibly CacheMode.PUT?) while importing data.
I discussed this briefly with Sanne, and we agree that an improvement would
be to not store a SharedSessionContractImplementor in a PendingPut at all.
There is already a way to get a UUID for the session by calling
SharedSessionContractImplementor#getSessionIdentifier(). Unfortunately, the
implementation in AbstractSharedSessionContract indicates that frequent
"UUID generations will cause a significant amount of contention".
Sanne has suggested returning a "token" that is just a new Object. I've
created a branch
<https://github.com/gbadner/hibernate-core/tree/HHH-13916_token> [1] that
does this.
Infinispan would need to be updated so that PendingPut#owner is set
to SharedSessionContractImplementor#getSessionToken() (instead of
the SharedSessionContractImplementor object).
Looking at the Infinispan code, I see that code that would be affected is
in
org.infinispan.hibernate.cache.commons.access.PutFromLoadValidator, which
is used by infinispan-hibernate-cache-v51.
IIUC, in order to fix this any time soon for WildFly or EAP 7.x, [1] would
have to be backported to both Hibernate ORM 5.1 and 5.3 branches, and the
Hibernate versions would have to be updated in Infinispan before Infinispan
could be updated to use SharedSessionContractImplementor#getSessionToken().
Galder/Radim, are there any plans for
dropping infinispan-hibernate-cache-v51?
Are there other places where the SharedSessionContractImplementor is stored
in the cache?
Aside from infinispan-hibernate-cache-v51, do you see anything about [1]
that would cause problems?
If not, when do you think we could coordinate this change? Do we need to
wait for Hibernate ORM 6.0?
This is considered an improvement, so it's not urgent. It would be nice to
fix this though.
Galder/Radim, please provide your input so we figure out when it can be
fixed.
Thanks,
Gail
[1] https://github.com/gbadner/hibernate-core/tree/HHH-13916_token
[2]
4 years
