[Hibernate-JIRA] Created: (HHH-4041) Null Pointer Exception when using @NotAudited on an entity with discriminator column, inherited from base entity with InheritanceType.SINGLE_TABLE
by Priya M (JIRA)
Null Pointer Exception when using @NotAudited on an entity with discriminator column, inherited from base entity with InheritanceType.SINGLE_TABLE
--------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-4041
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4041
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.3.1
Reporter: Priya M
Using latest Envers version -- 1.2.1GA
This is my mapping:
@Entity
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
class Foo {
}
@Entity
@DiscriminatorValue("bar")
class Bar {
}
@Entity
@Audited
class FooBarTest {
@NotAudited
Bar bar;
}
I get a NPE exception!
Caused by: java.lang.NullPointerException
at org.hibernate.envers.configuration.metadata.AuditMetadataGenerator.generateInheritanceMappingData(AuditMetadataGenerator.java:305)
at org.hibernate.envers.configuration.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:349)
at org.hibernate.envers.configuration.EntitiesConfigurator.configure(EntitiesConfigurator.java:87)
at org.hibernate.envers.configuration.AuditConfiguration.<init>(AuditConfiguration.java:86)
at org.hibernate.envers.configuration.AuditConfiguration.getFor(AuditConfiguration.java:99)
at org.hibernate.envers.event.AuditEventListener.initialize(AuditEventListener.java:260)
at org.hibernate.event.EventListeners$1.processListener(EventListeners.java:198)
at org.hibernate.event.EventListeners.processListeners(EventListeners.java:181)
at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:194)
Right now, I'm forced to make Foo as @Audited even though I don't intend to.
--
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
15 years, 1 month
[Hibernate-JIRA] Created: (HHH-4090) RelationTargetAuditMode.NOT_AUDITED not working with many-to-many relations
by Jacek Kunicki (JIRA)
RelationTargetAuditMode.NOT_AUDITED not working with many-to-many relations
---------------------------------------------------------------------------
Key: HHH-4090
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4090
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1-GA, PostgreSQL 8.2
Reporter: Jacek Kunicki
When defining a @ManyToMany relation from an @Audited entity to a non-@Audited one using RelationTargetAuditMode.NOT_AUDITED:
@Entity
@Audited
class A {
@ManyToMany
@JoinTable(...)
@Audited(targetAuditMode = RelationTargetAuditMode.NOT_AUDITED)
private B b;
// getters, setters ...
}
@Entity
class B {
...
}
the following error occurs during deployment:
Caused by: org.hibernate.HibernateException: could not init listeners
at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:205)
at org.hibernate.cfg.Configuration.getInitializedEventListeners(Configuration.java:1338)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1327)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669)
... 145 more
Caused by: org.hibernate.MappingException: An audited relation from A to a non-audited entity: B
at org.hibernate.envers.configuration.metadata.CollectionMetadataGenerator.throwRelationNotAudited(CollectionMetadataGenerator.java:537)
at org.hibernate.envers.configuration.metadata.CollectionMetadataGenerator.addValueToMiddleTable(CollectionMetadataGenerator.java:390)
at org.hibernate.envers.configuration.metadata.CollectionMetadataGenerator.addWithMiddleTable(CollectionMetadataGenerator.java:310)
at org.hibernate.envers.configuration.metadata.CollectionMetadataGenerator.addCollection(CollectionMetadataGenerator.java:154)
at org.hibernate.envers.configuration.metadata.AuditMetadataGenerator.addValue(AuditMetadataGenerator.java:144)
at org.hibernate.envers.configuration.metadata.AuditMetadataGenerator.addProperties(AuditMetadataGenerator.java:164)
at org.hibernate.envers.configuration.metadata.AuditMetadataGenerator.generateSecondPass(AuditMetadataGenerator.java:419)
at org.hibernate.envers.configuration.EntitiesConfigurator.configure(EntitiesConfigurator.java:100)
at org.hibernate.envers.configuration.AuditConfiguration.<init>(AuditConfiguration.java:86)
at org.hibernate.envers.configuration.AuditConfiguration.getFor(AuditConfiguration.java:99)
at org.hibernate.envers.event.AuditEventListener.initialize(AuditEventListener.java:260)
at org.hibernate.event.EventListeners$1.processListener(EventListeners.java:198)
at org.hibernate.event.EventListeners.processListeners(EventListeners.java:181)
at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:194)
--
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
15 years, 1 month
[Hibernate-JIRA] Created: (HHH-2935) Cascading save on OneToMany causes not null constraint violation on child table
by Aaron Luchko (JIRA)
Cascading save on OneToMany causes not null constraint violation on child table
-------------------------------------------------------------------------------
Key: HHH-2935
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2935
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.1
Environment: hibernate-3.2.1, hibernate-annotations-3.2.1
Reporter: Aaron Luchko
Attachments: saveNull.zip
When defining a OneToMany relationship, controlled by the parent, and not nullable by the child, there's an issue when trying to insert the initially created columns.
With a schema attached as thus
public class Parent {
...
@OneToMany(targetEntity = Child.class, cascade = { CascadeType.ALL })
@Cascade( { org.hibernate.annotations.CascadeType.SAVE_UPDATE,
org.hibernate.annotations.CascadeType.DELETE_ORPHAN })
@JoinColumn(name = "parent_child")
public List<Child> getChildren() {
return children;
}
}
public class Child{
...
@ManyToOne
@JoinColumn(name = "parent_child", insertable = false, updatable = false, nullable=false)
public Parent getParent() {
return parent;
}
}
And running a section of code such as this
Session session = HibernateUtil.getSession();
session.beginTransaction();
Parent parent = new Parent();
int times = 2;
List<Child> children = new ArrayList<Child>(times);
for (int i = 0; i < times; i++) {
Child child = new Child();
children.add(child);
child.setParent(parent);
}
parent.setChildren(children);
session.save(parent);
session.getTransaction().commit();
Hibernate attempts to run the following series of queries
select child_.id from Child child_ where child_.id=?
select child_.id from Child child_ where child_.id=?
insert into Parent (id) values (?)
insert into Child (id) values (?)
insert into Child (id) values (?)
update Child set parent_child=? where id=?
update Child set parent_child=? where id=?
The problem is that in initial batch inserting the two children fails violating the not null constraint before the update can assign a value to parent_child.
I've reproduced this with postgresql and mysql (after setting the dialect to org.hibernate.dialect.MySQLInnoDBDialect, MyISAM doesn't catch the constraint violation).
As a workaround one can simply leave off the nullable=false.
I've attached a full testcase.
thanks,
Aaron
--
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
15 years, 1 month
[Hibernate-JIRA] Created: (HHH-2272) Serious performance problems when saving large amount of transient entities with collections of transient entities
by Markus Heiden (JIRA)
Serious performance problems when saving large amount of transient entities with collections of transient entities
------------------------------------------------------------------------------------------------------------------
Key: HHH-2272
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2272
Project: Hibernate3
Type: Task
Components: core
Versions: 3.2.0.ga
Environment: Hibernate 3.2.0 on Oracle 9.2
Reporter: Markus Heiden
When saving many (e.g. 50000) transient entities with a collection of transient entities, for each collection element the whole persistence context is searched (by StatefulPersistenceContext#getIndexInOwner() and StatefulPersistenceContext#getOwnerId) and its even searched twice when the collection is an indexed collection. This leads to an enormous amount (> 1000000) of iterations over all entities and over all collection elements of each entity. Especially when one saves only the same type of entities this leads to times of hours(!) even on a fast machine before any insert statement is even issued. This issue is related to HHH-1612, but fixing issue HHH-1612 won't resolve this problem (I have explored this with a hack which fixes HHH-1612).
In my eyes there are two ways to solve this problem:
1) When cascading the save of a parent, the parent cascade can fill the persistence context with information about its collection elements. E.g. before cascading the save to a collection a parent can add a (child, parent) pair to a map in the persistence context to avoid the above described iterations. Then a simple Map#get() would be sufficient in most cases to get the parent.
2) When cascading, the parent has to be passed with the cascaded (e.g. saved) element. But this is no good solution, because it affects some well known hibernate apis.
--
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
15 years, 1 month
[Hibernate-JIRA] Created: (HHH-3271) Prepare Statement Caching
by lalit railwani (JIRA)
Prepare Statement Caching
-------------------------
Key: HHH-3271
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3271
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 10g
Reporter: lalit railwani
We are using Hibernate 3.2.5 are trying to evaluate hibernate batching vis a vis JDBC batching.
As per our results the hibernate batching takes approx 2 times the time taken by JDBC batching.
The problem is we need to commit the batches also so in a loop we are commiting the transaction also (batching).
But for every new loop hibernate creates new prepared statements i.e. if we have 20 batches 20 prepared statements per table/entity are being created but in case of JDBC the same can be done using 1 prepared statement per table/entity.
Hibernate does reuse the prepared statements within a batch but not across batches. If hibernate can reuse these statements it would significantly reduce the timings and would bring the hibernate batching close to jdbc batching.
This is happening even after enabling prepare statement caching in the hibernate cfg xml.
--
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
15 years, 1 month
[Hibernate-JIRA] Created: (HHH-3578) Add setReadOnly(true) method to the Criteria interface
by Graeme Rocher (JIRA)
Add setReadOnly(true) method to the Criteria interface
------------------------------------------------------
Key: HHH-3578
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3578
Project: Hibernate Core
Issue Type: New Feature
Components: core
Affects Versions: 3.3.1, 3.3.0.SP1, 3.3.0.GA, 3.3.0.CR2, 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga, 3.2.0.cr5, 3.2.0.cr4, 3.2.0.cr3, 3.2.0.cr2, 3.2.0 cr1, 3.1.3, 3.2.0.alpha2, 3.2.0.alpha1, 3.1.2, 3.1.1, 3.1, 3.1 rc3, 3.1 rc2, 3.1 rc 1, 3.1 beta 2, 3.1 beta 1, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0 final, 3.0 rc 1, 3.0 beta 4, 3.0 beta 3, 3.0 beta 2, 3.0 beta 1, 3.0 alpha
Reporter: Graeme Rocher
Currently the Query interface has a setReadOnly(true) method but the Criteria interface does not, this makes it impractical to use the Criteria API for read-only queries.
--
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
15 years, 1 month
[Hibernate-JIRA] Created: (HHH-3772) Constraint names cannot be quoted with backticks `
by Christian (JIRA)
Constraint names cannot be quoted with backticks `
--------------------------------------------------
Key: HHH-3772
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3772
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Hibernate 3.3, all database dialects
Reporter: Christian
Priority: Minor
Table and Column names can be quoted with ` but constraint names cannot be quoted. You can reproduces the bug with the following testcase:
@javax.persistence.Entity
@javax.persistence.Table( name = "`categories`" )
abstract public class Category {
...
@org.hibernate.annotations.ForeignKey( name = "`fk_categories_parent_id`" )
@javax.persistence.ManyToOne( targetEntity = Category.class )
@javax.persistence.JoinColumn( name = "`parent_id`" )
private Category parent;
...
}
The SchemaExport (hbm2ddl) creates the following SQL statement for Postgresql:
alter table "categories" drop constraint `fk_categories_parent_id`;
drop table "categories";
create table "categories" (
...
"parent_id" int8,
...
);
alter table "categories" add constraint `fk_categories_parent_id`
foreign key ("parent_id") references "categories";
I think this problem should be fixed in the method in the class org.hibernate.mapping.Constraint in the same way as in Table.java and Column.java:
old:
public void setName(String name) {
this.name = name;
}
new:
private boolean quoted = false;
public void setName(String name) {
if ( name.charAt( 0 ) == '`' ) {
quoted = true;
this.name = name.substring( 1, name.length() - 1 );
}
else {
this.name = name;
}
}
public String getQuotedName() .. same as in Column.java
public String getQuotedName(Dialect d) { .. same as in Column.java
public boolean isQuoted() .. same as in Column.java
public String sqlDropString( ... ) {
...
return "alter table " + getTable().getQualifiedName( dialect, defaultCatalog, defaultSchema ) + " drop constraint " + getQualifiedName();
...
}
public String sqlCreateString( ... ) {
...
String constraintString = sqlConstraintString( dialect, getQualifiedName(), defaultCatalog, defaultSchema );
...
}
--
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
15 years, 1 month
[Hibernate-JIRA] Created: (HHH-4070) createProxy() called even when hasProxy() returns false
by Philip Borlin (JIRA)
createProxy() called even when hasProxy() returns false
-------------------------------------------------------
Key: HHH-4070
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4070
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: 3.3.2GA, PostgresQL 8.3
Reporter: Philip Borlin
This problem occurs when an EntityTuplizer is used. In my case I throw an UnsupportedOperationException in my createProxy() method. I would expect that would be ok since my hasProxy() method returns false. This was working in 3.3.1 but broke in 3.3.2.
In DefaultLoadEventListener in the proxyOrLoad() method there is a call to persister.hasProxy(). This makes a call to AbstractEntityPersister which simply checks to see whether the entityMetamodel isLazy().
That check succeeds since lazy is sent to true.
The next check sees if isAllowProxyCreation() is false in the options.
Lastly creatProxyIfNecessary() is called which if the entity does not exist calls createProxy() on the persister. AnstractEntityPersister delegates this directly to the tuplizer.
At no point was the tuplizer's hasProxy() method ever consulted.
--
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
15 years, 1 month