[hibernate-dev] Hibernate ORM 5.3.23.Final Released

[Gail Badner]

https://in.relation.to/2021/09/29/hibernate-orm-5323-final-out/
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Re: FetchMode.SELECT

[Gail Badner]

OK, thanks for the feedback! I've created HHH-14405
<https://hibernate.atlassian.net/browse/HHH-14405> for fixing the
documentation.

I've set the fix version for both HHH-14390
<https://hibernate.atlassian.net/browse/HHH-14390> and HHH-14405
<https://hibernate.atlassian.net/browse/HHH-14405> to 5.4-backlog.

Thanks,
Gail

On Wed, Jan 13, 2021 at 2:12 AM Sanne Grinovero  wrote:

> On Tue, 12 Jan 2021 at 08:31, andrea boriero  wrote:
> >
> > I agree with Christian, the FetchMode should only influence the how and
> not
> > the when of a fetch.
> >
> > If the association is EAGER and annotated with FetchMode.SELECT then it
> > should be loaded immediately using a secondary select.
>
> +1
>
> How and when to load express different needs and can be valid in
> various combinations.
>
> A use case is that one might explicitly want a separate loading event,
> for example to simplify the generated SQL or to make better use of the
> 2LC.
>
> One might still want it EAGERly loaded, so to prepare an object graph
> for detached processing.
>
> >
> > On Thu, 7 Jan 2021 at 10:31, Christian Beikov <
> christian.bei...@gmail.com>
> > wrote:
> >
> > > I agree that this should be supported. Specifying a fetch mode should
> > > IMO not change the fetch type to LAZY or EAGER.
> > >
> > > Am 06.01.2021 um 04:50 schrieb Gail Badner:
> > > > Should it be possible to force an eager association to be loaded by a
> > > > separate query using @Fetch(FetchMode.SELECT)?
> > > >
> > > > I thought that Hibernate supported that for an EAGER association,
> but I
> > > see
> > > > the documentation for FetchMode.SELECT
> > > > <
> > >
> https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#fetching-fetch-annotation
> > > >
> > > > says:
> > > >
> > > > "SELECT
> > > > The association is going to be fetched lazily using a secondary
> select
> > > for
> > > > each individual entity, collection, or join load. It’s equivalent to
> > > > JPA FetchType.LAZY fetching strategy."
> > > >
> > > > The reason I ask is because I am trying to wrap up HHH-13085, which
> will
> > > > change derived IDs mapped as a one-to-one association, currently
> loaded
> > > by
> > > > a separate query, to instead be loaded in the same query that loads
> the
> > > > dependent entity. I want to ensure that it is possible to revert
> back to
> > > > loading that one-to-one association in a separate query after
> HHH-13085
> > > is
> > > > fixed.
> > > >
> > > > Currently, a StackOverflowError is thrown when loading an entity
> with an
> > > ID
> > > > that is an bidirectional eager one-to-one association has
> > > FetchMode.SELECT
> > > > mapped.
> > > >
> > > > @Entity(name = "Foo")public class Foo implements Serializable {
> > > >
> > > >  @Id
> > > >  @GeneratedValue
> > > >  private Long id;
> > > >
> > > >  @OneToOne(mappedBy = "foo", cascade = CascadeType.ALL)
> > > >  private Bar bar;
> > > > }
> > > >
> > > > @Entity(name = "Bar")public class Bar implements Serializable {
> > > > @Id
> > > >  @OneToOne(fetch = FetchType.EAGER)
> > > >  @Fetch(FetchMode.SELECT)
> > > >  @JoinColumn(name = "BAR_ID")
> > > >  private Foo foo;
> > > > }
> > > >
> > > >
> > > > According to the documentation, it sounds like
> @Fetch(FetchMode.SELECT)
> > > > should make the association lazy. Is that really correct?
> > > >
> > > > Could someone please clarify the expected behavior?
> > > >
> > > > I created HHH-14390 <
> https://hibernate.atlassian.net/browse/HHH-14390>
> > > for
> > > > the StackOverflowError. I've pushed some FailureExpected tests
> > > > <
> > >
> https://github.com/hibernate/hibernate-orm/commit/b40d1251e385a5fdb018f9583a83c472d6da4e8f
> > > >
> > > > that reproduce this issue.
> > > >
> > > > Thanks,
> > > > Gail
> > > > ___
> > > > hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
> &

[hibernate-dev] FetchMode.SELECT

[Gail Badner]

Should it be possible to force an eager association to be loaded by a
separate query using @Fetch(FetchMode.SELECT)?

I thought that Hibernate supported that for an EAGER association, but I see
the documentation for FetchMode.SELECT

says:

"SELECT
The association is going to be fetched lazily using a secondary select for
each individual entity, collection, or join load. It’s equivalent to
JPA FetchType.LAZY fetching strategy."

The reason I ask is because I am trying to wrap up HHH-13085, which will
change derived IDs mapped as a one-to-one association, currently loaded by
a separate query, to instead be loaded in the same query that loads the
dependent entity. I want to ensure that it is possible to revert back to
loading that one-to-one association in a separate query after HHH-13085 is
fixed.

Currently, a StackOverflowError is thrown when loading an entity with an ID
that is an bidirectional eager one-to-one association has FetchMode.SELECT
mapped.

@Entity(name = "Foo")public class Foo implements Serializable {

@Id
@GeneratedValue
private Long id;

@OneToOne(mappedBy = "foo", cascade = CascadeType.ALL)
private Bar bar;
}

@Entity(name = "Bar")public class Bar implements Serializable {
@Id
@OneToOne(fetch = FetchType.EAGER)
@Fetch(FetchMode.SELECT)
@JoinColumn(name = "BAR_ID")
private Foo foo;
}


According to the documentation, it sounds like @Fetch(FetchMode.SELECT)
should make the association lazy. Is that really correct?

Could someone please clarify the expected behavior?

I created HHH-14390  for
the StackOverflowError. I've pushed some FailureExpected tests

that reproduce this issue.

Thanks,
Gail
___
hibernate-dev mailing list -- hibernate-dev@lists.jboss.org
To unsubscribe send an email to hibernate-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[hibernate-dev] Hibernate ORM 5.3.18.Final Released

[Gail Badner]

https://in.relation.to/2020/08/05/hibernate-orm-5318-final-out/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Starting release process for ORM 5.3.18

[Gail Badner]

Please don't push anything to 5.3 branch...

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Can a transient attribute be overridden to be persistent in a subclass?

[Gail Badner]

Thanks, Andrea.

I've created https://hibernate.atlassian.net/browse/HHH-14103.

Since you already see the mapping above, I'll assume you don't need to
review the test case before pushing upstream.

Regards,
Gail

On Thu, Jul 9, 2020 at 10:09 AM andrea boriero  wrote:

> Hi Gail,
>
> based on my understanding of Section 2.2  it seems that it should not be
> portable, but I think that it would be nice for Hibernate to support the
> feature.
>
> On Thu, 9 Jul 2020 at 17:40, Gail Badner  wrote:
>
>> Hi Christian,
>>
>> It actually does work already.
>>
>> I was just trying to get answers to the questions at the end of my email.
>>
>> > Would overriding a transient attribute be portable? If not, is that
>> something Hibernate would/should support?
>>
>> If the answer is "yes" to either of those, I'll add a test case to the
>> test
>> suite.
>>
>> Thanks,
>> Gail
>>
>> On Thu, Jul 9, 2020 at 12:47 AM Christian Beikov <
>> christian.bei...@gmail.com>
>> wrote:
>>
>> > I agree, this should work. Do you have a JIRA ticket describing what the
>> > problem is?
>> >
>> > Am 09.07.2020 um 02:42 schrieb Gail Badner:
>> > > I *think* the following is valid, but I need confirmation. This
>> mapping
>> > > does seem to work for Hibernate.
>> > >
>> > > A transient attribute, Employee#title, gets overridden as a persistent
>> > > attribute, Editor#title, stored in a column named "e_title".
>> > >
>> > > Writer#title is also transient, but Writer#group uses the same
>> "e_title"
>> > > column as a foreign key. That foreign key value is used to populate
>> > > Writer#title.
>> > >
>> > > @Entity
>> > > @Table(name="Employee")
>> > > @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
>> > > @DiscriminatorColumn(name="department")
>> > > public abstract class Employee {
>> > >  private String name;
>> > >  private String title;
>> > >
>> > >  @Id
>> > >  public String getName() {
>> > >  return name;
>> > >  }
>> > >
>> > >  @Transient
>> > >  public String getTitle() {
>> > >  return title;
>> > >  }
>> > >
>> > >  protected void setName(String name) {
>> > >  this.name = name;
>> > >  }
>> > >
>> > >  protected void setTitle(String title) {
>> > >  this.title = title;
>> > >  }
>> > > }
>> > >
>> > > @Entity
>> > > public class Editor extends Employee {
>> > >  @Column(name = "e_title")
>> > >  public String getTitle() {
>> > >  return super.getTitle();
>> > >  }
>> > >
>> > >  public void setTitle(String title) {
>> > >  super.setTitle( title );
>> > >  }
>> > > }
>> > >
>> > > @Entity
>> > > public class Writer extends Employee {
>> > >  private Group group;
>> > >
>> > >  @ManyToOne(optional = false)
>> > >  @JoinColumn(name = "e_title")
>> > >  public Group getGroup() {
>> > >  return group;
>> > >  }
>> > >
>> > >  public void setGroup(Group group) {
>> > >  this.group = group;
>> > >  setTitle( group.getName() );
>> > >  }
>> > > }
>> > >
>> > > In 4.2, the above mapping worked with Employee#title being persistent,
>> > but
>> > > does not work in 5.3.
>> > >
>> > > Section 2.2 Persistent Fields and Properties of the spec says:
>> > >
>> > > "Entity subclasses may override the property accessor methods.
>> However,
>> > > portable applications must not override the object/relational mapping
>> > > metadata that applies to the persistent fields or properties of entity
>> > > superclasses."
>> > >
>> > > Would overriding a transient attribute be portable? If not, is that
>> > > something Hibernate would/should support?
>> > >
>> > > Thanks,
>> > > Gail
>> > > ___
>> > > hibernate-dev mailing list
>> > > hibernate-dev@lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Can a transient attribute be overridden to be persistent in a subclass?

[Gail Badner]

Hi Christian,

It actually does work already.

I was just trying to get answers to the questions at the end of my email.

> Would overriding a transient attribute be portable? If not, is that
something Hibernate would/should support?

If the answer is "yes" to either of those, I'll add a test case to the test
suite.

Thanks,
Gail

On Thu, Jul 9, 2020 at 12:47 AM Christian Beikov 
wrote:

> I agree, this should work. Do you have a JIRA ticket describing what the
> problem is?
>
> Am 09.07.2020 um 02:42 schrieb Gail Badner:
> > I *think* the following is valid, but I need confirmation. This mapping
> > does seem to work for Hibernate.
> >
> > A transient attribute, Employee#title, gets overridden as a persistent
> > attribute, Editor#title, stored in a column named "e_title".
> >
> > Writer#title is also transient, but Writer#group uses the same "e_title"
> > column as a foreign key. That foreign key value is used to populate
> > Writer#title.
> >
> > @Entity
> > @Table(name="Employee")
> > @Inheritance(strategy = InheritanceType.SINGLE_TABLE)
> > @DiscriminatorColumn(name="department")
> > public abstract class Employee {
> >  private String name;
> >  private String title;
> >
> >  @Id
> >  public String getName() {
> >  return name;
> >  }
> >
> >  @Transient
> >  public String getTitle() {
> >  return title;
> >  }
> >
> >  protected void setName(String name) {
> >  this.name = name;
> >  }
> >
> >  protected void setTitle(String title) {
> >  this.title = title;
> >  }
> > }
> >
> > @Entity
> > public class Editor extends Employee {
> >  @Column(name = "e_title")
> >  public String getTitle() {
> >  return super.getTitle();
> >  }
> >
> >  public void setTitle(String title) {
> >  super.setTitle( title );
> >  }
> > }
> >
> > @Entity
> > public class Writer extends Employee {
> >  private Group group;
> >
> >  @ManyToOne(optional = false)
> >  @JoinColumn(name = "e_title")
> >  public Group getGroup() {
> >  return group;
> >  }
> >
> >  public void setGroup(Group group) {
> >  this.group = group;
> >  setTitle( group.getName() );
> >  }
> > }
> >
> > In 4.2, the above mapping worked with Employee#title being persistent,
> but
> > does not work in 5.3.
> >
> > Section 2.2 Persistent Fields and Properties of the spec says:
> >
> > "Entity subclasses may override the property accessor methods. However,
> > portable applications must not override the object/relational mapping
> > metadata that applies to the persistent fields or properties of entity
> > superclasses."
> >
> > Would overriding a transient attribute be portable? If not, is that
> > something Hibernate would/should support?
> >
> > Thanks,
> > Gail
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Can a transient attribute be overridden to be persistent in a subclass?

[Gail Badner]

I *think* the following is valid, but I need confirmation. This mapping
does seem to work for Hibernate.

A transient attribute, Employee#title, gets overridden as a persistent
attribute, Editor#title, stored in a column named "e_title".

Writer#title is also transient, but Writer#group uses the same "e_title"
column as a foreign key. That foreign key value is used to populate
Writer#title.

@Entity
@Table(name="Employee")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name="department")
public abstract class Employee {
private String name;
private String title;

@Id
public String getName() {
return name;
}

@Transient
public String getTitle() {
return title;
}

protected void setName(String name) {
this.name = name;
}

protected void setTitle(String title) {
this.title = title;
}
}

@Entity
public class Editor extends Employee {
@Column(name = "e_title")
public String getTitle() {
return super.getTitle();
}

public void setTitle(String title) {
super.setTitle( title );
}
}

@Entity
public class Writer extends Employee {
private Group group;

@ManyToOne(optional = false)
@JoinColumn(name = "e_title")
public Group getGroup() {
return group;
}

public void setGroup(Group group) {
this.group = group;
setTitle( group.getName() );
}
}

In 4.2, the above mapping worked with Employee#title being persistent, but
does not work in 5.3.

Section 2.2 Persistent Fields and Properties of the spec says:

"Entity subclasses may override the property accessor methods. However,
portable applications must not override the object/relational mapping
metadata that applies to the persistent fields or properties of entity
superclasses."

Would overriding a transient attribute be portable? If not, is that
something Hibernate would/should support?

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Bytecode enhancement as proxy

[Gail Badner]

+1

On Tue, Jul 7, 2020 at 5:55 AM Sanne Grinovero  wrote:

> +1 Great idea
>
> On Tue, 7 Jul 2020 at 13:15, andrea boriero  wrote:
> >
> > Hi all,
> >
> > Last year the Bytecode enhancement as proxy feature was introduced (see
> > https://in.relation.to/2019/07/30/bytecode-proxy/ for details) and the
> > hibernate.bytecode.allow_enhancement_as_proxy was added to enable/disable
> > the new feature.
> >
> > In ORM 5.3 and 5.4 versions this feature is disabled by default, I was
> > wondering if it is a good idea for the future ORM 5.5 release to make
> > it enabled by default.
> >
> > Thanks,
> > Andrea
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [ORM] Query with condition on subclass attribute

[Gail Badner]

I don't see it documented in the user guide. Is it safe to assume that this
functionality won't be going away?

On Wed, Jul 1, 2020 at 5:11 PM Steve Ebersole  wrote:

> It is not portable.  Hibernate applies an implicit treat-as operation in
> such cases.  This is actually Hibernate's behavior from the beginning.  JPA
> says this should use an explicit treat-as operation.
>
> On Wed, Jul 1, 2020, 4:58 PM Gail Badner  wrote:
>
>> Hi,
>>
>> Given the following inheritance hierarchy:
>>
>> @Entity
>> public class Person {
>> @Id
>> private int id;
>> ...
>> }
>>
>> @Entity
>> public class Employee extends Person {
>> private String title;
>> }
>>
>> Executing a query like the following succeeds.
>>
>> "from Person where title = 'abc'"
>>
>> I thought that it would fail because Person does not have an attribute
>> named "title". Instead, the query succeeds and returns the Employee with
>> the specified title.
>>
>> I don't see anything in the JPA spec that indicates whether this is
>> portable.
>>
>> Does anyone know if this is portable?
>>
>> Thanks,
>> Gail
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [ORM] Query with condition on subclass attribute

[Gail Badner]

Hi,

Given the following inheritance hierarchy:

@Entity
public class Person {
@Id
private int id;
...
}

@Entity
public class Employee extends Person {
private String title;
}

Executing a query like the following succeeds.

"from Person where title = 'abc'"

I thought that it would fail because Person does not have an attribute
named "title". Instead, the query succeeds and returns the Employee with
the specified title.

I don't see anything in the JPA spec that indicates whether this is
portable.

Does anyone know if this is portable?

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] v6 and load-event

[Gail Badner]

I *think* so.

On Fri, Jun 5, 2020 at 12:45 PM Steve Ebersole  wrote:

