October 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6783) Using FetchType.EAGER with @ElementCollection results in multiple entity copies returned via Criteria query

by Greg Burcher (JIRA)

Using FetchType.EAGER with @ElementCollection results in multiple entity copies returned via Criteria query ----------------------------------------------------------------------------------------------------------- Key: HHH-6783 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6783 Project: Hibernate Core Issue Type: Bug Components: annotations Affects Versions: 3.6.0 Environment: MySQL Reporter: Greg Burcher If we specify FetchType.EAGER on an @ElementCollection: @ElementCollection(fetch = FetchType.EAGER) @Column(name = "emailAddress") private Set<String> emailAddresses; then request all persisted objects of this class via Criteria: session.createCriteria(ReportSchedule.class).list(); The returned list contains multiple references to each ReportSchedule, one per email address. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

5
8
0 / 0

[Hibernate-JIRA] Created: (BVAL-216) Work with the JAXB EG to have a nice Bean Validation integration

by Emmanuel Bernard (JIRA)

Work with the JAXB EG to have a nice Bean Validation integration ---------------------------------------------------------------- Key: BVAL-216 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-216 Project: Bean Validation Issue Type: Improvement Components: spec-general Reporter: Emmanuel Bernard -- 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

13 years, 7 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-6285) Exception when the entities has no @Id but just uses @EmbeddId

by Strong Liu (JIRA)

Exception when the entities has no @Id but just uses @EmbeddId -------------------------------------------------------------- Key: HHH-6285 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6285 Project: Hibernate Core Issue Type: Bug Reporter: Strong Liu Assignee: Hardy Ferentschik Fix For: 4.0.0.Beta1 Hardy, the logic of org.hibernate.metamodel.source.annotations.entity.ConfiguredClassHierarchy#determineDefaultAccessType is not correct ... as subject, if all entities use only @EmbeddId, then this method throws exception. we need find a better way to determin the default access type -- 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

13 years, 7 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3809) Improve Memory Management when Post Commit Listeners are enabled

by Shawn Clowater (JIRA)

Improve Memory Management when Post Commit Listeners are enabled ---------------------------------------------------------------- Key: HHH-3809 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3809 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Environment: N/A Reporter: Shawn Clowater This is somewhat related to the QueryCache behavior reported under http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028 In this particular case however, it is the fact that when the session factory is configured to have post commit listeners it prevents the garbage collection of any entity that is modified during the session due to the fact that it is referenced in the executions list in the ActionQueue class. This makes any type of memory management by flushing/clearing the session ineffective if you're in the middle of a large batch that is inserting or updating a large amount of data. i.e in our case we have 4 entities out of possibly 300 or so that we want to notify external systems if they change. However, by simply having the listeners defined they essentially block the remaining entities in the executions. A potential workaround I guess might be to keep 2 session factories around with a different set of listeners but that seems a bit dirty. There are 2.5 potential ways that I can think of that might address this. 1 - Have some sort of flag on the session to disable the post commit listeners. The onus would be on the user of the session to disable the listeners in the case where they know they aren't modifying anything that will need post commit handling. 2 - Add the ability to configure the post commit listeners by entity a)With polymorphism - i.e. you could add a listener based on Object.class and it would apply to all entities and would behave much like it does now. You could also configure to Animal.class and would include Cat and Dog. b)Without polymorphism - you could add a listener based on a specific entity class and it would only apply to that particular one. You would have an option to specify a null entity and it would default to what is there today. In my miind, 2a is probably the best albeit slightly more complex to implement but I think would be a good value add. I don't mind submitting a patch assuming that I'm not so far in left field that I should be committed. -- 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

13 years, 7 months

3
20
0 / 0

[Hibernate-JIRA] Created: (HHH-2770) Action observers for event listeners

by Christian Bauer (JIRA)

Action observers for event listeners ------------------------------------ Key: HHH-2770 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2770 Project: Hibernate3 Issue Type: New Feature Components: core Reporter: Christian Bauer Priority: Minor Talked to Steve about a feature he calls "action observers", which would allow the following use case: - Write a FlushEventListener - Observer for what has been deleted, inserted, updated (action queues) This removes some of the pain that comes from missing communication between listeners. For example, you can easily move code you would traditionally write in an Interceptor into a FlushEventListener if you only need inserted/deleted/udpated records. -- 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

13 years, 7 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3452) Statistics for Criteria Queries

by Rohit N (JIRA)

Statistics for Criteria Queries ------------------------------- Key: HHH-3452 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3452 Project: Hibernate3 Issue Type: New Feature Components: query-criteria Reporter: Rohit N Priority: Blocker Criteria Queries are not part of the Query Statistics. This gives an incomplete "picture" to the user. Currently, the Statistics is only for HQL 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

13 years, 8 months

9
16
0 / 0

[Hibernate-JIRA] Created: (ANN-630) @ManyToMany and @Index

by Peter K. Guldbæk (JIRA)

