December 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-4520) Infinispan second level cache integration can cache stale collection data

by Galder Zamarreno (JIRA)

Infinispan second level cache integration can cache stale collection data ------------------------------------------------------------------------- Key: HHH-4520 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4520 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5 Port HHH-3817 to Infinispan second level cache integration. -- 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, 3 months

1
1
0 / 0

[Hibernate-JIRA] Created: (EJB-402) Ejb3ConfigurationObjectFactory needs to use MarshalledValueInputStream

by Galder Zamarreno (JIRA)

Ejb3ConfigurationObjectFactory needs to use MarshalledValueInputStream ---------------------------------------------------------------------- Key: EJB-402 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-402 Project: Hibernate Entity Manager Issue Type: Bug Affects Versions: 3.4.0.CR2, 3.3.2.GA, 3.2.1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.4.0.GA Ejb3ConfigurationObjectFactory should use MarshalledValueInputStream instead of ObjectInputStream, otherwise looking up configuration from isolated deployments won't work correcly and you'll get ClassNotFoundExceptions. MarshalledValueInputStream is different from ObjectInputStream in that it uses the thread context classloader to load classes rather than the system classloader. -- 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, 3 months

2
13
0 / 0

[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, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4656) Small patch to support cross joins in Criteria queries

by Chris Wilson (JIRA)

Small patch to support cross joins in Criteria queries ------------------------------------------------------ Key: HHH-4656 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4656 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5 Environment: Recent Hibernate trunk, Ubuntu 8.04, MySQL 5.0.51a-3ubuntu5.4 Reporter: Chris Wilson Attachments: hibernate-criteria-cross-join.patch This patch allows you to do a cartesian product (cross join) in a Criteria query, deliberately removing the supplied join conditions, and adding any that you like (prefer) via the withClause parameter of Criteria.createCriteria. For example, it enables you to do: Criteria c = session.createCriteria(Project.class); c.createCriteria("sites", JoinFragment.CROSS_JOIN); returning a row for every Project and every Site, regardless of whether they match or not. I need this to implement some complex SQL queries using Criteria. I could probably use HQL or SQL but I prefer Criteria. The patch includes some changes I made to ANSIJoinFragment's SQL formatting to make the SQL it generates easier to read, which you may prefer to leave out. -- 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, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4655) Upgrade jpamodelgen dependency in entitymanager to use 1.0.0.Beta1

by Hardy Ferentschik (JIRA)

Upgrade jpamodelgen dependency in entitymanager to use 1.0.0.Beta1 ------------------------------------------------------------------- Key: HHH-4655 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4655 Project: Hibernate Core Issue Type: Task Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 3.5 -- 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, 3 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1599) ConstraintViolationException returns null with PostgresDialect

by Bruno Medeiros (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1599?page=c... ] Bruno Medeiros commented on HHH-1599: ------------------------------------- Sorry for the double post.. I've attached a file that I tried to apply the patches above. I don't remember why I didn't extend the default dialect, but I think it's not possible to apply the patches extending. It's far from perfect, but at least shows the constraint. It's doesn't seem that there's someone with free enough time to spent on this... > ConstraintViolationException returns null with PostgresDialect > -------------------------------------------------------------- > > Key: HHH-1599 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1599 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1.3 > Environment: Hibernate 3.1.3 , Postgres 8.1.2 (i686), postgresql-8.2dev-501.jdbc.jar > Reporter: Niclas Lindberg > Assignee: Diego Plentz > Priority: Minor > Attachments: HHH-1599-postgres-only.patch, HHH-1599.patch, PostgreSQLDialect.java > > Original Estimate: 3 minutes > Remaining Estimate: 3 minutes > > ConstraintViolationException.getConstraintName() returns null. The problem is that the message being parsed comes from the SqlException that is the inputparameter to extractConstraintName(SqlException) in ViolatedConstraintNameExtracter. > Solution. The message provided by sqlException.getMessage() is "batch bla bla something" but the correct Exception message to parse is sqlException.getNextException().getMessage() -- 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, 3 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1599) ConstraintViolationException returns null with PostgresDialect

by Bruno Medeiros (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1599?page=c... ] Bruno Medeiros updated HHH-1599: -------------------------------- Attachment: PostgreSQLDialect.java Patched PostgreSQLDialect > ConstraintViolationException returns null with PostgresDialect > -------------------------------------------------------------- > > Key: HHH-1599 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1599 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1.3 > Environment: Hibernate 3.1.3 , Postgres 8.1.2 (i686), postgresql-8.2dev-501.jdbc.jar > Reporter: Niclas Lindberg > Assignee: Diego Plentz > Priority: Minor > Attachments: HHH-1599-postgres-only.patch, HHH-1599.patch, PostgreSQLDialect.java > > Original Estimate: 3 minutes > Remaining Estimate: 3 minutes > > ConstraintViolationException.getConstraintName() returns null. The problem is that the message being parsed comes from the SqlException that is the inputparameter to extractConstraintName(SqlException) in ViolatedConstraintNameExtracter. > Solution. The message provided by sqlException.getMessage() is "batch bla bla something" but the correct Exception message to parse is sqlException.getNextException().getMessage() -- 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, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HV-38) Conditional validation

by Bruno Braga (JIRA)

Conditional validation ---------------------- Key: HV-38 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-38 Project: Hibernate Validator Issue Type: Improvement Components: engine Affects Versions: 3.0.0.ga Reporter: Bruno Braga Priority: Critical Support Conditional Validation Example: @NotNull(apply-if="some condition in el") I can develop this if you approve. -- 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, 3 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-4654) Criteria quries must support referencing parameters by name

by Steve Ebersole (JIRA)

Criteria quries must support referencing parameters by name ----------------------------------------------------------- Key: HHH-4654 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4654 Project: Hibernate Core Issue Type: Sub-task Reporter: Steve Ebersole Assignee: Steve Ebersole -- 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, 3 months

1
2
0 / 0

[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, 3 months

5
13
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2009