> Load event handling does not have "anything" parameters.  Am I
> understanding you correctly?
>
> On Fri, Jun 5, 2020, 11:42 AM Gail Badner  wrote:
>
>> Hi Steve,
>>
>> Sorry, I have not read the entire thread carefully, so please disregard
>> if not relevant.
>>
>> Would this provide functionality like what we discussed for an
>> OperationContext?
>>
>> https://hibernate.atlassian.net/browse/HHH-10478
>>
>> Thanks,
>> Gail
>>
>> On Fri, May 29, 2020 at 4:21 AM Steve Ebersole 
>> wrote:
>>
>>> If/when it comes to needing that, I kind of like that continuation
>>> design.
>>> But I agree, Yoann is right - let's leave it off until needed or until we
>>> have specific requirements.
>>>
>>> Thanks everyone!
>>>
>>> On Fri, May 29, 2020 at 2:19 AM Sanne Grinovero 
>>> wrote:
>>>
>>> > On Fri, 29 May 2020 at 07:22, Yoann Rodiere 
>>> wrote:
>>> > >
>>> > > +1 not to add surround capability initially. Sounds better to start
>>> > simple and make things more complex when we actually need it :)
>>> >
>>> > Right. I didn't mean to raise additional requirements without having
>>> > investigated those tracing libraries - what I meant really is just to
>>> > raise awareness that we'll likely need to evolve it further when it
>>> > comes to finally implement such things.
>>> >
>>> > >
>>> > > Yoann Rodière
>>> > > Hibernate Team
>>> > > yo...@hibernate.org
>>> > >
>>> > >
>>> > > On Fri, 29 May 2020 at 07:25, Sanne Grinovero 
>>> > wrote:
>>> > >>
>>> > >> Yes, I agree.
>>> > >>
>>> > >> On Thu, 28 May 2020, 22:11 Steve Ebersole, 
>>> wrote:
>>> > >>>
>>> > >>> Wanted to clarify -
>>> > >>>
>>> > >>> Regarding incremental addition of "surround listeners", so long as
>>> we
>>> > are all in agreement that this simply means there will be absolutely no
>>> > surround capability ***initially*** then I am fine with that.
>>> > >>>
>>> > >>> On Thu, May 28, 2020 at 4:10 PM Steve Ebersole <
>>> st...@hibernate.org>
>>> > wrote:
>>> > >>>>
>>> > >>>> Hm, the dynamic enable/disable stuff should be easy to handle, no?
>>> > Depends on what specific library you are thinking of and exactly how
>>> that
>>> > detail gets propagated to us.  At the end of the day, its really as
>>> simple
>>> > as protecting the creation of some of these objects with `if
>>> > (enabled)`-type checks.
>>> > >>>>
>>> > >>>> But again, if you have specific details in mind we can take a
>>> look.
>>> > >>>>
>>> > >>>> Also, I think it is not at all a good idea to even plan for
>>> > "different types of events".  In fact I'm fine with getting rid of
>>> > LoadEvent completely from that contract and simply directly passing the
>>> > information that is likely useful.  I mean at the end of the day a
>>> listener
>>> > for load events is going to be interested in the same set of
>>> information.
>>> > Yes, some will not need all of that information but that's not really a
>>> > concern IMO.  Especially if we inline the parameters and completely
>>> avoid
>>> > the event object instantiation
>>> > >>>>
>>> > >>>> Regarding incremental addition of "surround listeners", so long
>>> as we
>>> > are all in agreement that this simply means there will be absolutely no
>>> > surround capability then I am fine with that.
>>> > >>>>
>>> > >>>>
>>> > >>>> On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero <
>>> sa...@hibernate.org>
>>> > wrote:
>>> > >>>>>
>>> > >>>>> On Thu, 28 May 2020 at 21:27, Steve Ebersole <
>>> st...@hibernate.org>
>>> > wrote:
>>> > >>>>> >
>>> > >>>>> > Any thought

Re: [hibernate-dev] v6 and load-event

[Gail Badner]

Hi Steve,

Sorry, I have not read the entire thread carefully, so please disregard if
not relevant.

Would this provide functionality like what we discussed for an
OperationContext?

https://hibernate.atlassian.net/browse/HHH-10478

Thanks,
Gail

On Fri, May 29, 2020 at 4:21 AM Steve Ebersole  wrote:

> If/when it comes to needing that, I kind of like that continuation design.
> But I agree, Yoann is right - let's leave it off until needed or until we
> have specific requirements.
>
> Thanks everyone!
>
> On Fri, May 29, 2020 at 2:19 AM Sanne Grinovero 
> wrote:
>
> > On Fri, 29 May 2020 at 07:22, Yoann Rodiere  wrote:
> > >
> > > +1 not to add surround capability initially. Sounds better to start
> > simple and make things more complex when we actually need it :)
> >
> > Right. I didn't mean to raise additional requirements without having
> > investigated those tracing libraries - what I meant really is just to
> > raise awareness that we'll likely need to evolve it further when it
> > comes to finally implement such things.
> >
> > >
> > > Yoann Rodière
> > > Hibernate Team
> > > yo...@hibernate.org
> > >
> > >
> > > On Fri, 29 May 2020 at 07:25, Sanne Grinovero 
> > wrote:
> > >>
> > >> Yes, I agree.
> > >>
> > >> On Thu, 28 May 2020, 22:11 Steve Ebersole, 
> wrote:
> > >>>
> > >>> Wanted to clarify -
> > >>>
> > >>> Regarding incremental addition of "surround listeners", so long as we
> > are all in agreement that this simply means there will be absolutely no
> > surround capability ***initially*** then I am fine with that.
> > >>>
> > >>> On Thu, May 28, 2020 at 4:10 PM Steve Ebersole 
> > wrote:
> > 
> >  Hm, the dynamic enable/disable stuff should be easy to handle, no?
> > Depends on what specific library you are thinking of and exactly how that
> > detail gets propagated to us.  At the end of the day, its really as
> simple
> > as protecting the creation of some of these objects with `if
> > (enabled)`-type checks.
> > 
> >  But again, if you have specific details in mind we can take a look.
> > 
> >  Also, I think it is not at all a good idea to even plan for
> > "different types of events".  In fact I'm fine with getting rid of
> > LoadEvent completely from that contract and simply directly passing the
> > information that is likely useful.  I mean at the end of the day a
> listener
> > for load events is going to be interested in the same set of information.
> > Yes, some will not need all of that information but that's not really a
> > concern IMO.  Especially if we inline the parameters and completely avoid
> > the event object instantiation
> > 
> >  Regarding incremental addition of "surround listeners", so long as
> we
> > are all in agreement that this simply means there will be absolutely no
> > surround capability then I am fine with that.
> > 
> > 
> >  On Thu, May 28, 2020 at 3:55 PM Sanne Grinovero <
> sa...@hibernate.org>
> > wrote:
> > >
> > > On Thu, 28 May 2020 at 21:27, Steve Ebersole 
> > wrote:
> > > >
> > > > Any thoughts on this "continuation" approach?
> > >
> > > I love the pattern! Maybe we'll need also some ability to not
> capture
> > > the state for events which don't have any?
> > >
> > > I wonder if that implies we'll need two different event contracts:
> > one
> > > for the listeners which need state and one for those which don't;
> but
> > > I'm not eager to overcomplicate this.
> > >
> > > > Or maybe its just not important (yet) to handle "surround"
> > handling?
> > >
> > > I'm confident that integration with tracing libraries would be very
> > > useful and interesting to have - but indeed not having time to
> > > research it properly I'm a bit afraid that it might need further
> > > changes to reach excellent performance.
> > >
> > > For example one thing I remember is that with some libraries you're
> > > supposed to have the option to enable/disable the profiling options
> > > dynamically, and since there's an expectation of no overhead when
> > it's
> > > disabled this would need to imply having a way for the overhead of
> > > allocating space for the captured state to "vanish": this might be
> a
> > > bit more complicated, or need to be able to take advantage of JIT
> > > optimisations.
> > >
> > > So if we end up thinking that such event APIs need to be different
> > > depending on the need for state, perhaps indeed it's better to
> > > postpone the design of those with state to when someone has time to
> > > research an optimal integration with a tracing library. It might
> not
> > > be too hard, I just haven't explored it myself yet.
> > >
> > > Maybe let's do this incrementally, considering the "continuation"
> > > approach a next step?
> > >
> > > Thanks,
> > > Sanne
> > >
> > > >
> > > > On Wed, May 27, 2020 at 9:27 AM Steve Ebersole <
> > st...@hi

Re: [hibernate-dev] Branch protections: enabling selected maintainers on older branches

[Gail Badner]

Thanks for doing that Sanne!

On Tue, May 19, 2020 at 11:28 PM Yoann Rodiere  wrote:

> Sounds like a good idea.
>
> I took the liberty of renaming the team, since it's specifically about ORM,
> and older versions of other projects may not be maintained by the same
> people.
>
> I'll do something similar for Search.
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Tue, 19 May 2020 at 22:36, Sanne Grinovero  wrote:
>
> > Hi all,
> >
> > yesterday I pushed a fix on Hibernate ORM branch 5.3 by mistake and
> > had to apologize to Gail, since we're to be very conservative with
> > that branch and she needs to be able to track and approve any changes
> > on this specific branch.
> >
> > This made me check if there was a way to express such rules on github,
> > and there is: the "branch protection" feature can now apply different
> > rules, such as requiring to be a member of a specific team, on a
> > specific branch.
> >
> > I like that: we can allow most current committers to keep working on
> > any branches in active development, such as master, while only a more
> > restricted group can push freely on selected older branches.
> >
> > Of course admins can always change the settings if there's compelling
> > need; in this case I like the self-imposed restriction as it would
> > help avoid mistakes - such as trying to be helpful when too tired.
> >
> > So I enabled this on 5.3 already .. I hope you agree it's a welcome
> > change, but we can of course reverse this if there's strong concerns,
> > or if we regret it later.
> >
> > Thoughts? I'd assume other Hibernate projects might want to do a
> > similar thing; among other benefits it might make it easier to give
> > push permissions to new volunteers, withouth needing to impose on them
> > all the responsibilities and more complex processes we have for
> > maintenance branches.
> >
> > Thanks,
> > Sanne
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.3.17 and 5.4.15.Final has been released

[Gail Badner]

5.3.17: https://in.relation.to/2020/04/30/hibernate-orm-5317-final-out/
5.4.15: https://in.relation.to/2020/04/30/hibernate-orm-5415-final-out/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release Hibernate ORM 5.3.17 and 5.4.15

[Gail Badner]

Please do not push anything to 5.3 or 5.4 branches until after they are
released.

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-13916 / WFLY-13259

[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  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 
> wrote:
>
>> On Wed, 15 Apr 2020 at 02:16, Gail Badner  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  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 
>> 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  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.
>> >>> >
>>

Re: [hibernate-dev] HHH-13916 / WFLY-13259

[Gail Badner]

FWIW, there's no point in fixing HHH-13916 unless we hear that Infinispan
is going to use the fix.

Radim/Galder, WDYT?

Thanks,
Gail

On Tue, Apr 14, 2020 at 3:25 PM Gail Badner  wrote:

> Hi Sanne,
>
> I've reworked HHH-13916 <https://hibernate.atlassian.net/browse/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 
> 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  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@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-13916 / WFLY-13259

[Gail Badner]

Hi Sanne,

I've reworked HHH-13916 <https://hibernate.atlassian.net/browse/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  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  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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HHH-13916 / WFLY-13259

[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
 [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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.3.16.Final released

[Gail Badner]

For details: https://in.relation.to/2020/03/27/hibernate-orm-5316-final-out/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.4.13.Final has been released

[Gail Badner]

We've released Hibernate ORM version 5.4.11.Final !

For details:
https://in.relation.to/2020/03/26/hibernate-orm-5413-final-out/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release Hibernate ORM 5.4.13

[Gail Badner]

Please don't push to master until the release is announced.

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Jakarta EE: JPA 3.0 is coming

[Gail Badner]

I'm unsure of the merit of supporting both JPA 2.2 and JPA 3.0 using the
exact same source code and jars.

I have not thought too much about the ramifications of this, but what about
dealing with this by having the gradle build generate JPA 3.0-compatible
source/test code, then changing the release process to test/release both
JPA 2.2-compatible and JPA 3.0-compatible sets of jars, source code, and
documentation?

The JPA 2.2-compatible jars could follow our current naming conventions.
The JPA 3.0-compatible jars could have a suffix like -JPA3.jar.

I believe this would be less work than employing bytecode magic.

Users would have the ability to move to using JPA 3.3 with 5.3/5.4.

Obviously this would have ramifications for WildFly/EAP.

Anyhow, that's my half-baked idea...

Regards,
Gail

On Wed, Mar 11, 2020 at 7:43 AM Guillaume Smet 
wrote:

> On Wed, Mar 11, 2020 at 9:49 AM Sanne Grinovero 
> wrote:
>
> > I'm not a fan of bytecode hacks either, so maybe let's just see what a
> POC
> > looks like before tearing it down?
> >
> >>
> I totally miss why we would want to even work on a POC given how much we
> have on our shoulders? Could someone explain it to me?
>
> IMHO, *if* consumers of our stack want to support both javax and jakarta
> packages, the work will need to be done there i.e. in WildFly or Quarkus.
>
> There's a good chance the solutions will be different given the totally
> different infrastructure of both.
>
> And supporting that for Hibernate ORM only makes sense if the whole stack
> supports that e.g. CDI, HV, Jakarta EL... and AFAICS most of the projects
> will only support either javax or jakarta, not both. So if we want to
> support both, we will need the extra layer I was talking about at a global
> level, not in Hibernate ORM.
>
> I wouldn't open the door at supporting both in ORM and let the consuming
> projects decide of the strategy they want to follow and how they want to
> solve the issue globally.
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Property using field access and has final getter/setter method

[Gail Badner]

Here's the PR:
https://github.com/hibernate/hibernate-orm/pull/3286

On Thu, Mar 5, 2020 at 10:21 PM Gail Badner  wrote:

> I created https://hibernate.atlassian.net/browse/HHH-13891.
>
> IIUC, a ProxyFactory should not be created if any ID, version, or property
> method getter/setter is final.
>
> I'm working on a PR.
>
> Thanks,
> Gail
>
>
> On Thu, Mar 5, 2020 at 7:56 AM Steve Ebersole  wrote:
>
>> If any getters or setters are final then the ProxyFactory cannot be used
>> and imo should not get built, especially moving forward as we could use
>> bytecode-based proxies
>>
>> On Wed, Mar 4, 2020 at 2:11 PM Gail Badner  wrote:
>>
>>> This commit [1] for HHH-11838 [2] causes an error to get logged by
>>> ProxyFactoryHelper#validateProxyability [3] for a property that uses
>>> field
>>> access and has a corresponding final getter/setter method.
>>>
>>> The logged error does not cause any failure, and the
>>> ByteBuddyProxyFactory
>>> gets built.
>>>
>>> Should this error be logged in this case?
>>>
>>> When the error message is valid, should ByteBuddyProxyFactory not get
>>> built?
>>>
>>> Thanks,
>>> Gail
>>>
>>> [1]
>>>
>>> https://github.com/hibernate/hibernate-orm/commit/f8b78bcad0df43bd9b69fa5ee9d3bf10a3202318
>>> [2] https://hibernate.atlassian.net/browse/HHH-11838
>>> [3]
>>>
>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/proxy/pojo/ProxyFactoryHelper.java#L87-L94
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Property using field access and has final getter/setter method

[Gail Badner]

I created https://hibernate.atlassian.net/browse/HHH-13891.

IIUC, a ProxyFactory should not be created if any ID, version, or property
method getter/setter is final.

I'm working on a PR.

Thanks,
Gail


On Thu, Mar 5, 2020 at 7:56 AM Steve Ebersole  wrote:

> If any getters or setters are final then the ProxyFactory cannot be used
> and imo should not get built, especially moving forward as we could use
> bytecode-based proxies
>
> On Wed, Mar 4, 2020 at 2:11 PM Gail Badner  wrote:
>
>> This commit [1] for HHH-11838 [2] causes an error to get logged by
>> ProxyFactoryHelper#validateProxyability [3] for a property that uses field
>> access and has a corresponding final getter/setter method.
>>
>> The logged error does not cause any failure, and the ByteBuddyProxyFactory
>> gets built.
>>
>> Should this error be logged in this case?
>>
>> When the error message is valid, should ByteBuddyProxyFactory not get
>> built?
>>
>> Thanks,
>> Gail
>>
>> [1]
>>
>> https://github.com/hibernate/hibernate-orm/commit/f8b78bcad0df43bd9b69fa5ee9d3bf10a3202318
>> [2] https://hibernate.atlassian.net/browse/HHH-11838
>> [3]
>>
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/proxy/pojo/ProxyFactoryHelper.java#L87-L94
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Custom EventType and listeners

[Gail Badner]

Thanks for the feedback!

I've created https://hibernate.atlassian.net/browse/HHH-13890 .

On Thu, Mar 5, 2020 at 7:57 AM Steve Ebersole  wrote:

> I agree at the high level.
>
> On Thu, Mar 5, 2020 at 9:17 AM Sanne Grinovero 
> wrote:
>
>> Hi Gail,
>>
>> at high level it seems a reasonable idea to me.
>>
>> In more detail, let's make sure the `registeredEventListeners`
>> initialization is not affected by data races, but we can defer
>> discussing such details on a PR as that would probably be clearer.
>>
>> Thanks,
>> Sanne
>>
>> On Thu, 5 Mar 2020 at 07:16, Gail Badner  wrote:
>> >
>> > There has been some discussion that it may be useful for hibernate-rx
>> to be
>> > able to define RX-specific event types and listeners.
>> >
>> > I've created a POC [1] that adds this support. I still need to do some
>> > testing, but I would like some feedback before I spend too much time on
>> > this.
>> >
>> > Please let me know if this is a reasonable improvement. If it is, I will
>> > create an HHH jira and create a pull request.
>> >
>> > Thanks,
>> > Gail
>> >
>> > [1]
>> >
>> https://github.com/gbadner/hibernate-core/commit/2d368a2ce1da36468ab7f965467711bc59f439cf
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Custom EventType and listeners

[Gail Badner]

There has been some discussion that it may be useful for hibernate-rx to be
able to define RX-specific event types and listeners.

I've created a POC [1] that adds this support. I still need to do some
testing, but I would like some feedback before I spend too much time on
this.

Please let me know if this is a reasonable improvement. If it is, I will
create an HHH jira and create a pull request.

Thanks,
Gail

[1]
https://github.com/gbadner/hibernate-core/commit/2d368a2ce1da36468ab7f965467711bc59f439cf
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Property using field access and has final getter/setter method

[Gail Badner]

This commit [1] for HHH-11838 [2] causes an error to get logged by
ProxyFactoryHelper#validateProxyability [3] for a property that uses field
access and has a corresponding final getter/setter method.

The logged error does not cause any failure, and the ByteBuddyProxyFactory
gets built.

Should this error be logged in this case?

When the error message is valid, should ByteBuddyProxyFactory not get built?

Thanks,
Gail

[1]
https://github.com/hibernate/hibernate-orm/commit/f8b78bcad0df43bd9b69fa5ee9d3bf10a3202318
[2] https://hibernate.atlassian.net/browse/HHH-11838
[3]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/proxy/pojo/ProxyFactoryHelper.java#L87-L94
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM : format of the version logged on boot

[Gail Badner]

+1 to changing it.

The name was changed from "core" to "ORM" some years back. Can "core" just
be dropped now?

On Fri, Feb 7, 2020 at 6:20 AM Yoann Rodiere  wrote:

> +1
>
>
> Yoann Rodière
> Hibernate Team
> yo...@hibernate.org
>
>
> On Fri, 7 Feb 2020 at 14:58, Sanne Grinovero  wrote:
>
> > It's minor cosmetics, but I'd like to change the format of the message
> > we log on boot.
> >
> > Currently we have:
> > INFO  [org.hib.Version] HHH000412: Hibernate Core {5.4.11-SNAPSHOT}
> >
> > I would like to change it into:
> >INFO  [org.hib.Version] HHH000412: Hibernate ORM core version
> > 5.4.11-SNAPSHOT
> >
> > in particular:
> >  - to remove the "{}" wrapping around the number
> >  - add "ORM"
> >  - lowercase "core" and add "version"
> >
> > Looks good? It would be more consistent with our own project
> > naming/branding, and with the format of similar messages being logged
> > by other popular libraries.
> >
> > Thanks,
> > Sanne
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.3.15.Final has been released!

[Gail Badner]

It was actually released 07/Jan/2020. Apologies for the late announcement!
https://in.relation.to/2020/01/23/hibernate-orm-5315-final-out/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Bidirectional one-to-one, both sides are owners, using @PrimaryKeyJoinColumn

[Gail Badner]

Hi Jan-Willem,

Thanks for responding.

I have also heard from Steve offlist that this mapping is not valid.

Also, please see below...

On Wed, Jan 15, 2020 at 1:20 AM Jan-Willem Gmelig Meyling <
jan-wil...@youngmediaexperts.nl> wrote:

> Hi Gail,
>
> The mapping is IMO invalid. For removal etc. to work properly, the
> direction needs to be deducible. However, I’ve observed this mapping as a
>  workaround for supporting lazy loading on either side of the association,
> prior to our fixes in 5.4 with HHH-12842 [1] .
>

Yes, I was thinking that as well.


> The mapping works  in my experience,  but with quirks that are to be
> expected. With Hibernate 5.4 there is no reason to map this at all: if the
> association is non-optional and non-nullable, also the non-owning side of
> the association can be lazy loaded.
>

Bytecode enhancement is required for the non-owning side to be lazily
loaded.

With bytecode enhancement and enhancement-as-proxy enabled, the association
does not get set as an uninitialized proxy, even though the ID for the
associated entity is the same as the ID for the entity owner. I've created
https://hibernate.atlassian.net/browse/HHH-13814 for that case.

I believe the fix for HHH-13814 could also apply when bytecode enhancement
is not enabled.

Regards,
Gail


>
>
> Kind regards,
>
> Jan-Willem
>
>
> [1] https://github.com/hibernate/hibernate-orm/pull/2612
>
>
> On 15 Jan 2020, at 05:18, Gail Badner  wrote:
>
> Hi,
>
> Does Hibernate support having both entities involved in a one-to-one
> association own its side of the association when using
> @PrimaryKeyJoinColumn?
>
> My guess is that this is not supported by Hibernate. I just want to
> confirm.
>
> For example:
>
> @Entity
> public class Employee {
>
>@EmbeddedId
>private CompositeKey id;
>
>@OneToOne(optional = false)
>@PrimaryKeyJoinColumns({
>  @PrimaryKeyJoinColumn(name = "ID1", referencedColumnName = "ID1"),
>  @PrimaryKeyJoinColumn(name = "ID2", referencedColumnName =
> "ID2"), })
>})
>private EmployeeInfo employeeInfo;
>...
> }
>
> @Entity
> public class EmployeeInfo {
>
>@EmbeddedId
>private CompositeKey id;
>
>@OneToOne(optional = false)
>@PrimaryKeyJoinColumns({
>  @PrimaryKeyJoinColumn(name = "ID1", referencedColumnName = "ID1"),
>  @PrimaryKeyJoinColumn(name = "ID2", referencedColumnName =
> "ID2"), })
>})
>private Employee employee;
> ...
> }
>
> In this particular case, the foreign keys have been deleted, so it's
> possible to load and delete these entities.
>
> An attempt to insert an entity on either side results in:
> org.hibernate.PropertyValueException: not-null property references a null
> or transient value
>
> When converted to use @MapsId and @JoinColumns instead, Hibernate throws:
> org.hibernate.MappingException: cyclic dependency in derived identities
>
> Please let me know...
>
> Thanks,
> Gail
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Bidirectional one-to-one, both sides are owners, using @PrimaryKeyJoinColumn