@ManyToMany and @Index ---------------------- Key: ANN-630 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-630 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Environment: Windows Vista java version "1.5.0_11" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) Java HotSpot(TM) Client VM (build 1.5.0_11-b03, mixed mode) Reporter: Peter K. Guldbæk I have trouble adding an index to a column of a table which is part of a many-to-many property mapping. The following example causes a NullPointerException when generating the DDL (the exception can be seen at the end of my post): @Entity @Table(name="usr") public class User implements Serializable { @Id @GeneratedValue(strategy=GenerationType.AUTO) public Integer id; @ManyToMany(targetEntity=Target.class, cascade={}) @Index(name="fkey_usr_target", columnNames="usr_id") @JoinTable(name="usr_target", joinColumns=@JoinColumn(name="usr_id"), inverseJoinColumns=@JoinColumn(name="target_id")) public Collection<Target> targets; } @Entity @Table(name="target") public class Target implements Serializable { @Id @GeneratedValue(strategy=GenerationType.AUTO) public Integer id; @Basic public String myValue; } NullPointerException thrown when an @Index annotation is used with a @ManyToMany: java.lang.NullPointerException at org.hibernate.cfg.AnnotationBinder.processElementAnnotations(AnnotationBinder.java:1594) at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:733) at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:498) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:277) at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1115) at org.hibernate.tool.ant.ConfigurationTask.getConfiguration(ConfigurationTask.java:56) at org.hibernate.tool.ant.HibernateToolTask.getConfiguration(HibernateToolTask.java:299) at org.hibernate.tool.ant.Hbm2DDLExporterTask.execute(Hbm2DDLExporterTask.java:45) at org.hibernate.tool.ant.HibernateToolTask.execute(HibernateToolTask.java:183) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) at sun.reflect.GeneratedMethodAccessor19.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:357) at org.apache.tools.ant.Target.performTasks(Target.java:385) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329) at org.apache.tools.ant.Project.executeTarget(Project.java:1298) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1181) at org.apache.tools.ant.Main.runBuild(Main.java:698) at org.apache.tools.ant.Main.startAnt(Main.java:199) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104) -- 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

13 years, 8 months

8
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5233) @FetchProfile fails to take more than one @FetchProfile.FetchOverride

by Emmanuel Bernard (JIRA)

@FetchProfile fails to take more than one @FetchProfile.FetchOverride --------------------------------------------------------------------- Key: HHH-5233 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5233 Project: Hibernate Core Issue Type: Bug Components: annotations Affects Versions: 3.5.2 Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik Fix For: 3.5.x A unit test is committed in org.hibernate.test.annotations.fetchprofile.MoreFetchProfileTest#testFetchWithTwoOverrides -- 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

13 years, 8 months

5
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5690) Inserted data remains in 2L Cache after rollback

by Nikita Koksharov (JIRA)

Inserted data remains in 2L Cache after rollback ------------------------------------------------ Key: HHH-5690 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5690 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.6.0, 3.5.6 Reporter: Nikita Koksharov Attachments: TransactionalCacheableItem.java, TransactionalInsertedDataTest.java For entities with Transactional caching strategy, inserted data remains in 2L cache after transaction rollback. Testcase attached. testcase used from this bug http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490 -- 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

13 years, 8 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6776) Hibernate inserts duplicates into @OneToMany collection

by Damien (JIRA)

Hibernate inserts duplicates into @OneToMany collection ------------------------------------------------------- Key: HHH-6776 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6776 Project: Hibernate Core Issue Type: Bug Affects Versions: 4.0.0.CR4, 3.6.7 Environment: MySQL 5.1.54 Reporter: Damien Priority: Minor Attachments: Test.zip Consider following entities (getters and setters are omitted for brevity): {code:java} @Entity public class Parent { @Id @GeneratedValue private int id; @OneToMany(mappedBy="parent") private List<Child> children = new LinkedList<Child>(); } @Entity public class Child { @Id @GeneratedValue private int id; @ManyToOne private Parent parent; } {code} Now consider following code snippet, which persists one parent and one child entity and then prints the children of the parent. {code:java} // persist parent entity in a transaction EntityManager em = emf.createEntityManager(); em.getTransaction().begin(); Parent parent = new Parent(); em.persist(parent); int id = parent.getId(); em.getTransaction().commit(); em.close(); // relate and persist child entity in a new transaction em = emf.createEntityManager(); em.getTransaction().begin(); parent = em.find(Parent.class, id); // *: parent.getChildren().size(); Child child = new Child(); child.setParent(parent); parent.getChildren().add(child); em.persist(child); System.out.println(parent.getChildren()); // -> [Child@36bf7916, Child@36bf7916] em.getTransaction().commit(); em.close(); {code} The child entity is wrongly being inserted twice into the list of children of the parent entity. When doing one of the following, the code works fine (no duplicate entries in the list): - remove the mappedBy attribute in the parent entity - perform some read operation on the list of children (e.g. uncomment line marked by *) Also, when testing against another persistence provider, the code works as expected (no duplicates). Take a look at axtavt's [answer|http://stackoverflow.com/questions/7903800/hibernate-inserts-dupli...] to my post on Stack Overflow. He seems to know why this problem occurrs. I have attached a simple JUnit test for this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2011