[Hibernate-JIRA] Created: (HHH-6589) Support "Any" mappings when building metamodel
by Robert Brady (JIRA)
Support "Any" mappings when building metamodel
----------------------------------------------
Key: HHH-6589
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6589
Project: Hibernate Core
Issue Type: Improvement
Components: entity-manager
Affects Versions: 3.5.6
Environment: Hibernate entity manager 3.5.5, PostgreSQL 8.4
Reporter: Robert Brady
I am upgrading from Hibernate 3.2.x to 3.5.5 and getting UnsupportedOperationExceptions thrown when Hibernate is trying to create the metamodel. This is due to the dependency of my application upon jBPM 3.x, which uses "any" mappings for some of its classes.
The exception occurs in org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(...)
{noFormat}
java.lang.UnsupportedOperationException: any not supported yet
at org.hibernate.ejb.metamodel.AttributeFactory.determineAttributeMetadata(AttributeFactory.java:452)
{noFormat}
It is due to the logic in AttributeFactory at line 451:
{noFormat}
if ( type.isAnyType() ) {
throw new UnsupportedOperationException( "any not supported yet" );
}
{noFormat}
The "Big Hammer" approach of globally disabling the creation of the metamodel with the property setting:
{noFormat}
hibernate.ejb.metamodel.generation=disabled
{noFormat}
is not feasible: other components in my application depend upon the criteria search api, which need a generated meatamodel. Splitting the single application persistence unit into two parts ( one for the jBPM persisted classes with metamodel disabled and all other classes with metamodel enabled) is not feasible either. The split persistence unit approach would also split transaction boundaries of operations that are desired to be in a single transaction.
Hibernate should support "any" mappings in the metamodel. The @Any annotation is supported in Hibernate Annotation 3.5.5.
If Hibernate can not support "any" mappings then maybe it could:
* Allow the exclusion of persistent classes by package in the metamodel. I tried this successfully by changing the following code in org.hibernate.ejb.EntityManagerFactoryImpl constructor:
{noFormat}
...
List<PersistentClass> persistentClasses = new ArrayList<PersistentClass>();
while (classes.hasNext()) {
PersistentClass persistentClass = classes.next();
// Hardcode jBPM classes for now, but make tidy with a property like "hibernate.ejb.metamodel.excluded.pkgs"
if (persistentClass.getClassName().startsWith("org.jbpm")) {
continue;
} else {
persistentClasses.add(persistentClass);
}
}
// a safe guard till we are confident that metamodel is wll tested
if (!"disabled".equalsIgnoreCase(cfg.getProperty("hibernate.ejb.metamodel.generation"))) {
this.metamodel = MetamodelImpl.buildMetamodel(persistentClasses.iterator(),
(SessionFactoryImplementor) sessionFactory);}
...
{noFormat}
* Exclude persistent classes having "any" mappings from the metamodel generation.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[Hibernate-JIRA] Created: (JPA-24) java.sql.SQLException: Invalid argument in JDBC call: parameter index out of range when trying to persist an entity mapped with insertable = false, updatable = false on @Column
by Karsten Wutzke (JIRA)
java.sql.SQLException: Invalid argument in JDBC call: parameter index out of range when trying to persist an entity mapped with insertable = false, updatable = false on @Column
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: JPA-24
URL: http://opensource.atlassian.com/projects/hibernate/browse/JPA-24
Project: Java Persistence API
Issue Type: Bug
Environment: Hibernate 4.0.0.CR4, HSQLDB 2.0, MySQL 5.1
Reporter: Karsten Wutzke
The following mappings are all JPA 1.0 compatible (no derived identifiers):
{code:Company.java}
@Entity
@Table(name = "Companies")
public class Company
{
@Id
@Column
private Integer id;
@Column
private String name;
...
}
{code}
{code:PQ.java}
@Entity
@Table(name = "PQs")
public class PQ implements Serializable
{
@Id
@Column
private Integer id;
@Column
private String name;
...
}
{code}
{code:Partnership.java}
@Entity
@Table(name = "Partnerships")
@IdClass(value = PartnershipId.class)
public class Partnership implements Serializable
{
@Id
@Column(name = "pq_id", insertable = false, updatable = false)
private Integer pqId;
@Id
@Column(name = "company_id", insertable = false, updatable = false)
private Integer companyId;
@Column(name = "ordinal_nbr")
private Integer ordinalNbr;
@ManyToOne
@JoinColumn(name = "pq_id", referencedColumnName = "id")
private PQ pq;
@ManyToOne
@JoinColumn(name = "company_id", referencedColumnName = "id")
private Company company;
...
}
{code}
{code:PartnershipId.java}
public class PartnershipId implements Serializable
{
private Integer pqId;
private Integer companyId;
public PartnershipId()
{
}
public PartnershipId(Integer pqId, Integer companyId)
{
this.pqId = pqId;
this.companyId = companyId;
}
...
}
{code}
Note, the insertable = false, updatable = false on @JoinColumn relationships.
Running the following test code
{code:Main.java}
public class Main
{
private static String PERSISTENCE_UNIT_NAME = "standalonePu";
private static EntityManagerFactory emf;
private static EntityManager em;
private static EntityTransaction trans;
public static void main(String[] args)
{
setUp(PERSISTENCE_UNIT_NAME);
trans.begin();
PQ detachedPq = new PQ(1, "Test PQ");
Company detachedCompany = new Company(1, "Test Company");
PQ pq = em.merge(detachedPq);
Company company = em.merge(detachedCompany);
Partnership detachedPartnership = new Partnership(1, 1, 1);
detachedPartnership.setPQ(pq);
detachedPartnership.setCompany(company);
Partnership partnership = em.merge(detachedPartnership);
partnership = em.find(Partnership.class, new PartnershipId(1, 1));
System.out.println("Persistent partnership = ("
+ partnership.getPQId() + ", "
+ partnership.getCompanyId() + ", "
+ partnership.getOrdinalNbr() + ")");
trans.commit();
close();
}
private static void setUp(String puName)
{
emf = Persistence.createEntityManagerFactory(puName);
em = emf.createEntityManager();
trans = em.getTransaction();
}
private static void close()
{
em.close();
emf.close();
}
}
{code}
fails with a really strange exception:
ERROR: Invalid argument in JDBC call: parameter index out of range: 4
Exception in thread "main" javax.persistence.RollbackException: Error while committing the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:90)
at main.Main.main(Main.java:44)
Caused by: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: Invalid argument in JDBC call: parameter index out of range: 4
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1347)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1280)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:78)
... 1 more
Caused by: org.hibernate.exception.GenericJDBCException: Invalid argument in JDBC call: parameter index out of range: 4
at org.hibernate.exception.internal.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:148)
at org.hibernate.exception.internal.SQLStateConverter.convert(SQLStateConverter.java:136)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:124)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:109)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:131)
at org.hibernate.engine.jdbc.internal.proxy.AbstractProxyHandler.invoke(AbstractProxyHandler.java:80)
at $Proxy12.setInt(Unknown Source)
at org.hibernate.type.descriptor.sql.IntegerTypeDescriptor$1.doBind(IntegerTypeDescriptor.java:57)
at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:82)
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:305)
at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:300)
at org.hibernate.type.ComponentType.nullSafeSet(ComponentType.java:358)
at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2599)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2836)
at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:3276)
at org.hibernate.action.internal.EntityInsertAction.execute(EntityInsertAction.java:80)
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:273)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:265)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:186)
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:344)
at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1084)
at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:319)
at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:100)
at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:173)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:73)
... 1 more
Caused by: java.sql.SQLException: Invalid argument in JDBC call: parameter index out of range: 4
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.Util.sqlException(Unknown Source)
at org.hsqldb.jdbc.Util.outOfRangeArgument(Unknown Source)
at org.hsqldb.jdbc.JDBCPreparedStatement.checkSetParameterIndex(Unknown Source)
at org.hsqldb.jdbc.JDBCPreparedStatement.setInt(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:124)
... 22 more
Caused by: org.hsqldb.HsqlException: Invalid argument in JDBC call: parameter index out of range: 4
at org.hsqldb.error.Error.error(Unknown Source)
... 31 more
I've also tested this with MySQL with the same JDBC exception.
Note the workaround to resolve this is to put `..., insertable = false, updatable = false` onto the relationships' `@JoinColumn`s (but it's not really what I want).
Please fix.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[Hibernate-JIRA] Created: (HHH-7048) Remove resolver classes
by John Verhaeg (JIRA)
Remove resolver classes
-----------------------
Key: HHH-7048
URL: https://hibernate.onjira.com/browse/HHH-7048
Project: Hibernate ORM
Issue Type: Task
Components: metamodel
Affects Versions: 4.1.0
Reporter: John Verhaeg
Assignee: John Verhaeg
Resolvers are currently called at the end of the MetadataImpl constructor as a temporary solution until a proper solution for creating bindings can be developed. However, it appears these can be removed after integrating their logic in an appropriate location within the Binder.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[Hibernate-JIRA] Issue Comment Edited: (HHH-1917) Bulk Delete on the owning side of a ManyToMany relation needs to delete corresponding rows from the JoinTable
by Eugen Paraschiv (JIRA)
[ https://hibernate.onjira.com/browse/HHH-1917?page=com.atlassian.jira.plug... ]
Eugen Paraschiv edited comment on HHH-1917 at 3/2/12 8:40 AM:
--------------------------------------------------------------
I have pasted the endire SQL generated by Hibernate when performing the bulk delete. It looks like the delete is performed before dropping FK constraints. It also looks like MyISAM is indeed not enforcing the FK constraints, which is why it's working on MySQL.
What do you mean by it's working as designed?
I will provide the full details here as well:
I have the unidirectional @ManyToMany without any kind of cascading:
@Entity
public class Role implements IEntity{
@Id @GeneratedValue( strategy = GenerationType.AUTO ) @Column( name = "ROLE_ID" ) private Long id;
@ManyToMany( fetch = FetchType.EAGER )
@JoinTable( joinColumns = { @JoinColumn( name = "ROLE_ID",referencedColumnName = "ROLE_ID" ) },inverseJoinColumns = { @JoinColumn( name = "PRIV_ID",referencedColumnName = "PRIV_ID" ) } )
private Set< Privilege > privileges;
}
And I'm running the following test code:
Privilege existingPrivilege = privilegeService.create( new Privilege( ) );
Role newRole = new Role();
newRole.getPrivileges().add( existingPrivilege );
getService().create( newRole );
roleService.deleteAll(); // failing
This will fail with:
Caused by: org.h2.jdbc.JdbcSQLException: Referential integrity constraint violation: "FK81B4C22896D682CC: PUBLIC.ROLE_PRIVILEGE FOREIGN KEY(ROLE_ID) REFERENCES PUBLIC.ROLE(ROLE_ID)"; SQL statement:
delete from Role [23503-164]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at org.h2.constraint.ConstraintReferential.checkRow(ConstraintReferential.java:398)
at org.h2.constraint.ConstraintReferential.checkRowRefTable(ConstraintReferential.java:415)
at org.h2.constraint.ConstraintReferential.checkRow(ConstraintReferential.java:291)
at org.h2.table.Table.fireConstraints(Table.java:862)
at org.h2.table.Table.fireAfterRow(Table.java:879)
at org.h2.command.dml.Delete.update(Delete.java:99)
at org.h2.command.CommandContainer.update(CommandContainer.java:73)
at org.h2.command.Command.executeUpdate(Command.java:226)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:143)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122)
... 65 more
So it's indeed looking like deleting the Roles does not delete the entries in the join table first (I simply want to delete all Roles, and leave the Privileges intact).
Am I missing something (you mentioned this would be an improvement not a bug). Also, is there a way to simply delete all which will not trigger this issue?
Thanks for the feedback.
Eugen.
was (Author: eugenparaschiv):
I have pasted the endire SQL generated by Hibernate when performing the bulk delete. It looks like the delete is performed before dropping FK constraints. It also looks like MyISAM is indeed not enforcing the FK constraints, which is why it's working on MySQL.
What do you mean by it's working as designed?
I will provide the full details here as well:
I have the unidirectional @ManyToMany without any kind of cascading:
@Entity
public class Role implements IEntity{
@Id @GeneratedValue( strategy = GenerationType.AUTO ) @Column( name = "ROLE_ID" ) private Long id;
@ManyToMany( fetch = FetchType.EAGER )
@JoinTable( joinColumns = { @JoinColumn( name = "ROLE_ID",referencedColumnName = "ROLE_ID" ) },inverseJoinColumns = { @JoinColumn( name = "PRIV_ID",referencedColumnName = "PRIV_ID" ) } )
private Set< Privilege > privileges;
}
And I'm running the following test code:
Privilege existingPrivilege = privilegeService.create( new Privilege( randomAlphabetic( 6 ) ) );
Role newRole = new Role();
newRole.getPrivileges().add( existingPrivilege );
getService().create( newRole );
roleService.deleteAll(); // failing
This will fail with:
Caused by: org.h2.jdbc.JdbcSQLException: Referential integrity constraint violation: "FK81B4C22896D682CC: PUBLIC.ROLE_PRIVILEGE FOREIGN KEY(ROLE_ID) REFERENCES PUBLIC.ROLE(ROLE_ID)"; SQL statement:
delete from Role [23503-164]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at org.h2.constraint.ConstraintReferential.checkRow(ConstraintReferential.java:398)
at org.h2.constraint.ConstraintReferential.checkRowRefTable(ConstraintReferential.java:415)
at org.h2.constraint.ConstraintReferential.checkRow(ConstraintReferential.java:291)
at org.h2.table.Table.fireConstraints(Table.java:862)
at org.h2.table.Table.fireAfterRow(Table.java:879)
at org.h2.command.dml.Delete.update(Delete.java:99)
at org.h2.command.CommandContainer.update(CommandContainer.java:73)
at org.h2.command.Command.executeUpdate(Command.java:226)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:143)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122)
... 65 more
So it's indeed looking like deleting the Roles does not delete the entries in the join table first (I simply want to delete all Roles, and leave the Privileges intact).
Am I missing something (you mentioned this would be an improvement not a bug). Also, is there a way to simply delete all which will not trigger this issue?
Thanks for the feedback.
Eugen.
> Bulk Delete on the owning side of a ManyToMany relation needs to delete corresponding rows from the JoinTable
> -------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1917
> URL: https://hibernate.onjira.com/browse/HHH-1917
> Project: Hibernate ORM
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.2.0.cr2
> Environment: Hibernate 3.2 cr2
> Hibernate Annotations 3.2.0.CR1
> Hibernate Entity Manager 3.2.0.CR1
> Oracle 10.1, with Oracle 10.2 JDBC Driver
> Reporter: Keenan Ross
>
> Emmanuel says in http://forum.hibernate.org/viewtopic.php?t=961140,
> [quote]I also know we need to fix some limitations regarding associations table updates / delete and bulk operations[/quote]
> This issue provides a reminder that this task is pending.
> For bulk deletes, consider this scenario: Assume Person and Group entities in a bidirectional ManyToMany relationship with Group as the owning side. This implies a Join table, with the default name of Group_Person. Currently issuing
> em.createQuery("delete from Group").executeUpdate();
> makes no attempt to delete the corresponding rows from Group_Person, even though Group is the owning side, giving constraint errors. Since Group_Person has no corresponding entity, I don't think the spec's prohibition on lifecycle operations or cascading applies here. The only workarround is to individually delete the Groups.
> --keenan
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[Hibernate-JIRA] Commented: (HHH-1917) Bulk Delete on the owning side of a ManyToMany relation needs to delete corresponding rows from the JoinTable
by Eugen Paraschiv (JIRA)
[ https://hibernate.onjira.com/browse/HHH-1917?page=com.atlassian.jira.plug... ]
Eugen Paraschiv commented on HHH-1917:
--------------------------------------
I have pasted the endire SQL generated by Hibernate when performing the bulk delete. It looks like the delete is performed before dropping FK constraints. It also looks like MyISAM is indeed not enforcing the FK constraints, which is why it's working on MySQL.
What do you mean by it's working as designed?
I will provide the full details here as well:
I have the unidirectional @ManyToMany without any kind of cascading:
@Entity
public class Role implements IEntity{
@Id @GeneratedValue( strategy = GenerationType.AUTO ) @Column( name = "ROLE_ID" ) private Long id;
@ManyToMany( fetch = FetchType.EAGER )
@JoinTable( joinColumns = { @JoinColumn( name = "ROLE_ID",referencedColumnName = "ROLE_ID" ) },inverseJoinColumns = { @JoinColumn( name = "PRIV_ID",referencedColumnName = "PRIV_ID" ) } )
private Set< Privilege > privileges;
}
And I'm running the following test code:
Privilege existingPrivilege = privilegeService.create( new Privilege( randomAlphabetic( 6 ) ) );
Role newRole = new Role();
newRole.getPrivileges().add( existingPrivilege );
getService().create( newRole );
roleService.deleteAll(); // failing
This will fail with:
Caused by: org.h2.jdbc.JdbcSQLException: Referential integrity constraint violation: "FK81B4C22896D682CC: PUBLIC.ROLE_PRIVILEGE FOREIGN KEY(ROLE_ID) REFERENCES PUBLIC.ROLE(ROLE_ID)"; SQL statement:
delete from Role [23503-164]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:329)
at org.h2.message.DbException.get(DbException.java:169)
at org.h2.message.DbException.get(DbException.java:146)
at org.h2.constraint.ConstraintReferential.checkRow(ConstraintReferential.java:398)
at org.h2.constraint.ConstraintReferential.checkRowRefTable(ConstraintReferential.java:415)
at org.h2.constraint.ConstraintReferential.checkRow(ConstraintReferential.java:291)
at org.h2.table.Table.fireConstraints(Table.java:862)
at org.h2.table.Table.fireAfterRow(Table.java:879)
at org.h2.command.dml.Delete.update(Delete.java:99)
at org.h2.command.CommandContainer.update(CommandContainer.java:73)
at org.h2.command.Command.executeUpdate(Command.java:226)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:143)
at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.hibernate.engine.jdbc.internal.proxy.AbstractStatementProxyHandler.continueInvocation(AbstractStatementProxyHandler.java:122)
... 65 more
So it's indeed looking like deleting the Roles does not delete the entries in the join table first (I simply want to delete all Roles, and leave the Privileges intact).
Am I missing something (you mentioned this would be an improvement not a bug). Also, is there a way to simply delete all which will not trigger this issue?
Thanks for the feedback.
Eugen.
> Bulk Delete on the owning side of a ManyToMany relation needs to delete corresponding rows from the JoinTable
> -------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1917
> URL: https://hibernate.onjira.com/browse/HHH-1917
> Project: Hibernate ORM
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.2.0.cr2
> Environment: Hibernate 3.2 cr2
> Hibernate Annotations 3.2.0.CR1
> Hibernate Entity Manager 3.2.0.CR1
> Oracle 10.1, with Oracle 10.2 JDBC Driver
> Reporter: Keenan Ross
>
> Emmanuel says in http://forum.hibernate.org/viewtopic.php?t=961140,
> [quote]I also know we need to fix some limitations regarding associations table updates / delete and bulk operations[/quote]
> This issue provides a reminder that this task is pending.
> For bulk deletes, consider this scenario: Assume Person and Group entities in a bidirectional ManyToMany relationship with Group as the owning side. This implies a Join table, with the default name of Group_Person. Currently issuing
> em.createQuery("delete from Group").executeUpdate();
> makes no attempt to delete the corresponding rows from Group_Person, even though Group is the owning side, giving constraint errors. Since Group_Person has no corresponding entity, I don't think the spec's prohibition on lifecycle operations or cascading applies here. The only workarround is to individually delete the Groups.
> --keenan
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[Hibernate-JIRA] Commented: (HHH-912) Use of DetachedCriteria
by Luca Domenichini (JIRA)
[ https://hibernate.onjira.com/browse/HHH-912?page=com.atlassian.jira.plugi... ]
Luca Domenichini commented on HHH-912:
--------------------------------------
I'm having the problem of setting the maxResults on a Subqueries.propertyIn(String, DetachedCriteria).
Completely agree with John saying about a common interface between Criteria and DetachedCriteria.
Someone of you did find a way to solve this problem?
> Use of DetachedCriteria
> -----------------------
>
> Key: HHH-912
> URL: https://hibernate.onjira.com/browse/HHH-912
> Project: Hibernate ORM
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.0.5
> Environment: All
> Reporter: Frank Verbruggen
> Priority: Minor
>
> The class org.hibernate.criterion.DetachedCriteria should represent a criteria object on which all the operations available to a Criteria object that do NOT require a Session object are available.
> Two such operations are setFirstResult() and setMaxResults().
> These are unfortunately enough not available.
> There probably are more methods missing that need to be added but these two in particular are important to me.
> See http://opensource2.atlassian.com/projects/spring/browse/SPR-1254.
> Can they be added in the next release ?
> Kind regards
> Frank Verbruggen
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[Hibernate-JIRA] Created: (HHH-7140) hibernate.hbm2ddl.auto does not respect location of domain object
by Thomas Wabner (JIRA)
hibernate.hbm2ddl.auto does not respect location of domain object
-----------------------------------------------------------------
Key: HHH-7140
URL: https://hibernate.onjira.com/browse/HHH-7140
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 3.6.9
Environment: MSSQL Server, Spring 3.1
Reporter: Thomas Wabner
I have some domain objects (with javax.persistence Entity annotations) where some of them connected to one and some to another database. Let me introduce a small example:
package one;
@Entity
@Table(name="objOne")
public class DomainObjOne {
}
....
package two;
@Entity
@Table(name="objTwo")
public class DomainObjTwo {
}
Now I have following sort of spring configuration:
<jee:jndi-lookup id="dataSourceDirect" jndi-name="jdbc/one" />
<!-- decorate data source with JDBC logging -->
<bean id="dataSource" class="org.jdbcdslog.ConnectionPoolDataSourceProxy">
<property name="targetDSDirect" ref="dataSourceDirect" />
</bean>
<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="dataSource" />
<property name="packagesToScan" value="one" />
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="showSql" value="false" />
<property name="generateDdl" value="true" />
<property name="databasePlatform"
value="my.persistence.hibernate.OptimizedMSSQLServerDialect" />
</bean>
</property>
</bean>
<jee:jndi-lookup id="twoDataSourceDirect" jndi-name="jdbc/two" />
<bean id="pmdDataSource" class="org.jdbcdslog.ConnectionPoolDataSourceProxy">
<property name="targetDSDirect" ref="twoDataSourceDirect" />
</bean>
<bean id="pmdEntityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="dataSource" ref="twoDataSource" />
<property name="packagesToScan" value="two" />
<property name="jpaVendorAdapter">
<bean id="hibernateJpaVendorAdapter" class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="showSql" value="false" />
<property name="generateDdl" value="false" />
<property name="databasePlatform"
value="my.persistence.hibernate.OptimizedMSSQLServerDialect" />
</bean>
</property>
</bean>
---------------
Now I try to start my spring context ... I would expect, that all entities from package "one" are updated, because there I have set generateDdl=true ... and all entities from package "two" are not used in update / ignored.
But I get some SQL exceptions, because hibernate tried to update my entity from package "two" in the database configured for package "one".
I see in my log (debug level), that
org.hibernate.cfg.Configuration - resolving reference to class: one.DomainObjOne
is included and two.DomainObjTwo not (which seems correct).
But while the schema update is running I get the information:
INFO o.h.tool.hbm2ddl.DatabaseMetadata - table not found: OBJ_TWO
For me, the correct behavior should be to ignore the table / entity for domain object two because for this object no update was defined.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[Hibernate-JIRA] Created: (HHH-6414) CPU spinning, stuck on getResultList()
by Anthony Ogier (JIRA)
CPU spinning, stuck on getResultList()
--------------------------------------
Key: HHH-6414
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6414
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Hibernate Annotations 3.4.0.GA, Hibernate 3.3.1.GA, Hibernate Commons Annotations 3.1.0.GA, Hibernate EntityManager 3.4.0.GA, Seam 2.2.1.Final, JBoss 5.1.0.GA, Windows Server 2008 64bits, Microsoft SQL Server 10.00.4000, JDBC driver: Microsoft SQL Server 2005 JDBC Driver, version: 1.2.2828.100
Reporter: Anthony Ogier
I've got a web application which is well tested (JMeter etc), and suddenly today, 2 of JBoss threads were stuck on a getResultList(), using 100% of the CPU.
Here is the stack for each of the threads :
{noformat}
Thread: http-0.0.0.0-8080-2 : priority:5, demon:true, threadId:156, threadState:RUNNABLE
java.util.HashMap.put(HashMap.java:374)
org.hibernate.engine.StatefulPersistenceContext.addCollection(StatefulPersistenceContext.java:787)
org.hibernate.engine.StatefulPersistenceContext.addUninitializedCollection(StatefulPersistenceContext.java:756)
org.hibernate.type.CollectionType.getCollection(CollectionType.java:642)
org.hibernate.type.CollectionType.resolveKey(CollectionType.java:430)
org.hibernate.type.CollectionType.resolve(CollectionType.java:424)
org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:139)
org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:877)
org.hibernate.loader.Loader.doQuery(Loader.java:752)
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259)
org.hibernate.loader.Loader.doList(Loader.java:2228)
org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125)
org.hibernate.loader.Loader.list(Loader.java:2120)
org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:401)
org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:361)
org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
org.hibernate.impl.SessionImpl.list(SessionImpl.java:1148)
org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:67)
{noformat}
I've seen some similar problems here [JGRP-525|https://issues.jboss.org/browse/JGRP-525] and here [JBMESSAGING-1676|https://issues.jboss.org/browse/JBMESSAGING-1676] and they are talking about concurrency ...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months