[Gail Badner]

Hi,

Does Hibernate support having both entities involved in a one-to-one
association own its side of the association when using
@PrimaryKeyJoinColumn?

My guess is that this is not supported by Hibernate. I just want to confirm.

For example:

@Entity
public class Employee {

@EmbeddedId
private CompositeKey id;

@OneToOne(optional = false)
@PrimaryKeyJoinColumns({
  @PrimaryKeyJoinColumn(name = "ID1", referencedColumnName = "ID1"),
  @PrimaryKeyJoinColumn(name = "ID2", referencedColumnName =
"ID2"), })
})
private EmployeeInfo employeeInfo;
...
}

@Entity
public class EmployeeInfo {

@EmbeddedId
private CompositeKey id;

@OneToOne(optional = false)
@PrimaryKeyJoinColumns({
  @PrimaryKeyJoinColumn(name = "ID1", referencedColumnName = "ID1"),
  @PrimaryKeyJoinColumn(name = "ID2", referencedColumnName =
"ID2"), })
})
private Employee employee;
 ...
}

In this particular case, the foreign keys have been deleted, so it's
possible to load and delete these entities.

An attempt to insert an entity on either side results in:
org.hibernate.PropertyValueException: not-null property references a null
or transient value

When converted to use @MapsId and @JoinColumns instead, Hibernate throws:
org.hibernate.MappingException: cyclic dependency in derived identities

Please let me know...

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Composite IDs with a null property/field

[Gail Badner]

I agree with Steve. I don't think that we should add a feature to
explicitly support this.

That said, there is a workaround that avoids the issue, by using a UserType
to convert null to an empty string for Java processing, and convert the
empty string to null for inserting, update, and deleting.

I've created 2 tests that illustrate how this can be done with a UserType
and a custom @Loader, @SQLUpdate, and @SQLDelete:

Using an embedded ID:
https://github.com/gbadner/hibernate-core/blob/composite-id-with-null-property/hibernate-core/src/test/java/org/hibernate/test/cid/EmbeddedIdUserTypeNullableColumnTest.java

Using an IdClass:
https://github.com/gbadner/hibernate-core/blob/composite-id-with-null-property/hibernate-core/src/test/java/org/hibernate/test/cid/IdClassUserTypeNullableColumnTest.java

It will not be possible to execute an HQL/JPL query like:
CompositeKeyEntity compositeKeyEntity  = session.createQuery(
"from CKE where compositeKey = ?1",
CompositeKeyEntity.class
).setParameter( 1, new CompositeKey( "abc", LocaleType.DEFAULT )
).uniqueResult();

because Hibernate generates the SQL:

select embeddable0_.id1 as id1_0_ embeddable0_.id2 as id2_0_,
embeddable0_.name as name3_0_ from CKE embeddable0_ where
embeddable0_.id1=? and embeddable0_.id2=?

If an entity has id2 == null, then it will not be possible to load it using
this query.

The following will work though:

CompositeKeyEntity compositeKeyEntity  = session.createQuery(
"from CKE where compositeKey.id1 = ?1 and (compositeKey.id2 = ?2 or
compositeKey.id2 is null )" ,
CompositeKeyEntity.class
).setParameter( 1, "abc" ).setParameter( 2, LocaleType.DEFAULT
).uniqueResult();

Regards,
Gail

On Wed, Dec 18, 2019 at 1:48 PM Steve Ebersole  wrote:

> I've already chimed in ;)
>
>  I don't think this is something we should do.
>
> On Wed, Dec 18, 2019, 3:44 PM Gail Badner  wrote:
>
>> The main obstacle I see is that Hibernate assumes that ID columns are
>> non-nullable, even if ID columns are explicitly mapped as nullable.
>>
>> This is consistent with the JPA spec, which says:
>>
>> "Every entity must have a primary key."
>>
>> ANSI SQL 92 says:
>>
>> "In addition, if the unique constraint was defined with PRIMARY KEY, then
>> it requires that none of the values in the specified column or columns be
>> the null value."
>>
>> javax.persistence.Column#nullable has a default of true.
>>
>> Since Hibernate ignores the default (as appropriate for a primary key), I
>> think that it is also appropriate to ignore an explicit mapping to make it
>> nullable (i.e., @Column(nullable="true")).
>>
>> I don't think it's a good idea to add a new property that would change
>> this behavior for ID columns.
>>
>> Aside from the issue I mentioned above about ComponentType#hydrate [1],
>> SQL Hibernate generates for loading an entity by ID would have to change.
>> Currently, Hibernate generates SQL like the following:
>>
>> select ... from ... where  bundle = ? and key = ? and locale = ?
>>
>> If the locale column is null, then Session#get will return null.
>>
>> It is possible to create a custom (@Loader) to change the query used by
>> Session#get.
>>
>> Unfortunately, that won't work when loading entities with a Query like
>> "from ... where id = ?".
>>
>> IMO, if we want to support this use case, we should use
>> Hibernate-specific annotations to indicate that a composite ID column
>> should be forced to be nullable.
>>
>> I haven't thought too much about this yet, but something like the
>> following comes to mind:
>>
>> @EnbeddedId
>> @UniqueKeyIdColumns( uniqueKeyIdColumns = {
>> @UniqueKeyIdColumn( name="BUNDLE_NAME" ),
>> @UniqueKeyIdColumn( name="KEY" ),
>> @UniqueKeyIdColumn( name="LOCALE", nullable="true" )
>> }
>>
>> The default for UniqueKeyIdColumn#nullable would be false.
>>
>> This would likely affect SPIs.
>>
>> Honestly, I am on the fence about whether this use case should be
>> supported.
>>
>> Steve, Emmanuel, please chime in with your opinion?
>>
>> Thanks,
>> Gail
>>
>> [1]
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/ComponentType.java#L671-L675
>>
>> On Tue, Dec 17, 2019 at 10:41 AM Gail Badner  wrote:
>>
>>> Jan-Willem, thanks very much for your feedback!
>>>
>>> You may be right about Hibernate not allowing a formula for a compo

Re: [hibernate-dev] Composite IDs with a null property/field

[Gail Badner]

The main obstacle I see is that Hibernate assumes that ID columns are
non-nullable, even if ID columns are explicitly mapped as nullable.

This is consistent with the JPA spec, which says:

"Every entity must have a primary key."

ANSI SQL 92 says:

"In addition, if the unique constraint was defined with PRIMARY KEY, then
it requires that none of the values in the specified column or columns be
the null value."

javax.persistence.Column#nullable has a default of true.

Since Hibernate ignores the default (as appropriate for a primary key), I
think that it is also appropriate to ignore an explicit mapping to make it
nullable (i.e., @Column(nullable="true")).

I don't think it's a good idea to add a new property that would change this
behavior for ID columns.

Aside from the issue I mentioned above about ComponentType#hydrate [1], SQL
Hibernate generates for loading an entity by ID would have to change.
Currently, Hibernate generates SQL like the following:

select ... from ... where  bundle = ? and key = ? and locale = ?

If the locale column is null, then Session#get will return null.

It is possible to create a custom (@Loader) to change the query used by
Session#get.

Unfortunately, that won't work when loading entities with a Query like
"from ... where id = ?".

IMO, if we want to support this use case, we should use Hibernate-specific
annotations to indicate that a composite ID column should be forced to be
nullable.

I haven't thought too much about this yet, but something like the following
comes to mind:

@EnbeddedId
@UniqueKeyIdColumns( uniqueKeyIdColumns = {
@UniqueKeyIdColumn( name="BUNDLE_NAME" ),
@UniqueKeyIdColumn( name="KEY" ),
@UniqueKeyIdColumn( name="LOCALE", nullable="true" )
}

The default for UniqueKeyIdColumn#nullable would be false.

This would likely affect SPIs.

Honestly, I am on the fence about whether this use case should be supported.

Steve, Emmanuel, please chime in with your opinion?

Thanks,
Gail

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/ComponentType.java#L671-L675

On Tue, Dec 17, 2019 at 10:41 AM Gail Badner  wrote:

> Jan-Willem, thanks very much for your feedback!
>
> You may be right about Hibernate not allowing a formula for a composite ID
> property. It appears it's not allowed when hbm mapping is used. I'll have
> to check to see if a formula is allowed when mapped with annotations..
>
> Looking a the mapping for Address again, I see the composite ID does not
> contain a formula. Instead Address is associated with 2 different entity
> names, each with a specified "where" attribute that indicates which entity
> name the specific mapping is for:
>
> table="Address"
>entity-name="BillingAddress"
>where="add_type='BILLING'"
>check="add_type in ('BILLING', 'SHIPPING')"
>select-before-update="true"
>dynamic-update="true">
>
>
>   
>   
>
>...
>
> 
>
> table="Address"
>entity-name="ShippingAddress"
>where="add_type='SHIPPING'"
>select-before-update="true"
>dynamic-update="true">
>
>
>   
>   
>
>...
> 
>
> We would need to check the entity's "where" attribute or @Where clause
> attribute value to see if the fragment references a composite ID column.
>
> Regards,
> Gail
>
> On Tue, Dec 17, 2019 at 1:29 AM Jan-Willem Gmelig Meyling <
> jan-wil...@youngmediaexperts.nl> wrote:
>
>> PostgreSQL doesn’t allow nullable columns in a compound primary key. It
>> allows a unique constraint on a nullable column, but then it happily
>> inserts the two values below - without constraint violation error.
>>
>> I too have stumbled upon the need for nullable identifiers in Hibernate
>> however. Mostly when I want to map native query results without an actual
>> PK to an entity class. Another use case is mapping a @Subselect entity.
>> These may not have an actual identifier, for example when creating a join
>> product, so in order for all results to appear at all, you specify a
>> compound key based on your requirements. I have experienced that this
>> compound key may contain null values (in case of a LEFT JOIN for example).
>>
>> As far as I am aware, it is currently not allowed to use Formula’s as @Id
>> - I’ve stumbled upon this exception recently and I think correctly so .
>> Maybe it is allowed for compound keys however. I think its safe to only
>> allow null properties in an com

Re: [hibernate-dev] Composite IDs with a null property/field

[Gail Badner]

Jan-Willem, thanks very much for your feedback!

You may be right about Hibernate not allowing a formula for a composite ID
property. It appears it's not allowed when hbm mapping is used. I'll have
to check to see if a formula is allowed when mapped with annotations..

Looking a the mapping for Address again, I see the composite ID does not
contain a formula. Instead Address is associated with 2 different entity
names, each with a specified "where" attribute that indicates which entity
name the specific mapping is for:



   
  
  
   
   ...





   
  
  
   
   ...


We would need to check the entity's "where" attribute or @Where clause
attribute value to see if the fragment references a composite ID column.

Regards,
Gail

On Tue, Dec 17, 2019 at 1:29 AM Jan-Willem Gmelig Meyling <
jan-wil...@youngmediaexperts.nl> wrote:

> PostgreSQL doesn’t allow nullable columns in a compound primary key. It
> allows a unique constraint on a nullable column, but then it happily
> inserts the two values below - without constraint violation error.
>
> I too have stumbled upon the need for nullable identifiers in Hibernate
> however. Mostly when I want to map native query results without an actual
> PK to an entity class. Another use case is mapping a @Subselect entity.
> These may not have an actual identifier, for example when creating a join
> product, so in order for all results to appear at all, you specify a
> compound key based on your requirements. I have experienced that this
> compound key may contain null values (in case of a LEFT JOIN for example).
>
> As far as I am aware, it is currently not allowed to use Formula’s as @Id
> - I’ve stumbled upon this exception recently and I think correctly so .
> Maybe it is allowed for compound keys however. I think its safe to only
> allow null properties in an compound identifier if none of the identifier
> properties is a formula.
>
> Kind regards,
>
> Jan-Willem
>
>
>
>
>
>
> > On 17 Dec 2019, at 00:26, Gail Badner  wrote:
> >
> > I've confirmed that the same inserts result in a constraint violation
> using
> > Oracle 12c:
> >
> > insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
> > null);
> > insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
> > null);
> >
> > I'm trying to figure out what would be needed to support this.
> >
> > I tried simply commenting out this line:
> >
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/ComponentType.java#L673
> >
> > When I ran the unit
> > tests,
> org.hibernate.test.typedmanytoone.TypedManyToOneTest#testCreateQueryNull
> > failed because of a lazy many-to-one with a formula for a foreign key
> > column:
> >
> >  >   entity-name="BillingAddress"
> >   cascade="persist,save-update,delete"
> >   fetch="join">
> >   
> >   'BILLING'
> > 
> >
> > The change results in a Customer with a lazy ShippingAddress proxy
> > containing an AddressId with #addressId == null and #type == "BILLING').
> > When the proxy is initialized, ObjectNotFoundException is thrown.
> >
> > The reason this happens is a bit complicated.
> >
> > The problematic query is:
> >
> > "from Customer cust left join fetch cust.billingAddress where
> > cust.customerId='xyz123'"
> >
> > The SQL that gets generated is:
> >
> >select
> >customer0_.customerId as customer1_1_0_,
> >billingadd1_.addressId as addressI1_0_1_,
> >billingadd1_.add_type as add_type2_0_1_,
> >customer0_.name as name2_1_0_,
> >customer0_.billingAddressId as billingA3_1_0_,
> >customer0_.shippingAddressId as shipping4_1_0_,
> >'BILLING' as formula0_0_,
> >'SHIPPING' as formula1_0_,
> >billingadd1_.street as street3_0_1_,
> >billingadd1_.city as city4_0_1_,
> >billingadd1_.state as state5_0_1_,
> >billingadd1_.zip as zip6_0_1_
> >from
> >Customer customer0_
> >left outer join
> >Address billingadd1_
> >on customer0_.billingAddressId=billingadd1_.addressId
> >and 'BILLING'=billingadd1_.add_type
> >where
> >customer0_.customerId='xyz123'
> >
> > In this case, the Customer entity does not have a billingAddress.
> >
> > Hibernate correctly determines

Re: [hibernate-dev] Composite IDs with a null property/field

[Gail Badner]

I've confirmed that the same inserts result in a constraint violation using
Oracle 12c:

insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
null);
insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
null);

I'm trying to figure out what would be needed to support this.

I tried simply commenting out this line:
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/ComponentType.java#L673

When I ran the unit
tests, org.hibernate.test.typedmanytoone.TypedManyToOneTest#testCreateQueryNull
failed because of a lazy many-to-one with a formula for a foreign key
column:


   
   'BILLING'


The change results in a Customer with a lazy ShippingAddress proxy
containing an AddressId with #addressId == null and #type == "BILLING').
When the proxy is initialized, ObjectNotFoundException is thrown.

The reason this happens is a bit complicated.

The problematic query is:

"from Customer cust left join fetch cust.billingAddress where
cust.customerId='xyz123'"

The SQL that gets generated is:

