Re: [hibernate-dev] HHH-6044 / HHH-9662 and partial identifier generation - No part of a composite identifier may be null HibernateException
by Jason Pyeron
Turns out this issue may be a duplicate of a known issue, taking this over to the dev list.
org/hibernate/test/annotations/cid/CompositeIdIdentityTest.java:
7 package org.hibernate.test.annotations.cid;
48 @RequiresDialectFeature(DialectChecks.SupportsIdentityColumns.class)
49 @TestForIssue( jiraKey = "HHH-9662" )
50 public class CompositeIdIdentityTest extends BaseCoreFunctionalTestCase {
51
52 @Test
53 @FailureExpected( jiraKey = "HHH-9662" )
54 public void testCompositePkWithIdentity() throws Exception {
55 doInHibernate( this::sessionFactory, session -> {
56 Animal animal = new Animal();
57 animal.setSubId( 123L );
58 session.persist(animal);
59 } );
60 }
61
70 @Entity
71 @Table(name = "animal")
72 @IdClass(IdWithSubId.class)
73 public static class Animal {
74
75 @Id
76 @GeneratedValue(strategy = GenerationType.IDENTITY)
77 private Long id;
78
79 @Id
80 @Column(name = "sub_id")
81 private Long subId;
82
From: Jason Pyeron [mailto:jpyeron@pdinc.us]
Sent: Tuesday, April 21, 2020 1:32 AM
To: 'hibernate-users(a)lists.jboss.org' <hibernate-users(a)lists.jboss.org>
Subject: HHH-6044 and partial identifier generation - No part of a composite identifier may be null HibernateException
[note this is an issue with sequences too]
Quoting https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_...
With non-aggregated composite identifiers, Hibernate also supports "partial" generation of the composite values.
Example 135. @IdClass with partial identifier generation using @GeneratedValue
I seem to be having the same issues as https://hibernate.atlassian.net/browse/HHH-6044
I have existing tables / Entities (simplified):
CREATE TABLE [cresaptown].[saar](
[id] [bigint] IDENTITY(1,1) NOT NULL primary key
);
@Entity
@Table(schema = "cresaptown", name = "saar")
public class SystemAccessAuthorizationRequest
{
@Id
@GeneratedValue
Long id;
}
CREATE TABLE [cresaptown].[signature](
[rid] [bigint] IDENTITY(1,1) NOT NULL,
[sid] [bigint] NOT NULL,
PRIMARY KEY ([rid],[sid]),
FOREIGN KEY([rid]) REFERENCES [cresaptown].[saar] ([id])
);
@Entity
@Table(schema = "cresaptown", name = "signature")
@IdClass(Signature.ID.class)
public class Signature
{
@Id
@Column(name = "sid")
@GeneratedValue
Long sid;
@Id
@JoinColumn(name = "rid")
@ManyToOne
SystemAccessAuthorizationRequest rid;
public static class ID implements Serializable
{
Long sid;
Long rid;
}
}
A code fragment
em.getTransaction().begin();
SystemAccessAuthorizationRequest saar = new SystemAccessAuthorizationRequest();
em.persist(saar);
Signature sig = new Signature();
sig.setRid(saar);
em.persist(sig);
em.getTransaction().commit();
gives this exception, but if I disable the null check in AbstractEntityTuplizer.getIdentifier, I get the same issue as in HHH-6044
javax.persistence.PersistenceException: org.hibernate.HibernateException: No part of a composite identifier may be null
at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:154)
at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:181)
at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:188)
at org.hibernate.internal.SessionImpl.firePersist(SessionImpl.java:716)
at org.hibernate.internal.SessionImpl.persist(SessionImpl.java:696)
at x.Testclass.x(Testclass.java:38)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:89)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:41)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:541)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:763)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:463)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:209)
Caused by: org.hibernate.HibernateException: No part of a composite identifier may be null
at org.hibernate.tuple.entity.AbstractEntityTuplizer$IncrediblySillyJpaMapsIdMappedIdentifierValueMarshaller.getIdentifier(AbstractEntityTuplizer.java:365)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.getIdentifier(AbstractEntityTuplizer.java:219)
at org.hibernate.persister.entity.AbstractEntityPersister.getIdentifier(AbstractEntityPersister.java:5119)
at org.hibernate.persister.entity.AbstractEntityPersister.isTransient(AbstractEntityPersister.java:4819)
at org.hibernate.engine.internal.ForeignKeys.isTransient(ForeignKeys.java:294)
at org.hibernate.event.internal.EntityState.getEntityState(EntityState.java:59)
at org.hibernate.event.internal.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:95)
at org.hibernate.event.internal.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:55)
at org.hibernate.event.service.internal.EventListenerGroupImpl.fireEventOnEachListener(EventListenerGroupImpl.java:102)
at org.hibernate.internal.SessionImpl.firePersist(SessionImpl.java:710)
... 25 more
5 years, 6 months
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
5 years, 6 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
5 years, 6 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
5 years, 6 months
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
>> >>> >
>> >>>
>>
>>
5 years, 6 months
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
5 years, 6 months
