[JIRA] (HHH-14052) @ManyToAny annotation transient instance error for Cascade.All
by görkem balcısoy (JIRA)
görkem balcısoy ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5bc87b3... ) *created* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMjM3OTM5ZDdl... ) / Bug ( https://hibernate.atlassian.net/browse/HHH-14052?atlOrigin=eyJpIjoiMjM3OT... ) HHH-14052 ( https://hibernate.atlassian.net/browse/HHH-14052?atlOrigin=eyJpIjoiMjM3OT... ) @ManyToAny annotation transient instance error for Cascade.All ( https://hibernate.atlassian.net/browse/HHH-14052?atlOrigin=eyJpIjoiMjM3OT... )
Issue Type: Bug Affects Versions: 5.4.15 Assignee: Unassigned Components: hibernate-core Created: 31/May/2020 06:16 AM Priority: Major Reporter: görkem balcısoy ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5bc87b3... )
I have below domain model. I added specialization entities both Product and ProductDetail entities with @ManyToAny annotation. Also, Product entity has many ProductDetail entities.
I want to save a new Product entity with one of its specializations and productDetails(with one of its specializations,too).
I use merge() method for new Product saving process, but it produces an error:
org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: com.test.model.FlyingProductDetailSpecialization.
I searched for this issue, but I cannot find anything that is different from CascadeType.ALL usage answers. I used this cascade type.
If I use persist() method for new Product saving process, it results successful. But, if I want to update this Product entity (with merge() method) with adding a productDetail with its specializations, the same TransientObjectException also occurs.
Do you have any idea about this problem? Thanks.
(BaseObject class has createDate, updateDate, id columns. I don't add this class for shortening the question.)
You can find this question at link:
https://stackoverflow.com/questions/62062582/manytoany-annotation-transie...
// Product Model
@Table(name="product")
@Entity
public class Product extends BaseObject
{ @OneToMany(mappedBy="product", cascade=CascadeType.ALL, orphanRemoval=true) @LazyCollection(LazyCollectionOption.FALSE) @JsonIgnoreProperties(value="product", allowSetters=true) private List<ProductDetail> productDetails = new ArrayList<>(); @ManyToAny(metaDef="ProductSpecMetaDef", metaColumn=@Column(name="product_specialization_type")) @LazyCollection(LazyCollectionOption.FALSE) @Cascade(org.hibernate.annotations.CascadeType.ALL) @JoinTable( name="product_specialization_relationship", joinColumns=@JoinColumn(name="product"), inverseJoinColumns=@JoinColumn(name="product_specialization") ) private List<ISpecialization<Product>> productSpecializations = new ArrayList<>(); // and some string and numerical fields }
@Table(name="unused_product_specialization")
@Entity
public class UnusedProductSpecialization extends BaseObject implements ISpecialization<Product>
{ // some string and numerical fields }
@Table(name="used_product_specialization")
@Entity
public class UsedProductSpecialization extends BaseObject implements ISpecialization<Product>{ // some string and numerical fields }
// package-info definition for ManyToAny relationship
@AnyMetaDef(name="ProductSpecMetaDef", metaType="string", idType="string",
metaValues=
{@MetaValue(value = "Unused", targetEntity=UnusedProductSpecialization.class), @MetaValue(value = "Used", targetEntity=UsedProductSpecialization.class) }
)
// End of Product Model
// Product Detail Model
@Table(name="product_detail")
@Entity
public class ProductDetail extends BaseObject
{ @ManyToOne @JoinColumn(name="product",referencedColumnName="id",nullable=false, foreignKey=@ForeignKey(name="product_detail_product_fkey")) @JsonIgnoreProperties(value="productDetails", allowSetters=true) private Product product; @ManyToAny(metaDef="ProductDetailSpecMetaDef", metaColumn=@Column(name="product_detail_specialization_type")) @LazyCollection(LazyCollectionOption.FALSE) @Cascade(org.hibernate.annotations.CascadeType.ALL) @JoinTable( name="product_detail_specialization_relationship", joinColumns=@JoinColumn(name="product_detail"), inverseJoinColumns=@JoinColumn(name="product_detail_specialization") ) private List<ISpecialization<ProductDetail>> productDetailSpecializations = new ArrayList<>(); // and some string and numerical fields }
@Table(name="flying_product_detail_specialization")
@Entity
public class FlyingProductDetailSpecialization extends BaseObject implements ISpecialization<ProductDetail>
{ // some string and numerical fields }
@Table(name="walking_product_detail_specialization")
@Entity
public class WalkingProductDetailSpecialization extends BaseObject implements ISpecialization<ProductDetail>{ // some string and numerical fields }
// package-info definition for ManyToAny relationship
@AnyMetaDef(name="ProductDetailSpecMetaDef", metaType="string", idType="string",
metaValues=
{@MetaValue(value = "Flying", targetEntity=FlyingProductDetailSpecialization.class), @MetaValue(value = "Walking", targetEntity=WalkingProductDetailSpecialization.class) }
)
// End of Product Detail Model
( https://hibernate.atlassian.net/browse/HHH-14052#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-14052#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100127- sha1:2c97aec )
3 years, 11 months
[JIRA] (HHH-14051) typesafe references to named queries, result set mappings, and entity graphs
by Gavin King (JIRA)
Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMWRlMDcyNjU2... ) / New Feature ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiMWRlMD... ) HHH-14051 ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiMWRlMD... ) typesafe references to named queries, result set mappings, and entity graphs ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiMWRlMD... )
Change By: Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... )
Currently, named queries, entity graphs, and SQL result set mappings are identified by stringly-typed keys.
It would be better if the metamodel generator would generate a typesafe element that identifies each of these things defined within a certain persistence unit. The reference can in principle even encode the result type of the query.
Thus, you would be able to write:
{{TypedQuery<Book> q = book session.createNamedQuery(NamedQueries_.bookWithAuthor);}}
Or:
{{TypedQuery<Book> q = book session.createNativeQuery(sqlQuery, ResultSetMappings_.bookWithAuthor);}}
Or:
{{Book book = session.find(Book.class, EntityGraphs_.bookWithAuthor);}}
Or whatever, and have that all be completely typesafe.
Now, a challenge for this is how to determine the "return type" for each sort of thing.
* For {{@SqlResultSetMapping}} and {{@NamedNativeQuery}}, it's explicit in the annotation.
* For {{@NamedEntityGraph}}, it could reasonably be inferred from the entity class on which the annotation occurs.
* For {{@NamedQuery}} we have a problem.
Now, the query-validator project shows how it's in-principle possible to typecheck a named JPA query at compile time, however, that approach is currently limited to Java 8.
There do seem to be some clever ways to infer the result type of a {{@NamedQuery}} in specific cases, without typechecking the entire query. For example:
* If there's more than one element in the {{select}}, it's totally trivial (must be {{Object[]}}).
* If there's no {{select}} clause at all, the problem is also pretty easy: either you've got a {{from}} with no {{join}}, in which case the thing after {{from}} is the name of the entity, or you have a {{from}} and a {{join}}, in which case you're back to {{Object[]}}.
However, for the specific case of exactly one element in the {{select}} clause, we have a problem.
So one option would be to add a result type member to the Hibernate {{@NamedQuery}} annotation, so that the user can specify it explicitly (defaulting to {{Object}}, of course).
Ultimately this would be a great feature to contribute back to the JPA spec.
( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100127- sha1:2c97aec )
3 years, 11 months
[JIRA] (HHH-14051) typesafe references to named queries, result set mappings, and entity graphs
by Gavin King (JIRA)
Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiYzUyMWQxMTkz... ) / New Feature ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiYzUyMW... ) HHH-14051 ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiYzUyMW... ) typesafe references to named queries, result set mappings, and entity graphs ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiYzUyMW... )
Change By: Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... )
Currently, named queries, entity graphs, and SQL result set mappings are identified by stringly-typed keys.
It would be better if the metamodel generator would generate a typesafe element that identifies each of these things defined within a certain persistence unit. The reference can in principle even encode the result type of the query.
Thus, you would be able to write:
{{TypedQuery<Book> q = book session.createNamedQuery(NamedQueries_.bookWithAuthor);}}
Or:
{{TypedQuery<Book> q = book session.createNativeQuery(sqlQuery, ResultSetMappings_.bookWithAuthor);}}
Or:
{{Book book = session.find(Book.class, EntityGraphs_.bookWithAuthor);}}
Or whatever, and have that all be completely typesafe.
Now, a challenge for this is how to determine the "return type" for each sort of thing.
* For {{@SqlResultSetMapping}} and {{@NamedNativeQuery}}, it's explicit in the annotation.
* For {{@NamedEntityGraph}}, it could reasonably be inferred from the entity class on which the annotation occurs.
* For {{@NamedQuery}} we have a problem.
Now, the query-validator project shows how it's in-principle possible to typecheck a named JPA query at compile time, however, that approach is currently limited to Java 8.
There do seem to be some clever ways to infer the result type of a {{@NamedQuery}} in specific cases, without typechecking the entire query. For example:
* If there's more than one element in the {{select}}, it's totally trivial (must be {{Object[]}}).
* If there's no {{select}} clause at all, the problem is also pretty easy: either you've got a {{from}} with no {{join}}, in which case the thing after {{from}} is the name of the entity, or you have a {{from}} and a {{join}}, in which case you're back to {{Object[]}}.
However, for the specific case of exactly one element in the ` {{select}} ` clause, we have a problem.
So one option would be to add a result type member to the Hibernate {{@NamedQuery}} annotation, so that the user can specify it explicitly (defaulting to {{Object}}, of course).
Ultimately this would be a great feature to contribute back to the JPA spec.
( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100127- sha1:2c97aec )
3 years, 11 months
[JIRA] (HHH-14051) typesafe references to named queries, result set mappings, and entity graphs
by Gavin King (JIRA)
Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMDhmODk5OWNl... ) / New Feature ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiMDhmOD... ) HHH-14051 ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiMDhmOD... ) typesafe references to named queries, result set mappings, and entity graphs ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiMDhmOD... )
Change By: Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... )
Currently, named queries, entity graphs, and SQL result set mappings are identified by stringly-typed keys.
It would be better if the metamodel generator would generate a typesafe element that identifies each of these things defined within a certain persistence unit. The reference can in principle even encode the result type of the query.
Thus, you would be able to write:
{{TypedQuery<Book> q = book session.createNamedQuery(NamedQueries_.bookWithAuthor);}}
Or:
{{TypedQuery<Book> q = book session.createNativeQuery(sqlQuery, ResultSetMappings_.bookWithAuthor);}}
Or:
{{Book book = session.find(Book.class, EntityGraphs_.bookWithAuthor);}}
Or whatever, and have that all be completely typesafe.
Now, a challenge for this is how to determine the "return type" for each sort of thing.
* For ` {{ @SqlResultSetMapping ` }} and ` {{ @NamedNativeQuery ` }} , it's explicit in the annotation.
* For ` {{ @NamedEntityGraph ` }} , it could reasonably be inferred from the entity class on which the annotation occurs.
* For ` {{ @NamedQuery ` }} we have a problem.
Now, the query-validator project shows how it's in-principle possible to typecheck a named JPA query at compile time, however, that approach is currently limited to Java 8.
There do seem to be some clever ways to infer the result type of a ` {{ @NamedQuery ` }} in specific cases, without typechecking the entire query. For example:
* If there's more than one element in the ` {{ select ` }} , it's totally trivial (must be ` {{ Object \ [] ` }} ).
* If there's no ` {{ select ` }} clause at all, the problem is also pretty easy: either you've got a ` {{ from ` }} with no ` {{ join ` }} , in which case the thing after ` {{ from ` }} is the name of the entity, or you have a ` {{ from ` }} and a ` {{ join ` }} , in which case you're back to ` {{ Object \ [] ` }}.
However, for the specific case of exactly one element in the ` {{ select }} ` clause, we have a problem.
So one option would be to add a result type member to the Hibernate ` {{ @NamedQuery ` }} annotation, so that the user can specify it explicitly (defaulting to ` {{ Object ` }} , of course).
Ultimately this would be a great feature to contribute back to the JPA spec.
( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100127- sha1:2c97aec )
3 years, 11 months
[JIRA] (HHH-14051) typesafe references to named queries, result set mappings, and entity graphs
by Gavin King (JIRA)
Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... ) *updated* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiOThlODEwMmE1... ) / New Feature ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiOThlOD... ) HHH-14051 ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiOThlOD... ) typesafe references to named queries, result set mappings, and entity graphs ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiOThlOD... )
Change By: Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... )
Currently, named queries, entity graphs, and SQL result set mappings are identified by stringly-typed keys.
It would be better if the metamodel generator would generate a typesafe element that identifies each of these things defined within a certain persistence unit. The reference can in principle even encode the result type of the query.
Thus, you would be able to write:
{{ TypedQuery<Book> q = book session.createNamedQuery(NamedQueries_.bookWithAuthor); }}
Or:
{{ TypedQuery<Book> q = book session.createNativeQuery(sqlQuery, ResultSetMappings_.bookWithAuthor); }}
Or:
{{ Book book = session.find(Book.class, EntityGraphs_.bookWithAuthor); }}
Or whatever, and have that all be completely typesafe.
Now, a challenge for this is how to determine the "return type" for each sort of thing.
- * For `@SqlResultSetMapping` and `@NamedNativeQuery`, it's explicit in the annotation.
- * For `@NamedEntityGraph`, it could reasonably be inferred from the entity class on which the annotation occurs.
- * For `@NamedQuery` we have a problem.
Now, the query-validator project shows how it's in-principle possible to typecheck a named JPA query at compile time, however, that approach is currently limited to Java 8.
There do seem to be some clever ways to infer the result type of a `@NamedQuery` in specific cases, without typechecking the entire query. For example:
- * If there's more than one element in the `select`, it's totally trivial (must be `Object \ []`).
- * If there's no `select` clause at all, the problem is also pretty easy: either you've got a `from` with no `join`, in which case the thing after `from` is the name of the entity, or you have a `from` and a `join`, in which case you're back to `Object \ []`.
However, for the specific case of exactly one element in the `select` clause, we have a problem.
So one option would be to add a result type member to the Hibernate `@NamedQuery` annotation, so that the user can specify it explicitly (defaulting to `Object`, of course).
Ultimately this would be a great feature to contribute back to the JPA spec.
( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100127- sha1:2c97aec )
3 years, 11 months
[JIRA] (HHH-14051) typesafe references to named queries, result set mappings, and entity graphs
by Gavin King (JIRA)
Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... ) *created* an issue
Hibernate ORM ( https://hibernate.atlassian.net/browse/HHH?atlOrigin=eyJpIjoiMzA2M2UxODc4... ) / New Feature ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiMzA2M2... ) HHH-14051 ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiMzA2M2... ) typesafe references to named queries, result set mappings, and entity graphs ( https://hibernate.atlassian.net/browse/HHH-14051?atlOrigin=eyJpIjoiMzA2M2... )
Issue Type: New Feature Assignee: Unassigned Components: hibernate-jpamodelgen Created: 31/May/2020 04:40 AM Priority: Major Reporter: Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=5ed3929... )
Currently, named queries, entity graphs, and SQL result set mappings are identified by stringly-typed keys.
It would be better if the metamodel generator would generate a typesafe element that identifies each of these things defined within a certain persistence unit. The reference can in principle even encode the result type of the query.
Thus, you would be able to write:
TypedQuery<Book> q = book session.createNamedQuery(NamedQueries_.bookWithAuthor);
Or:
TypedQuery<Book> q = book session.createNativeQuery(sqlQuery, ResultSetMappings_.bookWithAuthor);
Or:
Book book = session.find(Book.class, EntityGraphs_.bookWithAuthor);
Or whatever, and have that all be completely typesafe.
Now, a challenge for this is how to determine the "return type" for each sort of thing.
* For `@SqlResultSetMapping` and `@NamedNativeQuery`, it's explicit in the annotation.
* For `@NamedEntityGraph`, it could reasonably be inferred from the entity class on which the annotation occurs.
* For `@NamedQuery` we have a problem.
Now, the query-validator project shows how it's in-principle possible to typecheck a named JPA query at compile time, however, that approach is currently limited to Java 8.
There do seem to be some clever ways to infer the result type of a `@NamedQuery` in specific cases, without typechecking the entire query. For example:
* If there's more than one element in the `select`, it's totally trivial (must be `Object[]`).
* If there's no `select` clause at all, the problem is also pretty easy: either you've got a `from` with no `join`, in which case the thing after `from` is the name of the entity, or you have a `from` and a `join`, in which case you're back to `Object[]`.
However, for the specific case of exactly one element in the `select` clause, we have a problem.
So one option would be to add a result type member to the Hibernate `@NamedQuery` annotation, so that the user can specify it explicitly (defaulting to `Object`, of course).
Ultimately this would be a great feature to contribute back to the JPA spec.
( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-14051#add-comment?atlOrigin=ey... )
Get Jira notifications on your phone! Download the Jira Cloud app for Android ( https://play.google.com/store/apps/details?id=com.atlassian.android.jira.... ) or iOS ( https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100127- sha1:2c97aec )
3 years, 11 months