select
customer0_.customerId as customer1_1_0_,
billingadd1_.addressId as addressI1_0_1_,
billingadd1_.add_type as add_type2_0_1_,
customer0_.name as name2_1_0_,
customer0_.billingAddressId as billingA3_1_0_,
customer0_.shippingAddressId as shipping4_1_0_,
'BILLING' as formula0_0_,
'SHIPPING' as formula1_0_,
billingadd1_.street as street3_0_1_,
billingadd1_.city as city4_0_1_,
billingadd1_.state as state5_0_1_,
billingadd1_.zip as zip6_0_1_
from
Customer customer0_
left outer join
Address billingadd1_
on customer0_.billingAddressId=billingadd1_.addressId
and 'BILLING'=billingadd1_.add_type
where
customer0_.customerId='xyz123'

In this case, the Customer entity does not have a billingAddress.

Hibernate correctly determines that the join fetched Address is null
because addressI1_0_1_ and add_type2_0_1_ are both null.

The problem happens when the Customer entity gets initialized. Since
Customer#billingAddress is mapped as lazy, it gets resolved as a proxy with
AddressId#addressId == null and #type == "BILLING").

Similarly, Customer#shippingAddress gets resolved as a proxy with
AddressId#addressId == null and #type == "SHIPPING").

Without the change Customer#billingAddress and #shippingAddress are null.

I don't see any way to maintain functionality demonstrated
by TypedManyToOneTest at the same time as allowing a composite ID to have a
null property at the same time.

I suppose we could allow a composite ID to have a null property only when
it has no properties that are formulas.

WDYT?

Thanks,
Gail

On Thu, Dec 12, 2019 at 10:26 AM Gail Badner  wrote:

> Thinking about this more, I realized that, depending on the database, the
> use case may be invalid.
>
> For H2, at least, the following is allowed with a unique constraint:
>
> insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
> null);
> insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
> null);
>
> The reason why the unique constraint is not violated is because null !=
> null.
>
> If we allow a null value for a composite ID property, it should be
> specific to the dialects that would assume null == null in a unique key. I
> believe SQL Server behaves this way. I'm not sure about other databases.
>
> On Wed, Dec 11, 2019 at 3:06 AM Emmanuel Bernard 
> wrote:
>
>> My answer is that if the code change looks too impactful I'm fine with no
>> supporting such scenario.
>>
>> On 11 Dec 2019, at 11:24, Joerg Baesner wrote:
>>
>> > ...  I suppose some means it as default.
>>
>> Yes, exactly.
>>
>> Your reply doesn't answer the question if Hibernate shouldn't support
>> this scenario. Anyhow, what Gail already wrote is that Hibernate returns
>> null for the entity result, leading to a null value in a returned
>> ResultList, which seem to be wrong...
>>
>> On Wed, Dec 11, 2019 at 11:16 AM Emmanuel Bernard 
>> wrote:
>>
>>> We have been trying to keep a balance of maintainable code base for
>>> Hibernate vs legacy/counter intuitive/plain wrong DB designs. The answer is
>>> never clear cut. In your case I'm not sure what a bundle + key means if it
>>> does not have a locale - I suppose some means it as default.
>>>
>>> On 11 Dec 2019, at 10:49, Joerg Baesner wrote:
>>>
>>> > I think in the past we argued the same for attributes of a composite
>>

Re: [hibernate-dev] Composite IDs with a null property/field

[Gail Badner]

Thinking about this more, I realized that, depending on the database, the
use case may be invalid.

For H2, at least, the following is allowed with a unique constraint:

insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
null);
insert into bundle (BUNDLE_NAME, KEY, LOCALE) values('bundle1', 'key1',
null);

The reason why the unique constraint is not violated is because null !=
null.

If we allow a null value for a composite ID property, it should be specific
to the dialects that would assume null == null in a unique key. I believe
SQL Server behaves this way. I'm not sure about other databases.

On Wed, Dec 11, 2019 at 3:06 AM Emmanuel Bernard 
wrote:

> My answer is that if the code change looks too impactful I'm fine with no
> supporting such scenario.
>
> On 11 Dec 2019, at 11:24, Joerg Baesner wrote:
>
> > ...  I suppose some means it as default.
>
> Yes, exactly.
>
> Your reply doesn't answer the question if Hibernate shouldn't support this
> scenario. Anyhow, what Gail already wrote is that Hibernate returns null
> for the entity result, leading to a null value in a returned ResultList,
> which seem to be wrong...
>
> On Wed, Dec 11, 2019 at 11:16 AM Emmanuel Bernard 
> wrote:
>
>> We have been trying to keep a balance of maintainable code base for
>> Hibernate vs legacy/counter intuitive/plain wrong DB designs. The answer is
>> never clear cut. In your case I'm not sure what a bundle + key means if it
>> does not have a locale - I suppose some means it as default.
>>
>> On 11 Dec 2019, at 10:49, Joerg Baesner wrote:
>>
>> > I think in the past we argued the same for attributes of a composite id,
>> > like you said, if one of the element can be nul, why is it in the id
>> > property in the first place.
>>
>> As an example you might Imagine someone wants to put internationalization
>> properties into a database and having a table structure like this (this
>> might be an old legacy application that doesn't have a PK column):
>>
>> BUNDLE_NAME (not nullable)
>> KEY (not nullable)
>> LOCALE (nullable)
>> VALUE (not nullable)
>>
>> The first 3 (BUNDLE_NAME, KEY, LOCALE) are the CompositeKey and there's a
>> unique constraint on the database on these columns.
>>
>> It is fine to have the LOCALE as , as in this case the systems
>> default locale would be used, but for each BUNDLE_NAME/KEY combination you
>> could only have a single composite key with a  LOCALE.
>>
>> Hibernate should be (must be?) able to handle this scenario, what do you
>> think?
>>
>> Joerg
>>
>> On Wed, Dec 11, 2019 at 10:18 AM Emmanuel Bernard 
>> wrote:
>>
>>> Just talking about simple id, even if we allow the column to be nullable
>>> (if the DB even allows that), I don't think Hibernate allows null to be
>>> a valid id value. Because null means I don't know or not applicable.
>>> I think in the past we argued the same for attributes of a composite id,
>>> like you said, if one of the element can be nul, why is it in the id
>>> property in the first place.
>>>
>>> As for whether there is a strong implementation detail reason to not
>>> allow it, I don't know but I assume the null checking assuming "not an
>>> id" is pretty much all over the place.
>>>
>>> Emmanuel
>>>
>>> On 11 Dec 2019, at 3:37, Gail Badner wrote:
>>>
>>> > Currently, there is no way to load an entity that exists in the
>>> > database
>>> > with a composite ID, if one of the composite ID columns is null.
>>> >
>>> > This behavior is due to this code in ComponentType#hydrate:
>>> >
>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/ComponentType.java#L671-L675
>>> >
>>> > Basically, if any field/property in a composite ID is null, Hibernate
>>> > assumes the entire ID is null. An entity cannot have a null ID, so it
>>> > returns null for the entity result.
>>> >
>>> > I believe that Hibernate does allow a primary key column to be
>>> > nullable.
>>> >
>>> > TBH, it seems strange to have a property in a composite ID that can be
>>> > null. If it can be null, it seems that the property could be removed
>>> > from
>>> > the composite key.
>>> >
>>> > I don't see anything in the spec about a requirement that all
>>> > composite ID
>

[hibernate-dev] Composite IDs with a null property/field

[Gail Badner]

Currently, there is no way to load an entity that exists in the database
with a composite ID, if one of the composite ID columns is null.

This behavior is due to this code in ComponentType#hydrate:
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/ComponentType.java#L671-L675

Basically, if any field/property in a composite ID is null, Hibernate
assumes the entire ID is null. An entity cannot have a null ID, so it
returns null for the entity result.

I believe that Hibernate does allow a primary key column to be nullable.

TBH, it seems strange to have a property in a composite ID that can be
null. If it can be null, it seems that the property could be removed from
the composite key.

I don't see anything in the spec about a requirement that all composite ID
fields/properties must be non-null. Am I missing something?

The code I referenced above is 13 years old. Does anyone have insight into
why Hibernate does this?

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] IdClass superclasses

[Gail Badner]

I've created https://hibernate.atlassian.net/browse/HHH-13776.

Thanks!
Gail


On Tue, Dec 10, 2019 at 1:30 PM Steve Ebersole  wrote:

> Actually I was thinking of @EmbeddedId, but you were asking about @IdClass.
>
> I think (2) sounds more natural.
>
>
> On Tue, Dec 10, 2019 at 3:12 PM Steve Ebersole 
> wrote:
>
>> To me this is perfectly consistent with how inheritance works in entity
>> hierarchies.  Unless a super type is marked with @Entity
>> or @MappedSuperclass, the "attributes" defined on that specific class are
>> not picked up.
>>
>> Maybe I'm misunderstanding you?
>>
>> On Mon, Dec 9, 2019 at 1:58 PM Gail Badner  wrote:
>>
>>> Hi,
>>>
>>> Suppose we have the following:
>>>
>>> public class CompositeKey implements Serializable {
>>>
>>>   private Long id1;
>>>
>>>   private Long id2;
>>>
>>>   public CompositeKey(Long id1, Long id2) {
>>> super();
>>> this.id1 = id1;
>>> this.id2 = id2;
>>>   }
>>> ...
>>> }
>>> public class InheritedKey extends CompositeKey {
>>>
>>>   private Long id3;
>>>
>>>   public InheritedKey(Long id1, Long id2, Long id3) {
>>> super(id1, id2);
>>> this.id3 = id3;
>>>   }
>>> ...
>>> }
>>>
>>> @Entity(name = "IKE")
>>> @IdClass(InheritedKey.class)public class InheritedKeyEntity {
>>>
>>>   @Id
>>>   private Long id1;
>>>
>>>   @Id
>>>   private Long id2;
>>>
>>>   @Id
>>>   private Long id3;
>>>
>>>   private String name;
>>> ...
>>> }
>>>
>>>
>>> Currently, Hibernate does not include InheritedKey#id3 in
>>> InheritedKeyEntity's composite key unless InheritedKey is annotated with
>>> @MappedSuperclass.
>>>
>>> I think there are some improvements that can be made.
>>>
>>> 1) As you can see, the entity, itself, has all of the ID fields
>>> annotated.
>>> An improvement would be for Hibernate to ensure that all mapped ID
>>> properties have been detected, and throw an exception if this is not the
>>> case.
>>>
>>> 2) A class used as an IdClass does not need any annotations (as opposed
>>> to
>>> a class used for an EmbeddedId class, which requires {{@Embeddable}}).
>>> Since the class used as an IdClass does not need to be annotated, it
>>> seems
>>> kind of strange that its superclass would need to be annotated with
>>> {{@MappedSuperclass}} in order for its fields/properties to be
>>> persistent.
>>> Since the field/property names must match what is annotated in an
>>> IdClass,
>>> it is clear that the field/property in a superclass is intended to be an
>>> ID. Perhaps we could make annotating the superclass with
>>> {{@MappedSuperclass}} optional?
>>>
>>> Opinions?
>>>
>>> Thanks,
>>> Gail
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] IdClass superclasses

[Gail Badner]

Hi,

Suppose we have the following:

public class CompositeKey implements Serializable {

  private Long id1;

  private Long id2;

  public CompositeKey(Long id1, Long id2) {
super();
this.id1 = id1;
this.id2 = id2;
  }
...
}
public class InheritedKey extends CompositeKey {

  private Long id3;

  public InheritedKey(Long id1, Long id2, Long id3) {
super(id1, id2);
this.id3 = id3;
  }
...
}

@Entity(name = "IKE")
@IdClass(InheritedKey.class)public class InheritedKeyEntity {

  @Id
  private Long id1;

  @Id
  private Long id2;

  @Id
  private Long id3;

  private String name;
...
}


Currently, Hibernate does not include InheritedKey#id3 in
InheritedKeyEntity's composite key unless InheritedKey is annotated with
@MappedSuperclass.

I think there are some improvements that can be made.

1) As you can see, the entity, itself, has all of the ID fields annotated.
An improvement would be for Hibernate to ensure that all mapped ID
properties have been detected, and throw an exception if this is not the
case.

2) A class used as an IdClass does not need any annotations (as opposed to
a class used for an EmbeddedId class, which requires {{@Embeddable}}).
Since the class used as an IdClass does not need to be annotated, it seems
kind of strange that its superclass would need to be annotated with
{{@MappedSuperclass}} in order for its fields/properties to be persistent.
Since the field/property names must match what is annotated in an IdClass,
it is clear that the field/property in a superclass is intended to be an
ID. Perhaps we could make annotating the superclass with
{{@MappedSuperclass}} optional?

Opinions?

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

[Gail Badner]

Hi Steve,

I like your ideas about loading an entity with multiple ID attributes
without @IdClass. It's much nicer than passing an instance of the entity
with ID attributes initialized to Session#get.

Getting back to the cache issue -- it sounds like disassembling the ID is
worth pursuing.

Please confirm...

Thanks,
Gail

On Thu, Dec 5, 2019 at 9:33 AM Steve Ebersole  wrote:

> > JPA does not allow mixing of @IdClass and @EmbeddedId.  But I think
>> that's a valid option.  In fact in our original work on 6 where we
>> completely replaced the mapping model (persisters) i had added support for
>> this.  We could add an improvement to pull this feature to 6 proper?
>>
>> There would be some rough edges (what would
>> org.hibernate.Session#getIdentifier return, the embedded id or the idclass?
>> What would Session.load accept? What would be the declared type of the ID
>> in JPA Criteria?). But that could be a valuable feature for people who
>> really want composite IDs. And it could solve the caching problem.
>> However, if we need to solve the caching problem in ORM 5 and are not in
>> a position to declare that caching isn't supported for such identifiers...
>> then we'll have to work on some hack in ORM 5. So maybe it's not a priority
>> in ORM 6.
>>
>
> `Session#getIdentifier` would return the embedded-id, imo.  The
> embedded-id is the "real" id.  The id-class is just a simplified "syntactic
> sugar" used only for an alternative form of loading.  In fact for an entity
> with an id-class you can load using either approach, though the legacy form
> of loading an entity with a non-aggregated composite id is truly painful.
>
> Just spit-balling, one option would be to expose a even more simplified
> loading for these entities using `Session#byId` (or a new similar method)
> allowing specifying the simplified, basic "maps-id" values for the load.
> Just for illustration, something like:
>
> session.byCompositeId( EntityWithCompositeId.class )
> .using( "idAttribute1", "idAttribute1-value" )
> .using( "keyManyToOne", "keyManyToOne-basic-id-value" )
> ...
> .load();
>
> That's geared toward non-aggregated composite id cases, though really it
> could be available in aggregated composite id cases as well.
>
> We could also allow a form in normal load-by-id using a Map maybe?  I only
> mention this as even though its still a "new feature", it does not require
> any API changes or new APIs.
>
> final Map idValues = new HashMap();
> idValues.put( "idAttribute1", "idAttribute1-value" );
> idValues.put( "keyManyToOne", "keyManyToOne-basic-id-value" );
> ...
> session.get( EntityWithCompositeId.class, idValues );
>
> Or even an "array Map" option to avoid the Map instantiation:
>
> final Object[] idValues = new Object[] {
> "idAttribute1", "idAttribute1-value",
> "keyManyToOne", "keyManyToOne-basic-id-value",
> ...
> };
> assert idValues.length %2 == 0;
> session.get( EntityWithCompositeId.class, idValues );
>
> Of course, if the embedded-id could also have an id-class you'd use that.
>
> I'd like to see all of these as options btw, not one-or-the-other.
> Though I'm fine if no-one else likes the `Session#byCompositeId` idea.
> It was just a spur-of-the-moment idea.
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Cache key containing composite ID with a many-to-one

[Gail Badner]

Hi Sanne,

By default, the cache key is of type CacheKeyImplementation [1]. As long as
a composite key is a ComponentType (not a CustomType),
CacheKeyImplementation#equals and #hashCode uses ComponentType#equals and
#hashCode, not the custom implementation of the embeddable class methods.

IIRC, a CustomType cannot contain an association, so disassembling a custom
type should not be necessary.

Steve, does that sound right to you?

I believe that what you mentioned above does apply to "simple" cache keys,
where the cache key is the ID itself. There are other cases where a simple
cache key is not appropriate (e.g., multiple entity classes with the same
type of ID). I don't remember offhand if there are warnings logged in those
cases. We could warn if an application attempted to use a simple cache key
with a cacheable entity that has a composite key with an association.

Regarding B -- it is not possible to assemble the ID when
calling CacheKeyImplementation#equals or #hashCode, because
a CacheKeyImplementation does not have a reference to a Session, so it
cannot resolve an associated entity. In any case, there should be no need
to assemble an associated entity. It should be sufficient to for the
disassembled entity ID to be used for #equals and #hashCode operations.

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/CacheKeyImplementation.java



On Wed, Dec 4, 2019 at 2:03 PM Sanne Grinovero  wrote:

> Hi Gail,
>
> going for a disassembled ID would seem logical, but we'll need some
> special care to deal with custom implementations of equals/hashcode.
>
> Clearly a composite ID object would require the users to implement a
> custom equals(); going for a solution based on a disassembled ID we
> would need to either:
>
> A# trust the equals implementation is "the obvious one"
>
> B# hydrate both sides of the equals check for each time there's need
> to invoke an equals (and same for hashcode)
>
> I'm afraid only B would be backwards compatible and bullet-proof, and
> yet its performance overhead would make it a terrible choice.
>
> Perhaps the best solution is to constrain this, and warn that such a
> model is not a good fit for caching?
>
> Unless someone has a better idea; thinking out of the box: could be
> interesting to explore not allowing users to implement custom equality
> contracts as that's the root of many problems, but that would require
> much more careful thought, and for sure a significant breaking change.
>
> Or allow people to implement any custom equals, but ignore them and
> apply "the obvious one" consistently.
>
> Thanks,
> Sanne
>
>
>
> On Wed, 4 Dec 2019 at 19:40, Gail Badner  wrote:
> >
> > When an entity is cached with a composite ID containing a many-to-one
> > association, the cache key will contain the many-to-one associated
> entity.
> > If the associated entity is not enhanced, then it could be an
> uninitialized
> > proxy.
> >
> > I've created a test case [1] that illustrates this using Infinispan. The
> > test case is for 5.1 branch, since hibernate-infinispan is still included
> > in that branch. The same would happen for master as well.
> >
> > Aside from the obvious issue with increased memory requirements to store
> an
> > entity, there are other problems as well.
> >
> > What I've found so far is that caching a key with an uninitialized entity
> > proxy can cause some big problems:
> >
> > 1) A lookup will never find this key unless the lookup is done with a
> cache
> > key containing the same entity proxy instance.
> >
> > 2) Calling EntityManager#find with a composite ID containing a detached
> > uninitialized entity proxy will result in a LazyInitializationException.
> > This does not happen with second-level cache disabled.
> >
> > 3) Calling EntityManager#find with a composite ID containing a managed
> > uninitialized entity proxy will result in the proxy being initialized.
> This
> > does not happen with second-level cache disabled.
> >
> > I have not looked into what happens when the associated entity is
> enhanced
> > and uninitialized (i.e., enhancement-as-proxy).
> >
> > IIUC, disassembling the ID that gets stored in the cache key would be far
> > more efficient, and would avoid these issues. We would only want to do
> this
> > when a composite ID contains an association. This would require changes
> in
> > some SPIs though, to account for the disassembled ID type.
> >
> > I've been discussing necessary changes with Scott to cache a
> > disassembled ID. Before we get too far 

[hibernate-dev] Cache key containing composite ID with a many-to-one

[Gail Badner]

When an entity is cached with a composite ID containing a many-to-one
association, the cache key will contain the many-to-one associated entity.
If the associated entity is not enhanced, then it could be an uninitialized
proxy.

I've created a test case [1] that illustrates this using Infinispan. The
test case is for 5.1 branch, since hibernate-infinispan is still included
in that branch. The same would happen for master as well.

Aside from the obvious issue with increased memory requirements to store an
entity, there are other problems as well.

What I've found so far is that caching a key with an uninitialized entity
proxy can cause some big problems:

1) A lookup will never find this key unless the lookup is done with a cache
key containing the same entity proxy instance.

2) Calling EntityManager#find with a composite ID containing a detached
uninitialized entity proxy will result in a LazyInitializationException.
This does not happen with second-level cache disabled.

3) Calling EntityManager#find with a composite ID containing a managed
uninitialized entity proxy will result in the proxy being initialized. This
does not happen with second-level cache disabled.

I have not looked into what happens when the associated entity is enhanced
and uninitialized (i.e., enhancement-as-proxy).

IIUC, disassembling the ID that gets stored in the cache key would be far
more efficient, and would avoid these issues. We would only want to do this
when a composite ID contains an association. This would require changes in
some SPIs though, to account for the disassembled ID type.

I've been discussing necessary changes with Scott to cache a
disassembled ID. Before we get too far down this road, I'd like to get some
feedback.

In the first place, should an entity instance be stored in a cache key?

Is disassembling primary keys that contain an association the appropriate
way to go? If so, I'll continue with a POC for doing this.

Thanks,
Gail

[1]
https://github.com/gbadner/hibernate-core/blob/753e36edf5137296d28b2a07cee3daffc16c6d1e/hibernate-infinispan/src/test/java/org/hibernate/test/cache/infinispan/CacheKeysWithEagerEntityFactoryTest.java
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.3.14 Released

[Gail Badner]

https://in.relation.to/2019/11/08/hibernate-orm-5314-final-out/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release Hibernate ORM 5.3.14

[Gail Badner]

Please do not push anything to 5.3.

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Narrowed HibernateProxy and Uninitialized bytecode-enhanced entities do not get detached

[Gail Badner]

Hi,

I seem to remember this topic came when we were working on the
enhancement-as-proxy feature.

Basically, EnhancementAsProxyLazinessInterceptor#session does not get
nullified when the PersistenceContext gets cleared.

As a result, such an entity can still get initialized if
the SharedSessionContractImplementor is still open.

I also noticed that narrowed proxies are never added to the
PersistenceContext, but they still have a reference to
the SharedSessionContractImplementor from which the narrowed proxy
originated. These references never get nullified either.

I believe these are both bugs, and I would like to address them.

Please let me know if I'm missing something here.

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] "JDK: oraclejdk8 Java" check is failing for a PR

[Gail Badner]

It passed this time. :)

On Tue, Oct 15, 2019 at 2:51 PM Gail Badner  wrote:

> OK, I see it now.
>
> Thanks!
> Gail
>
> On Tue, Oct 15, 2019 at 2:24 PM Steve Ebersole 
> wrote:
>
>> Yes, in the upper right end corner there is a "Restart Job" link...
>> That's for any Travis job
>>
>> On Tue, Oct 15, 2019 at 1:20 PM Gail Badner  wrote:
>>
>>> "JDK: oraclejdk8 Java" check is failing [1] for PR:
>>> https://github.com/hibernate/hibernate-orm/pull/3066
>>>
>>> It's showing that OsgiIntegrationTest is failing. I can't reproduce this
>>> locally, but maybe I'm not using the same version of
>>>
>>> Has anyone else seen this before?
>>>
>>> Is there a way to repeat the job to see if it is transient?
>>>
>>> Thanks,
>>> Gail
>>>
>>> [1] https://travis-ci.org/hibernate/hibernate-orm/jobs/597997496
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] "JDK: oraclejdk8 Java" check is failing for a PR

[Gail Badner]

OK, I see it now.

Thanks!
Gail

On Tue, Oct 15, 2019 at 2:24 PM Steve Ebersole  wrote:

> Yes, in the upper right end corner there is a "Restart Job" link...
> That's for any Travis job
>
> On Tue, Oct 15, 2019 at 1:20 PM Gail Badner  wrote:
>
>> "JDK: oraclejdk8 Java" check is failing [1] for PR:
>> https://github.com/hibernate/hibernate-orm/pull/3066
>>
>> It's showing that OsgiIntegrationTest is failing. I can't reproduce this
>> locally, but maybe I'm not using the same version of
>>
>> Has anyone else seen this before?
>>
>> Is there a way to repeat the job to see if it is transient?
>>
>> Thanks,
>> Gail
>>
>> [1] https://travis-ci.org/hibernate/hibernate-orm/jobs/597997496
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] "JDK: oraclejdk8 Java" check is failing for a PR

[Gail Badner]

"JDK: oraclejdk8 Java" check is failing [1] for PR:
https://github.com/hibernate/hibernate-orm/pull/3066

It's showing that OsgiIntegrationTest is failing. I can't reproduce this
locally, but maybe I'm not using the same version of

Has anyone else seen this before?

Is there a way to repeat the job to see if it is transient?

Thanks,
Gail

[1] https://travis-ci.org/hibernate/hibernate-orm/jobs/597997496
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.3.12.Final Released

[Gail Badner]

https://in.relation.to/2019/09/11/hibernate-orm-5312-final-out/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Starting Hibernate ORM 5.3.12 release

[Gail Badner]

Please don't push anything to 5.3 branch.

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-13317

[Gail Badner]

I see. HHH-13317 is a valid mapping, and the types do match, so it is a
separate issue.

On Tue, Sep 10, 2019 at 8:54 PM Luis Barreiro  wrote:

> Hello Gail,
>
> The code in question deals with the detection of bi-directional
> associations and only affects that feature.
>
> What happens currently is that in certain situations fields are matched
> (based on the value of mappedBy) but the types don't actually match,
> leading to either the failure of enhancement or the generated code is
> invalid.
>
> Again, this has nothing to do with lazy loading or dirty tracking.
>
> Regards,
>
> Luis Barreiro
>
> Middleware Performance Team
> <https://red.ht/sig>
> On 9/9/19 10:55 PM, Gail Badner wrote:
>
> Hi Luis,
>
> IIUC, HHH-13446 deals with a mappedBy="" value that is invalid. I'm
> confused why the test in the PR is passing. Shouldn't an exception be
> thrown?
>
> HHH-13317 deals with a mappedBy value that is an association in an
> embeddable, which is valid.
>
> I know that Hibernate does not support a lazy association in an embeddable
> with bytecode enhancement. IIRC, we expect the association in the
> embeddable will not be lazy. It shouldn't thrown an exception though.
>
> Luis, could you please shed some light on this?
>
> Thanks,
> Gail
>
> On Thu, Sep 5, 2019 at 5:14 PM Gail Badner  wrote:
>
>> I'll take a look. Thanks Luis!
>>
>>
>>
>> On Thu, Sep 5, 2019 at 3:02 PM Luis Barreiro 
>> wrote:
>>
>>> Hello Gail,
>>>
>>> Without looking with much detail, this seems to be the same as HHH-13446.
>>>
>>> There is a PR for that for some time now:
>>> https://github.com/hibernate/hibernate-orm/pull/2919
>>>
>>> If it's the same issue, it should be fixed. While Javassist fails when
>>> enhancing the classes, ByteBuddy succeeds but the resulting classes are
>>> invalid.
>>>
>>> Regards,
>>>
>>> Luis Barreiro
>>>
>>> Middleware Performance Team
>>> <https://red.ht/sig>
>>> On 9/5/19 10:54 PM, Gail Badner wrote:
>>>
>>> HHH-13317 is specifically a bug with bytecode enhancement using Javassist.
>>>
>>> It showed up when running a test added for HHH-13241.
>>>
>>> I've verified that the same issue affected 5.1, so this is not a regression.
>>>
>>> Is it worthwhile to fix this issue in 5.3/5.4? Will Javassist continue to
>>> be supported in Hibernate ORM 6? If not, I'd like to close HHH-13317 as
>>> "Won't fix".
>>>
>>> Thanks,
>>> Gail
>>> ___
>>> hibernate-dev mailing 
>>> listhibernate-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.3.12 needs to support JDK13

[Gail Badner]

Hi,

WildFly 18 supports JDK 13, so Hibernate ORM 5.3.12 will also need to
support JDK 13.

We know that ByteBuddy needs to be upgraded to 1.9.11. That will be covered
by HHH-13504 [1]

Andrea mentioned HHH-13415 [2] should be backported as well.

Grepping through the log for jdk, I see these other issues that were
resolved in master, but not 5.3:

https://hibernate.atlassian.net/browse/HHH-12946
https://hibernate.atlassian.net/browse/HHH-13022
https://hibernate.atlassian.net/browse/HHH-13069
https://hibernate.atlassian.net/browse/HHH-13043
https://hibernate.atlassian.net/browse/HHH-13128
https://hibernate.atlassian.net/browse/HHH-13127
https://hibernate.atlassian.net/browse/HHH-13271
https://hibernate.atlassian.net/browse/HHH-13275
https://hibernate.atlassian.net/browse/HHH-13419
https://hibernate.atlassian.net/browse/HHH-13421
https://hibernate.atlassian.net/browse/HHH-13409

Did I miss anything?

Could someone please determine which of these need to be backported?

Better yet, could someone please create a pull request for 5.3?

I specifically need to know about any component upgrades that will be
required besides ByteBuddy, so I can clear it with WildFly folks.

I need to get 5.3.12 released in the next couple of days at the latest. I
am aiming for tomorrow, but I'm really not sure what it would entail for
Hibernate ORM 5.3 to support JDK 13.

Help would be very much appreciated.

Thanks!
Gail

[1] https://hibernate.atlassian.net/browse/HHH-13504
[2] https://hibernate.atlassian.net/browse/HHH-13415
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-13317

[Gail Badner]

Hi Luis,

IIUC, HHH-13446 deals with a mappedBy="" value that is invalid. I'm
confused why the test in the PR is passing. Shouldn't an exception be
thrown?

HHH-13317 deals with a mappedBy value that is an association in an
embeddable, which is valid.

I know that Hibernate does not support a lazy association in an embeddable
with bytecode enhancement. IIRC, we expect the association in the
embeddable will not be lazy. It shouldn't thrown an exception though.

Luis, could you please shed some light on this?

Thanks,
Gail

On Thu, Sep 5, 2019 at 5:14 PM Gail Badner  wrote:

> I'll take a look. Thanks Luis!
>
>
>
> On Thu, Sep 5, 2019 at 3:02 PM Luis Barreiro  wrote:
>
>> Hello Gail,
>>
>> Without looking with much detail, this seems to be the same as HHH-13446.
>>
>> There is a PR for that for some time now:
>> https://github.com/hibernate/hibernate-orm/pull/2919
>>
>> If it's the same issue, it should be fixed. While Javassist fails when
>> enhancing the classes, ByteBuddy succeeds but the resulting classes are
>> invalid.
>>
>> Regards,
>>
>> Luis Barreiro
>>
>> Middleware Performance Team
>> <https://red.ht/sig>
>> On 9/5/19 10:54 PM, Gail Badner wrote:
>>
>> HHH-13317 is specifically a bug with bytecode enhancement using Javassist.
>>
>> It showed up when running a test added for HHH-13241.
>>
>> I've verified that the same issue affected 5.1, so this is not a regression.
>>
>> Is it worthwhile to fix this issue in 5.3/5.4? Will Javassist continue to
>> be supported in Hibernate ORM 6? If not, I'd like to close HHH-13317 as
>> "Won't fix".
>>
>> Thanks,
>> Gail
>> ___
>> hibernate-dev mailing 
>> listhibernate-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-13317

[Gail Badner]

I'll take a look. Thanks Luis!



On Thu, Sep 5, 2019 at 3:02 PM Luis Barreiro  wrote:

> Hello Gail,
>
> Without looking with much detail, this seems to be the same as HHH-13446.
>
> There is a PR for that for some time now:
> https://github.com/hibernate/hibernate-orm/pull/2919
>
> If it's the same issue, it should be fixed. While Javassist fails when
> enhancing the classes, ByteBuddy succeeds but the resulting classes are
> invalid.
>
> Regards,
>
> Luis Barreiro
>
> Middleware Performance Team
> <https://red.ht/sig>
> On 9/5/19 10:54 PM, Gail Badner wrote:
>
> HHH-13317 is specifically a bug with bytecode enhancement using Javassist.
>
> It showed up when running a test added for HHH-13241.
>
> I've verified that the same issue affected 5.1, so this is not a regression.
>
> Is it worthwhile to fix this issue in 5.3/5.4? Will Javassist continue to
> be supported in Hibernate ORM 6? If not, I'd like to close HHH-13317 as
> "Won't fix".
>
> Thanks,
> Gail
> ___
> hibernate-dev mailing 
> listhibernate-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HHH-13317

[Gail Badner]

HHH-13317 is specifically a bug with bytecode enhancement using Javassist.

It showed up when running a test added for HHH-13241.

I've verified that the same issue affected 5.1, so this is not a regression.

Is it worthwhile to fix this issue in 5.3/5.4? Will Javassist continue to
be supported in Hibernate ORM 6? If not, I'd like to close HHH-13317 as
"Won't fix".

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] No default implementation for PersistenceContext#addEnhancedProxy

[Gail Badner]

Ok, thanks!

On Tue, Sep 3, 2019 at 6:01 AM Steve Ebersole  wrote:

> We do not support an application implementing a custom
> PersistenceContext.
>
> I'm not against adding a default, but most likely that default would be a
> "throw an exception" type which I am not sure is useful
>
> On Mon, Sep 2, 2019 at 4:19 PM Gail Badner  wrote:
>
>> HHH-11147 added PersistenceContext#addEnhancedProxy without a default
>> implementation.
>>
>> Would an application implement PersistenceContext? If so, this would be a
>> breaking change.
>>
>> Please let me know...
>>
>> Thanks,
>> Gail
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] EntityMetamodel

[Gail Badner]

Ok, thanks.

On Tue, Sep 3, 2019 at 6:09 AM Steve Ebersole  wrote:

> Seems like we dropped the need for the subclass checking here but did not
> remove passing that Function.  Technically it could be removed and the 
> EntityMetamodel
> constructor reverted
>
> On Mon, Sep 2, 2019 at 9:14 PM Gail Badner  wrote:
>
>> HHH-11147 changed a EntityMetamodel constructor argument from
>> a SessionFactoryImplementor to a PersisterCreationContext.
>>
>> Would a custom EntityPersister break due to calling the constructor with
>> the new argument type?
>>
>> From what I can tell, the argument was changed to
>> PersisterCreationContext go get access to an entity's metamodel, intended
>> to be used by EnhancementHelper.includeInBaseFetchGroup.
>>
>> The Function subclassChecker is passed to:
>> * BytecodeEnhancementMetadataPojoImpl.from
>> * LazyAttributesMetadata.from
>> * EnhancementHelper.includeInBaseFetchGroup
>>
>> EnhancementHelper.includeInBaseFetchGroup does not use the value passed
>> in for hasSubclassChecker.
>>
>> Can the EntityMetamodel constructor be changed back to take a
>> SessionFactoryImplementor?
>>
>> Can the hasSubclassChecker argument be removed from
>> BytecodeEnhancementMetadataPojoImpl.from, LazyAttributesMetadata.from, and
>> EnhancementHelper.includeInBaseFetchGroup?
>>
>> Thanks,
>> Gail
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] EntityMetamodel

[Gail Badner]

HHH-11147 changed a EntityMetamodel constructor argument from
a SessionFactoryImplementor to a PersisterCreationContext.

Would a custom EntityPersister break due to calling the constructor with
the new argument type?

>From what I can tell, the argument was changed to PersisterCreationContext
go get access to an entity's metamodel, intended to be used
by EnhancementHelper.includeInBaseFetchGroup.

The Function subclassChecker is passed to:
* BytecodeEnhancementMetadataPojoImpl.from
* LazyAttributesMetadata.from
* EnhancementHelper.includeInBaseFetchGroup

EnhancementHelper.includeInBaseFetchGroup does not use the value passed in
for hasSubclassChecker.

Can the EntityMetamodel constructor be changed back to take a
SessionFactoryImplementor?

Can the hasSubclassChecker argument be removed from
BytecodeEnhancementMetadataPojoImpl.from, LazyAttributesMetadata.from, and
EnhancementHelper.includeInBaseFetchGroup?

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Property#isLazy

[Gail Badner]

HHH-11147 changed Property#isLazy as shown in [1].

The part that concerns me is:

+ // For a many-to-one, this is always false.  Whether the
+ // association is EAGER, PROXY or NO-PROXY we want the fk
+ // selected
+ return false;

I don't think this is correct when enhancement-as-proxy is disabled.

Join#isLazy relies on Property#isLazy for the properties included in the
Join.

If Join#isLazy is returning the wrong value,
then SingleTableEntityPersister#isSubclassTableLazy
and JoinedSubclassEntityPersister#isSubclassTableLazy will return the wrong
value.

Steve, WDYT?

Thanks,
Gail

[1]
https://github.com/hibernate/hibernate-orm/commit/cc01f2561dbca95bd58048f85e283ba1719ee588#diff-f564326e8dae92695cdffe6509fb8f0b
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] No default implementation for PersistenceContext#addEnhancedProxy

[Gail Badner]

HHH-11147 added PersistenceContext#addEnhancedProxy without a default
implementation.

Would an application implement PersistenceContext? If so, this would be a
breaking change.

Please let me know...

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] hibernate.id.optimizer.pooled.preferred=hilo or legacy-hilo

[Gail Badner]

I agree completely.
Thanks,
Gail

On Wed, Aug 28, 2019 at 5:09 AM Steve Ebersole 
wrote:

> In my opinion we really should not drop them unless we also write a
> conversion for the existing I'd values in the database to account for the
> new scheme the user picks.  It's really just left there to allow these
> legacy databases keep working
>
> On Wed, Aug 28, 2019, 12:08 AM Gail Badner  wrote:
>
>> Hi,
>>
>> The documentation for hibernate.id.optimizer.pooled.preferred says the
>> following:
>>
>> hilo; legacy-hilo
>>
>> Define a custom algorithm for generating pools of values based on a single
>> value from a table or sequence.
>>
>> These optimizers are not recommended for use. They are maintained (and
>> mentioned) here simply for use by legacy applications that used these
>> strategies previously.
>>
>> Will these settings be supported long-term, or are there plans to
>> deprecate/remove them?
>>
>> Thanks,
>> Gail
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] hibernate.id.optimizer.pooled.preferred=hilo or legacy-hilo

[Gail Badner]

Hi,

The documentation for hibernate.id.optimizer.pooled.preferred says the
following:

hilo; legacy-hilo

Define a custom algorithm for generating pools of values based on a single
value from a table or sequence.

These optimizers are not recommended for use. They are maintained (and
mentioned) here simply for use by legacy applications that used these
strategies previously.

Will these settings be supported long-term, or are there plans to
deprecate/remove them?

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Entity implementation of equals()

[Gail Badner]

Please see below...

On Tue, Aug 27, 2019 at 8:00 PM Jan-Willem Gmelig Meyling <
jan-wil...@youngmediaexperts.nl> wrote:

> I tend to use this.getClass().isInstance(o) and this.getClass().cast(o)
> which works even in a mapped super class on most occasions. (Assuming that
> the proxy delegates equals to a concrete target).
>

Your suggestion worked to get past the class comparison.

There is still an issue though when comparing to a HibernateProxy.

This returns false: bID.equals( that.bID).

This returns true: bID.equals( that.getbID() ).

I've never noticed this before.

Steve, is there some requirement that getters have be used to compare
properties when an entity can be lazy?


>
> Jan-Willem
>
>
> > Op 27 aug. 2019 om 22:29 heeft Steve Ebersole  het
> volgende geschreven:
> >
> > Generally speaking an `#equals` method would not allow subclasses to
> > match.  For entity mappings specifically I this it is generally
> considered
> > kosher to allow subclass matching in `#equals`.  Interestingly, when
> > generating `#equals` overrides through IntelliJ it even asks specifically
> > whether subclasses should be allowed to match.  In fact it mentions (or
> > used to mention) Hibernate specifically wrt proxies in the dialog.
> >
> > And it's actually required (as you found) if you want to use Hibernate's
> > proxy-based lazy loading.
>

It makes sense, but I don't remember reading it. Is this documented
somewhere?

HHH-13590 specifically has to do with an entity's #equals(Object o) with o
being a HibernateProxy.

The fix unproxies the HibernateProxy, so that the argument to
#equals(Object o) is the target (not a HibernateProxy).

Thanks,
Gail

>
> > However, this is a case with a MappedSuperclass and specifically a
> > MappedSupperclass that is I guess shared amongst multiple root entities.
> > So here the allowance of subclasses is not really feasible and relying on
> > any kind of equality checking defined on the MappedSuperclass is not
> going
> > to work
> >
> >> On Tue, Aug 27, 2019 at 6:49 PM Gail Badner  wrote:
> >>
> >> Hi,
> >>
> >> I'm looking into the impact of HHH-13590.
> >>
> >> In the test for HHH-13590, I see that the mapped superclass entity
> defines
> >> equals() as:
> >>
> >> @Override
> >> public boolean equals(Object o) {
> >>   if (this == o) return true;
> >>   if (o == null || getClass() != o.getClass()) return false;
> >>
> >>   ...
> >>
> >> }
> >>
> >> Due to the bug:
> >> * this is a Project instance;
> >> * o is a HibernateProxy with target == this.
> >>
> >> Because the getClass() != o.getClass(), false is returned, and that
> >> ultimately causes the test to fail.
> >>
> >> The fix for HHH-13590 results in comparing a Project instance with
> itself
> >> (not the proxy).
> >>
> >> I see that the documentation has a similar implementation of equals() in
> >> "Example 111. Natural Id equals/hashCode" of [1].
> >>
> >> In general, is it OK for equals() to require both instances to be of the
> >> same class?
> >>
> >> Thanks,
> >> Gail
> >>
> >> [1]
> >>
> >>
> https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#mapping-model-pojo-equalshashcode
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Entity implementation of equals()

[Gail Badner]

Hi,

I'm looking into the impact of HHH-13590.

In the test for HHH-13590, I see that the mapped superclass entity defines
equals() as:

@Override
public boolean equals(Object o) {
   if (this == o) return true;
   if (o == null || getClass() != o.getClass()) return false;

   ...

}

Due to the bug:
* this is a Project instance;
* o is a HibernateProxy with target == this.

Because the getClass() != o.getClass(), false is returned, and that
ultimately causes the test to fail.

The fix for HHH-13590 results in comparing a Project instance with itself
(not the proxy).

I see that the documentation has a similar implementation of equals() in
"Example 111. Natural Id equals/hashCode" of [1].

In general, is it OK for equals() to require both instances to be of the
same class?

Thanks,
Gail

[1]
https://docs.jboss.org/hibernate/orm/5.4/userguide/html_single/Hibernate_User_Guide.html#mapping-model-pojo-equalshashcode
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ConnectionObserver

[Gail Badner]

In 4.2 and 4.3, it was possible to add a ConnectionObserver
using 
org.hibernate.engine.jdbc.spi.LogicalConnectionImplementor#addObserver(ConnectionObserver
observer).

Starting in 5.0, LogicalConnectionImplementor was moved
to org.hibernate.resource.jdbc.spi, and it's no longer possible to add a
ConnectionObserver.

For now, I think it's OK to change JdbcObserverImpl#observers from a
List, to:

private final transient ConnectionObserver observer;

Also, I'm fine with ConnectionObserver being deprecated, and later removed.

Steve, WDYT?


On Tue, Aug 20, 2019 at 10:55 AM Sanne Grinovero 
wrote:

> While refactoring some related optimisations, I noticed there's
> currently no way to register a custom ConnectionObserver.
>
> There seems to be only one implementation, which is registered by default:
>  -
> org.hibernate.internal.ConnectionObserverStatsBridge#ConnectionObserverStatsBridge
>
> Some questions:
>
> # Is this expected?
>
> # Should we deprecate the SPI so to make this more explict in the
> future, and possibly eventually discuss removing it?
>
> # Since I'm working on performance optimisations, may I take advantage
> currently of the fact that there's only one registered? We're
> currently iterating "the list of obeservers"...
>
> Thanks
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] API removal proposal: org.hibernate.resource.jdbc.ResourceRegistry#cancelLastQuery

[Gail Badner]

Hi Sanne,

I've confirmed that current versions of WildFly and EAP do not call that
ResourceRegistry#cancelLastQuery.

ResourceRegistry was introduced in 5.0. As of 5.0.16, cancelLastQuery() is
not used by Hibernate ORM.

At least as far back as 4.2, SessionImpl#cancelQuery
called JdbcCoordinator#cancelLastQuery(), which deals with
JdbcCoordinatorImpl#lastQuery (not ResourceRegistry#cancelLastQuery).

I believe that an application could only reach ResourceRegistry through an
SPI ; for example, via
* SharedSessionContractImplementor.getJdbcCoordinator().getResourceRegistry
(deprecated since 5.2);
or
*SharedSessionContractImplementor.getJdbcCoordinator().getLogicalConnection.getResourceRegistry().

My preference is to follow our normal process for removing an SPI.

In general, we try not to remove SPIs within a minor release (e.g., 7.x).
We normally deprecate the method in 7.x. The soonest we would remove it
would be in 7.x+1.

Regards,
Gail

On Fri, Aug 16, 2019 at 10:17 AM Sanne Grinovero 
wrote:

> Hi all,
>
> is this method needed?
>
>  - org.hibernate.resource.jdbc.ResourceRegistry#cancelLastQuery
>
> It seems undocumented, untested, and everything compiles just fine if
> I just delete it - however it seems marked as API.
>
> But also, I suppose this should be invoked by a different thread as
> the one actually running the query? Which would imply this
> implementation would need to be threadsafe, but it's not.
>
> My primary reason to explore its removal though is that this method is
> in the way of some optimisations I'd like to apply to this class, so
> it would be quite useful for me to be able to remove it - assuming
> that it's no longer of interest to anyone else.
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.3.11.Final released

[Gail Badner]

For details:
https://in.relation.to/2019/08/15/hibernate-orm-5311-final-out/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Starting release process for ORM 5.3.11.Final

[Gail Badner]

Please don't push anything to 5.3 branch.

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Suggestions for fixing HHH-13570?

[Gail Badner]

I chatted with Andrea about this.

I'll skip the test using @RequiresDialectFeature( value
= DialectChecks.SupportsLockTimeouts.class )


On Tue, Aug 13, 2019 at 6:45 PM Gail Badner  wrote:

> An alternative is to mark the tests with:
>
> @RequiresDialectFeature( value = DialectChecks.SupportsLockTimeouts.class )
>
> since SybaseASE15Dialect#supportsLockTimeouts returns false.
>
>
> On Tue, Aug 13, 2019 at 6:29 PM Gail Badner  wrote:
>
>> LockModeTest executes the following SQL for Sybase and SQL Server:
>>
>> UPDATE T_LOCK_A WITH(NOWAIT) SET a_value = :value where id = :id";
>>
>> This fails on Sybase, because it doesn't recognize WITH(NOWAIT).
>>
>> If I remove WITH(NOWAIT), the statement blocks until Junit times out.
>>
>> I'm having trouble finding some equivalent to WITH(NOWAIT) for Sybase.
>> Does anyone know if there is one?
>>
>> Should I just skip this test for Sybase?
>>
>> Thanks,
>> Gail
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Suggestions for fixing HHH-13570?

[Gail Badner]

An alternative is to mark the tests with:

@RequiresDialectFeature( value = DialectChecks.SupportsLockTimeouts.class )

since SybaseASE15Dialect#supportsLockTimeouts returns false.


On Tue, Aug 13, 2019 at 6:29 PM Gail Badner  wrote:

> LockModeTest executes the following SQL for Sybase and SQL Server:
>
> UPDATE T_LOCK_A WITH(NOWAIT) SET a_value = :value where id = :id";
>
> This fails on Sybase, because it doesn't recognize WITH(NOWAIT).
>
> If I remove WITH(NOWAIT), the statement blocks until Junit times out.
>
> I'm having trouble finding some equivalent to WITH(NOWAIT) for Sybase.
> Does anyone know if there is one?
>
> Should I just skip this test for Sybase?
>
> Thanks,
> Gail
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Suggestions for fixing HHH-13570?

[Gail Badner]

LockModeTest executes the following SQL for Sybase and SQL Server:

UPDATE T_LOCK_A WITH(NOWAIT) SET a_value = :value where id = :id";

This fails on Sybase, because it doesn't recognize WITH(NOWAIT).

If I remove WITH(NOWAIT), the statement blocks until Junit times out.

I'm having trouble finding some equivalent to WITH(NOWAIT) for Sybase. Does
anyone know if there is one?

Should I just skip this test for Sybase?

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Preparing to release Hibernate ORM 5.4.4

[Gail Badner]

Please do not push anything to master until the release is finished.

Regards,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] How to add Weblinks w/ new HHH Jira view?

[Gail Badner]

I see this is already covered by
https://jira.atlassian.com/browse/JRACLOUD-70211.

On Sun, Jul 14, 2019 at 11:41 PM Yoann Rodiere  wrote:

> No idea because I switched back to the old view, but you're able to file a
> report to Atlassian when switching back to the old view. I'd advise you to
> do just that, so that hopefully they improve the new view before removing
> the old one.
>
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
>
> On Sat, 13 Jul 2019 at 02:15, Gail Badner  wrote:
>
>> I see that the new Jira view allows issue links to be added easily.
>>
>> With the old view, I could add a Weblink (basically just a generic
>> hyperlink). I don't see how to do that with the new view. Does something
>> need to be added to provide that functionality?
>>
>> For now, I can go back to the old view to link JBEAP issues. I'm concerned
>> I will lose ability when the view gets updated again.
>>
>> Could someone please let me know how to find or add that functionality?
>>
>> Thanks,
>> Gail
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] How to add Weblinks w/ new HHH Jira view?

[Gail Badner]

I see that the new Jira view allows issue links to be added easily.

With the old view, I could add a Weblink (basically just a generic
hyperlink). I don't see how to do that with the new view. Does something
need to be added to provide that functionality?

For now, I can go back to the old view to link JBEAP issues. I'm concerned
I will lose ability when the view gets updated again.

Could someone please let me know how to find or add that functionality?

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] hibernate.jpa.compliance.caching and nullable secondary tables

[Gail Badner]

The Javadoc for JpaCompliance#isJpaCacheComplianceEnabled says:

* @implNote Effects include marking all secondary tables as non-optional.
The reason

* being that optional secondary tables can lead to entity cache being
invalidated rather
* than updated.

But, the way it's used is the opposite (marks all secondary tables as
optional): [1]
isNullableTable[j] = join.isOptional()
 || creationContext.getSessionFactory()

 .getSessionFactoryOptions()
   .getJpaCompliance()

 .isJpaCacheComplianceEnabled();

Even if a secondary table is explicitly mapped as non-optional using
@org.hibernate.annotations.Table(appliesTo=...,optional=false),
when hibernate.jpa.compliance.caching=true, Hibernate assumes that
secondary tables are nullable. This causes an outer join to be used in
queries, when an inner join could be used instead.

The property was added by HHH-12282 [2], which also mentions that the
intention is to mark all tables as non-optional. HHH-12282 also has a
comment [3] that says:

"I think its safe enough here to simply say that compliance means we omit
the table-span check at all."

Should the determination of whether a table is nullable depends only
on org.hibernate.mapping.Join#isOptional, like the following?

isNullableTable[j] = join.isOptional();

JpaCompliance().isJpaCacheComplianceEnabled() == true would still skip
invalidation.

WDYT?

Regards,
Gail

[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/persister/entity/SingleTableEntityPersister.java#L181-L185
[2] https://hibernate.atlassian.net/browse/HHH-12282
[3]
https://hibernate.atlassian.net/browse/HHH-12282?focusedCommentId=101168&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-101168
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-11147 - bytecode based "proxies"

[Gail Badner]

Hi Steve,

We had discussed releasing in 5.4, and possibly 5.3, with the default
for hibernate.bytecode.allow_enhancement_as_proxy=false. I am in favor of
this.

Are you suggesting that the default behavior would effectively be to set
hibernate.bytecode.allow_enhancement_as_proxy=true in 5.5?

Do you think there would be any need to be able to restore the earlier
behavior in 5.5? IOW, would we even need the property in 5.5?

Regards,
Gail

On Mon, May 13, 2019 at 10:11 AM Sanne Grinovero 
wrote:

> Hi Steve,
>
> like Christian, I would probably target ORM 6, but it's up to you.
>
> If you would rather recommend a 5.5 to get these improvements out
> earlier, I have no objections and can help with that.
>
> Thanks,
> Sanne
>
> On Mon, 13 May 2019 at 16:20, Christian Beikov
>  wrote:
> >
> > +1 for 6
> >
> > Am 13.05.2019 um 15:25 schrieb Steve Ebersole:
> > > Over the last 3 weeks or so, we have put a lot of work into HHH-11147
> which
> > > essentially allows bytecode enhancement to behave like the more
> traditional
> > > proxy feature (create a reference based solely on the entity id).
> > >
> > > We are wrapping up development of that improvement, enhancement,
> change,
> > > whatever-you-want-to-call-it...  One remaining question however is how
> to
> > > make this change available in terms of releases.  It seems to big of a
> deal
> > > to simply drop in a new bug-fix release.
> > >
> > > Should we consider a 5.5 release?  Push it to 6?  Thoughts?
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 5.3.10.Final released

[Gail Badner]

Sorry, I referenced the incorrect release announcement in my previous
email. It should have been:
http://in.relation.to/2019/04/22/hibernate-orm-5310-final-out/

On Mon, Apr 22, 2019 at 2:27 PM Gail Badner  wrote:

> http://in.relation.to/2019/02/19/hibernate-orm-538-final-out/
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.3.10.Final released

[Gail Badner]

http://in.relation.to/2019/02/19/hibernate-orm-538-final-out/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-13364

[Gail Badner]

Thanks Andrea!

On Fri, Apr 12, 2019 at 3:43 AM andrea boriero  wrote:

> I gave a look at your PR and the change makes sense to me
>
> Andrea
>
> On Fri, 12 Apr 2019 at 03:54, Gail Badner  wrote:
>
>> EntityManager#find and Query#getResultList / #getSingleResult do not
>> behave
>> consistently when failing to get a pessimistic lock with a timeout
>> provided.
>>
>> I think EntityManager#find is working correctly, and I think
>> Query#getResultList / #getSingleResult should be consistent with
>> EntityManager#find.
>>
>> Could someone please take a look at HHH-13364 and let me know if I'm
>> missing something?
>>
>> I've also created a pull request with tests and fix:
>> https://github.com/hibernate/hibernate-orm/pull/2827
>>
>> Thanks,
>> Gail
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HHH-13364

[Gail Badner]

EntityManager#find and Query#getResultList / #getSingleResult do not behave
consistently when failing to get a pessimistic lock with a timeout provided.

I think EntityManager#find is working correctly, and I think
Query#getResultList / #getSingleResult should be consistent with
EntityManager#find.

Could someone please take a look at HHH-13364 and let me know if I'm
missing something?

I've also created a pull request with tests and fix:
https://github.com/hibernate/hibernate-orm/pull/2827

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Make Gradle plugin available on plugins.gradle.org? (HHH-13354)

[Gail Badner]

An issue was opened to make Gradle plugin available on plugins.gradle.org.

Should this be done? If so, how?

Regards,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

[Gail Badner]

PR: https://github.com/hibernate/hibernate-orm/pull/2825

On Thu, Mar 28, 2019 at 1:49 PM Gail Badner  wrote:

> Hi Guillaume,
>
> I've confirmed that my fix gets the WildFly tests to pass. I've created
> https://hibernate.atlassian.net/browse/HHH-13343.
>
> I'm not sure I understand what you are suggesting by "default behavior".
>
> My proposed fix implements a ClassFileLocator checks if the bytecode
> Hibernate is attempting to enhance is the provided bytecode (by default).
>
> Are you suggesting that ByteBuddy should provide a ClassFileLocator
> implementation that does this?
>
> I'm getting a master PR set up. The tricky bit is to come up with a
> Hibernate unit test that can reproduce this. Scott suggested trying to
> enhance byte code that has already been enhanced, since the enhanced
> bytecode would not be available from the ClassLoader. I'm giving this a
> try.
>
> I will (hopefully) have a PR for master branch shortly.
>
> Regards,
> Gail
>
> On Thu, Mar 28, 2019 at 10:58 AM Guillaume Smet 
> wrote:
>
>> Hi Gail,
>>
>> Thanks for looking into this.
>>
>> Your commit is interesting as we had people in Quarkus complaining about
>> the fact that it was not possible to chain the ORM enhancer after other
>> enhancers as it didn't consider the provided bytes as the "source" to
>> consider.
>>
>> I wonder if what you did (i.e. considering the provided bytes) should be
>> the default behavior.
>>
>> On Thu, Mar 28, 2019 at 7:13 AM Gail Badner  wrote:
>>
>>> Hi Guillaume,
>>>
>>> Unfortunately, it is not so easy.
>>>
>>> typeDescription is of type
>>> TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get
>>> completely resolved until later.
>>>
>>> I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here
>>> is the commit [2].
>>>
>>> I haven't had a chance to try the other tests in Scott's PR. I'll give
>>> them a try tomorrow.
>>>
>>> I did not create a Hibernate issue for this yet because I'm not sure if
>>> Hibernate should be working around this issue.
>>>
>>> It's getting late for me tonight. I'll continue tomorrow.
>>>
>>> Comments are welcome.
>>>
>>> Regards,
>>> Gail
>>>
>>> [1] https://github.com/gbadner/hibernate-core/tree/WFLY-11891-5.3
>>> [2]
>>> https://github.com/gbadner/hibernate-core/commit/ef1687807def94a4465d6cf2372f9235dc559bd1
>>>
>>> On Tue, Mar 26, 2019 at 10:11 AM Gail Badner  wrote:
>>>
>>>> Guillaume, thanks for the suggestion. I'll give it a try...
>>>>
>>>> On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet <
>>>> guillaume.s...@gmail.com> wrote:
>>>>
>>>>> I would try changing the start of EnhancerImpl#enhance() to:
>>>>> ===
>>>>> public byte[] enhance(String className, byte[] originalBytes)
>>>>> throws
>>>>> EnhancementException {
>>>>> //Classpool#describe does not accept '/' in the description
>>>>> name as
>>>>> it expects a class name. See HHH-12545
>>>>> final String safeClassName = className.replace( '/', '.' );
>>>>> try {
>>>>> final Resolution typeResolution = typePool.describe(
>>>>> safeClassName );
>>>>> if ( !typeResolution.isResolved() ) {
>>>>> return null;
>>>>> }
>>>>>
>>>>> final TypeDescription typeDescription =
>>>>> typeResolution.resolve();
>>>>> ===
>>>>>
>>>>> i.e. testing the resolution of the type.
>>>>>
>>>>> That might fix it.
>>>>>
>>>>> --
>>>>> Guillaume
>>>>>
>>>>> On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow 
>>>>> wrote:
>>>>>
>>>>> > Thinking more about this, I don't think that ByteBuddy should be
>>>>> able to
>>>>> > do a classloader.getResource() on the class that is being defined
>>>>> > (SLSBPersistenceContexts$$$view5.class).  It might be correct for the
>>>>> > getResource call to return null, until after the class is completely
>>>>>

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

[Gail Badner]

Hi Guillaume,

I've confirmed that my fix gets the WildFly tests to pass. I've created
https://hibernate.atlassian.net/browse/HHH-13343.

I'm not sure I understand what you are suggesting by "default behavior".

My proposed fix implements a ClassFileLocator checks if the bytecode
Hibernate is attempting to enhance is the provided bytecode (by default).

Are you suggesting that ByteBuddy should provide a ClassFileLocator
implementation that does this?

I'm getting a master PR set up. The tricky bit is to come up with a
Hibernate unit test that can reproduce this. Scott suggested trying to
enhance byte code that has already been enhanced, since the enhanced
bytecode would not be available from the ClassLoader. I'm giving this a
try.

I will (hopefully) have a PR for master branch shortly.

Regards,
Gail

On Thu, Mar 28, 2019 at 10:58 AM Guillaume Smet 
wrote:

> Hi Gail,
>
> Thanks for looking into this.
>
> Your commit is interesting as we had people in Quarkus complaining about
> the fact that it was not possible to chain the ORM enhancer after other
> enhancers as it didn't consider the provided bytes as the "source" to
> consider.
>
> I wonder if what you did (i.e. considering the provided bytes) should be
> the default behavior.
>
> On Thu, Mar 28, 2019 at 7:13 AM Gail Badner  wrote:
>
>> Hi Guillaume,
>>
>> Unfortunately, it is not so easy.
>>
>> typeDescription is of type
>> TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get
>> completely resolved until later.
>>
>> I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here
>> is the commit [2].
>>
>> I haven't had a chance to try the other tests in Scott's PR. I'll give
>> them a try tomorrow.
>>
>> I did not create a Hibernate issue for this yet because I'm not sure if
>> Hibernate should be working around this issue.
>>
>> It's getting late for me tonight. I'll continue tomorrow.
>>
>> Comments are welcome.
>>
>> Regards,
>> Gail
>>
>> [1] https://github.com/gbadner/hibernate-core/tree/WFLY-11891-5.3
>> [2]
>> https://github.com/gbadner/hibernate-core/commit/ef1687807def94a4465d6cf2372f9235dc559bd1
>>
>> On Tue, Mar 26, 2019 at 10:11 AM Gail Badner  wrote:
>>
>>> Guillaume, thanks for the suggestion. I'll give it a try...
>>>
>>> On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet 
>>> wrote:
>>>
>>>> I would try changing the start of EnhancerImpl#enhance() to:
>>>> ===
>>>> public byte[] enhance(String className, byte[] originalBytes) throws
>>>> EnhancementException {
>>>> //Classpool#describe does not accept '/' in the description
>>>> name as
>>>> it expects a class name. See HHH-12545
>>>> final String safeClassName = className.replace( '/', '.' );
>>>> try {
>>>> final Resolution typeResolution = typePool.describe(
>>>> safeClassName );
>>>> if ( !typeResolution.isResolved() ) {
>>>> return null;
>>>> }
>>>>
>>>> final TypeDescription typeDescription =
>>>> typeResolution.resolve();
>>>> ===
>>>>
>>>> i.e. testing the resolution of the type.
>>>>
>>>> That might fix it.
>>>>
>>>> --
>>>> Guillaume
>>>>
>>>> On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow 
>>>> wrote:
>>>>
>>>> > Thinking more about this, I don't think that ByteBuddy should be able
>>>> to
>>>> > do a classloader.getResource() on the class that is being defined
>>>> > (SLSBPersistenceContexts$$$view5.class).  It might be correct for the
>>>> > getResource call to return null, until after the class is completely
>>>> > defined.
>>>> >
>>>> > Would it make sense for the above condition (cl.getResource()
>>>> returning
>>>> > null) be detected differently in the callstack [1] and just fall
>>>> through
>>>> > + return to the caller?
>>>> >
>>>> > Scott
>>>> >
>>>> > [1]
>>>> https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd
>>>> >
>>>> > On 3/26/19 9:53 AM, Scott Marlow wrote:
>>>> > > Hi Tomek,
>>>> &

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

[Gail Badner]

Hi Guillaume,

Unfortunately, it is not so easy.

typeDescription is of type
TypePool$Default$WithLazyResolution$LazyTypeDescription, and it doesn't get
completely resolved until later.

I've pushed a branch [1] that seems to work for MultiplePuTestCase. Here is
the commit [2].

I haven't had a chance to try the other tests in Scott's PR. I'll give them
a try tomorrow.

I did not create a Hibernate issue for this yet because I'm not sure if
Hibernate should be working around this issue.

It's getting late for me tonight. I'll continue tomorrow.

Comments are welcome.

Regards,
Gail

[1] https://github.com/gbadner/hibernate-core/tree/WFLY-11891-5.3
[2]
https://github.com/gbadner/hibernate-core/commit/ef1687807def94a4465d6cf2372f9235dc559bd1

On Tue, Mar 26, 2019 at 10:11 AM Gail Badner  wrote:

> Guillaume, thanks for the suggestion. I'll give it a try...
>
> On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet 
> wrote:
>
>> I would try changing the start of EnhancerImpl#enhance() to:
>> ===
>> public byte[] enhance(String className, byte[] originalBytes) throws
>> EnhancementException {
>> //Classpool#describe does not accept '/' in the description name
>> as
>> it expects a class name. See HHH-12545
>> final String safeClassName = className.replace( '/', '.' );
>> try {
>> final Resolution typeResolution = typePool.describe(
>> safeClassName );
>> if ( !typeResolution.isResolved() ) {
>> return null;
>> }
>>
>> final TypeDescription typeDescription =
>> typeResolution.resolve();
>> ===
>>
>> i.e. testing the resolution of the type.
>>
>> That might fix it.
>>
>> --
>> Guillaume
>>
>> On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow  wrote:
>>
>> > Thinking more about this, I don't think that ByteBuddy should be able to
>> > do a classloader.getResource() on the class that is being defined
>> > (SLSBPersistenceContexts$$$view5.class).  It might be correct for the
>> > getResource call to return null, until after the class is completely
>> > defined.
>> >
>> > Would it make sense for the above condition (cl.getResource() returning
>> > null) be detected differently in the callstack [1] and just fall through
>> > + return to the caller?
>> >
>> > Scott
>> >
>> > [1]
>> https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd
>> >
>> > On 3/26/19 9:53 AM, Scott Marlow wrote:
>> > > Hi Tomek,
>> > >
>> > > I think the pending question now is why ByteBuddy is getting a null
>> > > result from the
>> > >
>> >
>> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
>> >
>> > > call.
>> > >
>> > > We have also seen failures for
>> > > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which
>> is
>> > > also generated by the EJB container (see exception call stack in
>> > > https://issues.jboss.org/browse/WFLY-11891).
>> > >
>> > > I wonder if this could be an ordering bug where classes generated via
>> > > JBoss ClassFileWriter are added to the classloader list of classes,
>> > > before the actual bytecode is added.
>> > >
>> > > Scott
>> > >
>> > > On 3/26/19 9:17 AM, Tomasz Adamski wrote:
>> > >> Hi Scott,
>> > >>
>> > >> Added to my TODO. WIll try to look at it this week.
>> > >>
>> > >> Regards,
>> > >> Tomek
>> > >>
>> > >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow > > >> <mailto:smar...@redhat.com>> wrote:
>> > >>
>> > >> Adding Tomek + Cheng, as they have been working on the WildFly
>> EJB
>> > >> layer
>> > >>     recently, which seems to use
>> > >> https://github.com/jbossas/jboss-classfilewriter for generating
>> > >> the EJB
>> > >> stub classes like
>> > >>
>> > >>
>> >
>> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class.
>> >
>> > >>
>> > >>
>> > >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or
>> > >> B

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

[Gail Badner]

Guillaume, thanks for the suggestion. I'll give it a try...

On Tue, Mar 26, 2019 at 9:59 AM Guillaume Smet 
wrote:

> I would try changing the start of EnhancerImpl#enhance() to:
> ===
> public byte[] enhance(String className, byte[] originalBytes) throws
> EnhancementException {
> //Classpool#describe does not accept '/' in the description name as
> it expects a class name. See HHH-12545
> final String safeClassName = className.replace( '/', '.' );
> try {
> final Resolution typeResolution = typePool.describe(
> safeClassName );
> if ( !typeResolution.isResolved() ) {
> return null;
> }
>
> final TypeDescription typeDescription =
> typeResolution.resolve();
> ===
>
> i.e. testing the resolution of the type.
>
> That might fix it.
>
> --
> Guillaume
>
> On Tue, Mar 26, 2019 at 5:39 PM Scott Marlow  wrote:
>
> > Thinking more about this, I don't think that ByteBuddy should be able to
> > do a classloader.getResource() on the class that is being defined
> > (SLSBPersistenceContexts$$$view5.class).  It might be correct for the
> > getResource call to return null, until after the class is completely
> > defined.
> >
> > Would it make sense for the above condition (cl.getResource() returning
> > null) be detected differently in the callstack [1] and just fall through
> > + return to the caller?
> >
> > Scott
> >
> > [1] https://gist.github.com/scottmarlow/0e74cd16d7229812261b7c14e452b3cd
> >
> > On 3/26/19 9:53 AM, Scott Marlow wrote:
> > > Hi Tomek,
> > >
> > > I think the pending question now is why ByteBuddy is getting a null
> > > result from the
> > >
> >
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
> >
> > > call.
> > >
> > > We have also seen failures for
> > > org.jboss.as.ejb3.SerializationProxyHackImplementation as well, which
> is
> > > also generated by the EJB container (see exception call stack in
> > > https://issues.jboss.org/browse/WFLY-11891).
> > >
> > > I wonder if this could be an ordering bug where classes generated via
> > > JBoss ClassFileWriter are added to the classloader list of classes,
> > > before the actual bytecode is added.
> > >
> > > Scott
> > >
> > > On 3/26/19 9:17 AM, Tomasz Adamski wrote:
> > >> Hi Scott,
> > >>
> > >> Added to my TODO. WIll try to look at it this week.
> > >>
> > >> Regards,
> > >> Tomek
> > >>
> > >> On Mon, Mar 25, 2019 at 5:14 PM Scott Marlow  > >> <mailto:smar...@redhat.com>> wrote:
> > >>
> > >> Adding Tomek + Cheng, as they have been working on the WildFly EJB
> > >> layer
> > >> recently, which seems to use
> > >> https://github.com/jbossas/jboss-classfilewriter for generating
> > >> the EJB
> > >> stub classes like
> > >>
> > >>
> >
> org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class.
> >
> > >>
> > >>
> > >> Perhaps Tomek or Cheng, can answer whether WildFly (EJB layer) or
> > >> ByteBuddy should change to handle dynamically generated classes
> > >> differently.
> > >>
> > >> In other words, should ByteBuddy respond differently to
> > >>
> > >>
> >
> classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class")
> >
> > >>
> > >>
> > >> returning null or should the jboss-classfilewriter project somehow
> > >> avoid
> > >> this bug.
> > >>
> > >> Scott
> > >>
> > >> On 3/22/19 2:54 AM, Gail Badner wrote:
> > >>  > Scott added bytecode enhancement to some WildFly tests for
> > >> WFLY-11891 [1],
> > >>  > which are failing.
> > >>  >
> > >>  > Here is Scott's PR with the updated tests: [2]
> > >>  >
> > >>  > When I stepped into
> > >>  >
> > >>
> > >>
> >
> org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase,
> >
>

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

[Gail Badner]

Should dynamically generated classes be possible to load from a ClassLoader
by a name like
org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class
?

On Fri, Mar 22, 2019 at 12:34 PM Scott Marlow  wrote:

>
> On 3/22/19 1:53 PM, Gail Badner wrote:
> > I just wanted to clarify that sometimes I was seeing problems with
> > SerializationProxyHackImplementation. When debugging, I usually saw a
> > failure on SLSBPersistenceContexts$$$viewX, where (IIRC) X was between 1
> > and 9.
>
> I'm guessing that the SLSBPersistenceContexts$$$viewX classes are
> generated by the WildFly EJB container, for the (test) application EJB
> bean org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts.
>
> I'm not sure why the failure is varying between different classes.  For
> the weird org.jboss.as.ejb3.SerializationProxyHackImplementation
> failure, SerializationProxyHackImplementation is a dynamically generated
> server class apparently, that comes from
>
> https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/iiop/handle/SerializationHackProxy.java#L57
>
> Scott
>
> >
> > On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow  > <mailto:smar...@redhat.com>> wrote:
> >
> >
> >
> > On 3/22/19 10:08 AM, Scott Marlow wrote:
> >  >
> >  >
> >  > On 3/22/19 9:24 AM, Scott Marlow wrote:
> >  >>
> >  >>
> >  >> On 3/22/19 9:11 AM, Scott Marlow wrote:
> >  >>>
> >  >>>
> >  >>> On 3/22/19 7:49 AM, Guillaume Smet wrote:
> >  >>>> Hi Gail,
> >  >>>>
> >  >>>> Do we have any idea of what this class is supposed to be:
> >  >>>>
> >
>  org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5
> >  >>>> ?
> >  >>>
> >  >>> This is a unit test class that is not an entity class, but
> > instead it
> >  >>> happens to be an EJB stateless session bean.  In the exception
> > call
> >  >>> stack [1], the class that ByteBuddy complains about is a WildFly
> >  >>> class (not even a test class), you can see that in the exception
> >  >>> message SerializationProxyHackImplementation [2].
> >  >>>
> >  >>>> Scott, any idea?
> >  >>>
> >  >>> I was not really aware that classes like
> >  >>> SerializationProxyHackImplementation [2] , would also be
> > handled by
> >  >>>
> >
>  
> org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform()
> >
> >  >>> but I guess that makes sense, as application classloaders versus
> >  >>> application module classloaders, are not distinguished
> > internally in WF.
> >  >>
> >  >> I meant that class file transformers will be called for both
> >  >> application classes and WF classes as well.
> >  >
> >  > I'm going to see if I can hack around this failure in WF code, so
> > that
> >  > WF doesn't call into Hibernate to transform the
> >  > org.jboss.as.ejb3.SerializationProxyHackImplementation class.
> >
> > I tried changing
> >
>  
> org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform()
> >
> > to filter out any non-application classes but that didn't help as
> > DelegatingClassFileTransformer.transform() doesn't get called to
> > transform the SerializationProxyHackImplementation [2] class.
> >
> > It might be that the application classes are getting injected with a
> > classloader that references the SerializationProxyHackImplementation
> > [2]
> > class.
> >
> > IMO, this probably should be fixed in Hibernate ORM or ByteBuddy.
> >
> >  >
> >  >>
> >  >>>
> >  >>> I'm also not sure of how Javassist handles ignoring the
> >  >>> SerializationProxyHackImplementation [2] class but Javassist
> does
> >  >>> work fine (as long as you work around the other issue, which is
> > that
> >  >>> Javassist can only be selected via system property setting but
> not
> >  >>> persistence.xml setting, also mentioned in WFLY-11891 [3]).
> >  >>>
> >  >&

Re: [hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

[Gail Badner]

I just wanted to clarify that sometimes I was seeing problems with
SerializationProxyHackImplementation. When debugging, I usually saw a
failure on SLSBPersistenceContexts$$$viewX, where (IIRC) X was between 1
and 9.

On Fri, Mar 22, 2019 at 7:22 AM Scott Marlow  wrote:

>
>
> On 3/22/19 10:08 AM, Scott Marlow wrote:
> >
> >
> > On 3/22/19 9:24 AM, Scott Marlow wrote:
> >>
> >>
> >> On 3/22/19 9:11 AM, Scott Marlow wrote:
> >>>
> >>>
> >>> On 3/22/19 7:49 AM, Guillaume Smet wrote:
>  Hi Gail,
> 
>  Do we have any idea of what this class is supposed to be:
> 
> org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5
>  ?
> >>>
> >>> This is a unit test class that is not an entity class, but instead it
> >>> happens to be an EJB stateless session bean.  In the exception call
> >>> stack [1], the class that ByteBuddy complains about is a WildFly
> >>> class (not even a test class), you can see that in the exception
> >>> message SerializationProxyHackImplementation [2].
> >>>
>  Scott, any idea?
> >>>
> >>> I was not really aware that classes like
> >>> SerializationProxyHackImplementation [2] , would also be handled by
> >>>
> org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform()
>
> >>> but I guess that makes sense, as application classloaders versus
> >>> application module classloaders, are not distinguished internally in
> WF.
> >>
> >> I meant that class file transformers will be called for both
> >> application classes and WF classes as well.
> >
> > I'm going to see if I can hack around this failure in WF code, so that
> > WF doesn't call into Hibernate to transform the
> > org.jboss.as.ejb3.SerializationProxyHackImplementation class.
>
> I tried changing
> org.jboss.as.server.deployment.module.DelegatingClassFileTransformer.transform()
>
> to filter out any non-application classes but that didn't help as
> DelegatingClassFileTransformer.transform() doesn't get called to
> transform the SerializationProxyHackImplementation [2] class.
>
> It might be that the application classes are getting injected with a
> classloader that references the SerializationProxyHackImplementation [2]
> class.
>
> IMO, this probably should be fixed in Hibernate ORM or ByteBuddy.
>
> >
> >>
> >>>
> >>> I'm also not sure of how Javassist handles ignoring the
> >>> SerializationProxyHackImplementation [2] class but Javassist does
> >>> work fine (as long as you work around the other issue, which is that
> >>> Javassist can only be selected via system property setting but not
> >>> persistence.xml setting, also mentioned in WFLY-11891 [3]).
> >>>
> 
>  Because it doesn't ring a bell on my side.
> 
>  I suspect it's a class we shouldn't access or touch. And we should
>  probably
>  add a condition somewhere to avoid doing so.
> >>>
> >>> Agreed.
> >>>
> 
>  If you can give me the Hibernate call which initiates the error,
>  that would
>  be nice.
> >>>
> >>> [1] shows the exception call stack (look for
> >>>
> "org.hibernate.bytecode.enhance.internal.bytebuddy.EnhancerImpl.lambda$enhance$0(EnhancerImpl.java:137)"
>
> >>>
> >>>
> >>>
> 
>  And stupid question: we did not have any enhancement test in WildFly
>  before
>  that?
> 
> >>>
> >>> No, sadly, this is the first time we updated the WildFly unit tests
> >>> to try Javassist + ByteBuddy enhancement.  Its a very light test with
> >>> little verification, basically we just modified some existing tests
> >>> to include:
> >>>
> >>> hibernate.enhancer.enableDirtyTracking=true
> >>> hibernate.enhancer.enableLazyInitialization=true
> >>> hibernate.enhancer.enableAssociationManagement=true
> >>>
> >>> And one test was also modified to specify
> >>> hibernate.bytecode.provider=javassist, which is ignored (only the
> >>> system property works, via standalone.sh
> >>> -Dhibernate.bytecode.provider=javassist).  The problem is also
> >>> mentioned in WFLY-11891 [3].
> >>>
> >>> In WF, we also have a mock persistence provider test that ensures
> >>> that persistence providers can enhance classes as per the JPA
> >>> container contract.
> >>>
> >>> Scott
> >>>
> >>> [1]
> >>>
> https://issues.jboss.org/browse/WFLY-11891?focusedCommentId=13711809&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13711809
> >>>
> >>>
> >>> [2] java.lang.IllegalStateException: Cannot resolve type description
> >>> for org.jboss.as.ejb3.SerializationProxyHackImplementation
> >>>
> >>> [3] https://issues.jboss.org/browse/WFLY-11891
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] WildFly tests with ByteBuddy enhancement are failing

[Gail Badner]

Scott added bytecode enhancement to some WildFly tests for WFLY-11891 [1],
which are failing.

Here is Scott's PR with the updated tests: [2]

When I stepped into
org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase,
I can see that they are failing in ByteBuddy code.

I see that:

   -  enhancement of
   org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts gets
   skipped several times in a row;
   - enhancement of some other classes get skipped;
   - before trying to enhance
   org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5, an
   exception is thrown.

Unfortunately, I'm having trouble getting a good stacktrace to show what
happens in ByteBuddy code.

Here is what I'm seeing:

net.bytebuddy.pool.TypePool$Default.doDescribe("org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")
/* class name differs from run to run */


calls net.bytebuddy.dynamic.ClassFileLocator$ForClassLoader.locate( "
org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5")

calls net.bytebuddy.dynamic.ClassFileLocator.ForClassLoader.locate(
classLoader, 
"org.jboss.as.test.integration.jpa.basic.SLSBPersistenceContexts$$$view5"
)

calls
classLoader.getResourceAsStream("org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"),
which returns null;

(I don't actually see a class file with this name)


returns new TypePool.Resolution.Illegal(

"org/jboss/as/test/integration/jpa/basic/SLSBPersistenceContexts$$$view5.class"

)

returns TypePool.Resolution.Illegal


Ultimately, TypePool.Resolution.Illegal#resolve( ) throws
IllegalStateException, because the type description cannot be resolved.

I'm not sure if the problem is in WildFly, Hibernate, or ByteBuddy.

To build WildFly:
./build.sh clean install -DskipTests=true

To run the test:
cd testsuite/integration/basic
mvn install
-Dtest=org/jboss/as/test/integration/jpa/basic/multiplepersistenceunittest/MultiplePuTestCase

Help would be very much appreciated.

Thanks,
Gail

[1] https://issues.jboss.org/browse/WFLY-11891
[2] https://github.com/wildfly/wildfly/pull/12180
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [ORM] Converging on 5.4.2

[Gail Badner]

On Mon, Mar 4, 2019 at 2:31 AM Guillaume Smet 
wrote:

> Hi,
>
> I'm busy on other things these days but I would like to release a 5.4.2
> soon anyway as we already have fixed 28 issues, some of them quite
> annoying.
>
> Gail, I think most of the remaining open PRs need your attention.
>
> If you could take a look at them, that would be great. Let's maybe take a
> timebox of a few days and postpone to the next version whatever we are not
> confident enough to merge in this timebox.
>
> - https://github.com/hibernate/hibernate-orm/pull/2799 -> this one just
> has
> a checkstyle issue, it should be simple enough
>

I need to add more tests for this one.


> - https://github.com/hibernate/hibernate-orm/pull/2800 -> the date issue,
> Yoann pushed a new version, I think it should go in so that we can gather
> feedback before thinking about backporting it
>

+1; I'll review this in the next couple of days.


> - https://github.com/hibernate/hibernate-orm/pull/2801 -> don't know
> exactly the purpose or the state of this one but it looks like it should be
> addressed
>

+1;  I'll review this in the next couple of days.


> - https://github.com/hibernate/hibernate-orm/pull/2789 -> looks like it
> fixes a corner case but we would need to be sure it's safe
>

+1;  I'll review this in the next couple of days.


> - https://github.com/hibernate/hibernate-orm/pull/2753 -> this one I'm not
> sure at all
>

I'm not sure either; I'll take a look though.

>
> Thanks.
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Upgrading Hibernate Causes null index column for collection error for List

[Gail Badner]

Hi Amit,

This mailing list is for people working on Hibernate development.

If you think you have found a bug, then please create a jira issue (
https://hibernate.atlassian.net/) and attach a test case that reproduces
your issue.

Regards,
Gail

On Fri, Feb 15, 2019 at 6:05 AM Amit Shah  wrote:

> We are trying to upgrade hibernate from version 4.3.5 to 5.4.0. With this
> the jpa version also changes from hibernate-jpa-2.1 to jpa-2.2. After the
> upgrade we get the following error when using the List<> collection with
> @OrderColumn
>
> "javax.persistence.PersistenceException: org.hibernate.HibernateException:
> null index column for collection"
>
> It is a unidirectional one-to-mapping with following annotations
>
> @Entity@Table(name = "DS_GENERIC")@PrimaryKeyJoinColumn(name =
> "DSG_DS_ID")public class GenericConnection extends
> DataSourceConnection {
>
> @OneToMany(cascade = ALL, orphanRemoval = true, fetch =
> FetchType.EAGER)
> @JoinColumn(name = "DSC_DS_ID", nullable = false)
> @OrderColumn(name = "DSC_ORDER", updatable = false, insertable = false)
> List credentials = new ArrayList<>();
> }
> @Entity@Table(name = "DS_CREDENTIALS")public class Credentials {
>
> @Id
> @GeneratedValue(generator = "uid-generator")
> @Column(name = "DSC_ID", updatable = false)
> private Long id;
>
> //...}
>
> The below test code fails
>
> //construct the connection object with credentials
> entityManager.persist(connection);
> entityManager.find(DataSourceConnection.class, id); //this call fails
> with the above error
>
> Note that this code worked fine with hibernate 4.3.5 and one workaround
> that also works is converting List to Set as below
>
> @OneToMany(cascade = ALL, orphanRemoval = true, fetch =
> FetchType.EAGER)@JoinColumn(name = "DSC_DS_ID", nullable =
> false)@OrderBy("DSC_ID")Set credentials = new
> HashSet<>();
>
> I do not understand the root cause of this failure. Any inputs would be
> appreciated.
>
> Thanks.
>
> P.S - I have posted this query on stackoverflow too
> <
> https://stackoverflow.com/questions/54686603/upgrading-hibernate-causes-null-index-column-for-collection-error-for-list
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HHH-13076

[Gail Badner]

I was looking into backporting HHH-13076 for 5.3.8.

Looking at the fix [1], I see that starting a JDBC transaction that is
already started will fail, even
if hibernate.jpa.compliance.transaction=false.

AFAICT, this didn't happen in 5.1. Was there a reason in particular why
this was done?

Thanks,
Gail

[1]
https://github.com/hibernate/hibernate-orm/commit/a15dfe0e056c55664846b621c0d880ef2e367fff
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] hibernate-tools-maven-plugin 5.4 snapshots are not being uploaded to Nexus

[Gail Badner]

Someone mentioned in a jira that hibernate-tools-maven-plugin is not
available for 5.4. snapshots. [1]

Should it be?

Regards,
Gail

[1]
https://repository.jboss.org/nexus/content/groups/public-jboss/org/hibernate/hibernate-tools-maven-plugin/
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Should the TransactionSynchronizationRegistry be cached by the JtaPlatform or perhaps at the SessionFactory level?

[Gail Badner]

Hi Scott,

I see that the issue is resolved and your commit is merged. Is this no
longer an issue?

Thanks,
Gail

On Wed, Nov 28, 2018 at 1:12 PM Scott Marlow  wrote:

> Hi,
>
> I started working on a WildFly change WFLY-11243 [1] to cache the
> TransactionSynchronizationRegistry inside of the WildFly JtaPlatform
> instance.  The purpose of caching the TransactionSynchronizationRegistry
> is to avoid repeated JndiService.locate() calls, like during entity
> manager creation time [2] and other uses as well.
>
> My question is whether the idea of caching the
> TransactionSynchronizationRegistry instance is already handled at the
> session factory level?  If not, would that make sense?
>
> [3] is the WildFly pr to cache the TransactionSynchronizationRegistry
> instance, to avoid repeatedly looking it up (since it rarely ever
> changes).  If there is a way to instead have the
> TransactionSynchronizationRegistry cached at the SF level, that might be
> better.
>
> Scott
>
> [1] https://issues.jboss.org/browse/WFLY-11243
> [2] https://paste.fedoraproject.org/paste/kXHq27RpSSs8GS8v0S8Dog
> [3] https://github.com/wildfly/wildfly/pull/11784
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.1.17.Final has been released

[Gail Badner]

This is the final release of the 5.1 series. For details see
http://in.relation.to/2018/11/28/hibernate-orm-5117-final-release/.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Can't build Hibernate ORM 5.1 documentation

[Gail Badner]

Since this is the last 5.1.x release, I don't think it's worth doing
anything more with the documentation in that branch unless absolutely
necessary.

On Wed, Nov 28, 2018 at 5:19 AM Vlad Mihalcea 
wrote:

> Hi,
>
> Form 5.2, we no longer have the DocBooks tasks.
>
> The only document using DocBook in 5.1 is the Integration Guide:
>
> http://docs.jboss.org/hibernate/orm/5.1/integrationsGuide/
>
> We converted that to AsciiDoc in 5.2
>
> http://docs.jboss.org/hibernate/orm/5.2/integrationguide/
>
> It's worth investigating whether we could remove them from 5.1 as well.
>
> Vlad
>
> On Wed, Nov 28, 2018 at 11:37 AM Gail Badner  wrote:
>
>> Andrea found a solution that works. :)
>>
>> On Tue, Nov 27, 2018 at 10:49 PM Gail Badner  wrote:
>>
>>> I'm getting ready to release 5.1.17, but I'm having trouble building the
>>> documentation.
>>>
>>> I can't even build the documentation using 5.1.16 tag. It worked fine
>>> when I released 5.1.16.Final in August.
>>>
>>> A new property was added for HHH-13011, and I need to get that
>>> documented in the user guide for 5.1.17.
>>>
>>> Here is what I'm seeing when I execute `./gradlew buildDocs`:
>>>
>>> :documentation:renderDocBook_mappingGuide_en-US_html
>>> rendering Book(mappingGuide) en-US/html
>>> Extending script classloader with the jdocbookXsl dependencies
>>> redirecting console output to file
>>> [/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log]
>>>
>>> Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd:
>>>  Error reported by XML parser: The markup declarations contained or
>>> pointed to by the document type declaration must be well-formed.
>>> Resetting console output
>>> :documentation:renderDocBook_mappingGuide_en-US_html FAILED
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * What went wrong:
>>> Execution failed for task
>>> ':documentation:renderDocBook_mappingGuide_en-US_html'.
>>> > error rendering [org.xml.sax.SAXParseException; systemId:
>>> http://docbook.org/xml/5.0/dtd/docbook.dtd; lineNumber: 1;
>>> columnNumber: 1; The markup decl
>>> arations contained or pointed to by the document type declaration must
>>> be well-formed.] on Hibernate_Mapping_Guide.xml
>>>
>>> The log file 
>>> (/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log)
>>> was empty.
>>>
>>> I'm attaching the console log from executing `./gradlew buildDocs --debug
>>> --info`.
>>>
>>> Any ideas???
>>>
>>> Thanks,
>>> Gail
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Can't build Hibernate ORM 5.1 documentation

[Gail Badner]

Andrea found a solution that works. :)

On Tue, Nov 27, 2018 at 10:49 PM Gail Badner  wrote:

> I'm getting ready to release 5.1.17, but I'm having trouble building the
> documentation.
>
> I can't even build the documentation using 5.1.16 tag. It worked fine when
> I released 5.1.16.Final in August.
>
> A new property was added for HHH-13011, and I need to get that documented
> in the user guide for 5.1.17.
>
> Here is what I'm seeing when I execute `./gradlew buildDocs`:
>
> :documentation:renderDocBook_mappingGuide_en-US_html
> rendering Book(mappingGuide) en-US/html
> Extending script classloader with the jdocbookXsl dependencies
> redirecting console output to file
> [/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log]
>
> Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd:
>  Error reported by XML parser: The markup declarations contained or
> pointed to by the document type declaration must be well-formed.
> Resetting console output
> :documentation:renderDocBook_mappingGuide_en-US_html FAILED
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task
> ':documentation:renderDocBook_mappingGuide_en-US_html'.
> > error rendering [org.xml.sax.SAXParseException; systemId:
> http://docbook.org/xml/5.0/dtd/docbook.dtd; lineNumber: 1; columnNumber:
> 1; The markup decl
> arations contained or pointed to by the document type declaration must be
> well-formed.] on Hibernate_Mapping_Guide.xml
>
> The log file 
> (/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log)
> was empty.
>
> I'm attaching the console log from executing `./gradlew buildDocs --debug
> --info`.
>
> Any ideas???
>
> Thanks,
> Gail
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Can't build Hibernate ORM 5.1 documentation

[Gail Badner]

I'm getting ready to release 5.1.17, but I'm having trouble building the
documentation.

I can't even build the documentation using 5.1.16 tag. It worked fine when
I released 5.1.16.Final in August.

A new property was added for HHH-13011, and I need to get that documented
in the user guide for 5.1.17.

Here is what I'm seeing when I execute `./gradlew buildDocs`:

:documentation:renderDocBook_mappingGuide_en-US_html
rendering Book(mappingGuide) en-US/html
Extending script classloader with the jdocbookXsl dependencies
redirecting console output to file
[/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log]

Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd:
 Error reported by XML parser: The markup declarations contained or pointed
to by the document type declaration must be well-formed.
Resetting console output
:documentation:renderDocBook_mappingGuide_en-US_html FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task
':documentation:renderDocBook_mappingGuide_en-US_html'.
> error rendering [org.xml.sax.SAXParseException; systemId:
http://docbook.org/xml/5.0/dtd/docbook.dtd; lineNumber: 1; columnNumber: 1;
The markup decl
arations contained or pointed to by the document type declaration must be
well-formed.] on Hibernate_Mapping_Guide.xml

The log file 
(/home/gbadner/git/hibernate-orm-5.1-copy/documentation/target/docbook/work/mappingGuide/log/console-en-US-html.log)
was empty.

I'm attaching the console log from executing `./gradlew buildDocs --debug
--info`.

Any ideas???

Thanks,
Gail
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM 6 branch

[Gail Badner]

That's fine with me.

On Mon, Nov 26, 2018 at 11:29 AM Steve Ebersole  wrote:

> This Wednesday we plan to release 6.0 Alpha1 and I thought it best to start
> discussing how to best handle the 6.0 and master branches.
>
> I think we should keep 6.0 a little while longer in my fork and 5.4 as
> master until 6.0 becomes more stabilized to make it easier for 5.4
> maintenance.  And reconsider as we approach Beta1.
>
> But this affects everyone, so wanted to see what others thought...
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev