December 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5188) Use provided enum type ordinal/string when reading

by Stefan Larsson (JIRA)

Use provided enum type ordinal/string when reading -------------------------------------------------- Key: HHH-5188 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5188 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.5.0-CR-2 Reporter: Stefan Larsson Priority: Minor Attachments: EnumType.java-typeSafeNullSafeGet.patch When Hibernate reads a PostgreSQL enum type using ResultSet.getObject(), the JDBC driver returns a driver-specific PGObject object, which preserves both the value of the enum and its type ordinal/string. Hibernate fails with a ClassCastException when it attempts to cast the PGObject into a String in org.hibernate.type.EnumType.nullSafeGet(). The code in org.hibernate.type.EnumType assumes that ResultSet.getObject() will either return a Number or a String, which is not true for the PostgreSQL driver. IMHO it would be better to let the JDBC driver do the conversion using ResultSet.getInt() or getString() instead. The attached patch allows JBoss AS 6 M3 (Hibernate 3.5.0-CR-2) to read PostgreSQL enums, using JPA, with a a Java enum annotated as @javax.persistence.Enumerated(javax.persistence.EnumType.STRING). Also, I believe that perhaps ignoring the given enum type causes Issue HHH-4230, where an ordinal enum was stored in character field. ResultSet.getInteger() might work for that one depending on the JDBC driver. -- 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, 3 months

5
18
0 / 0

[Hibernate-JIRA] Created: (HHH-4468) Exception when using hibernate as JPA provider: "Found two representations of same collection"

by Håvard Nesvold (JIRA)

Exception when using hibernate as JPA provider: "Found two representations of same collection" ---------------------------------------------------------------------------------------------- Key: HHH-4468 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4468 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.3.2 Environment: 3.3.2.GA Reporter: Håvard Nesvold I have a J2SE application where I use JPA with Hibernate as persistence provider. The versions of the required hibernate jars that I use are: hibernate3.jar (3.3.2.GA) hibernate-annotations.jar (3.4.0.GA) hibernate-commons-annotations.jar (3.1.0.GA) hibernate-entitymanager.jar (3.4.0.GA) I have an entity where i have a bidirectional One-To-Many mapping. This is initialized to an empty list, something that clearly is allowed according to the JPA 1.0 spec. i.e. I have: in class Parent: @OneToMany(mappedBy="parent", cascade = CascadeType.ALL) private List<Child> children = ArrayList<Child>(); class Child: @ManyToOne @JoinColumn(name="PARENT_ID") private Parent parent; A certain sequence of actions result in a HibernateException being thrown (wrapped by JPA in a RollbackException): * Obtain a new EntityManager * Begin a transaction * Fetch a Parent entity from the entity manager (this exists in the db), call this e. * Apply an EntityManager.remove() on e * Commit the transaction * Begin a transaction * Apply an EntityManager.persist() on e * Commit the transaction The exception is thrown on the last commit(): Code: Caused by: org.hibernate.HibernateException: Found two representations of same collection: Parent.children at org.hibernate.engine.Collections.processReachableCollection(Collections.java:176) at org.hibernate.event.def.FlushVisitor.processCollection(FlushVisitor.java:60) at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:124) ... I have tried to flush(), clear(), and pretty much everything on the entity manager (event fetching the Hibernate Sesssion and clearing this) - the only thing that helps is creating a new one before attempting the last transaction. Moreover, after some investigation, the persisted entity actually seems to be persisted correctly - despite the exception (this also seems to hold true for any cascaded persists), perhaps the only erroneous thing here is the fact that an exception is thrown when it really should not? -- 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, 3 months

2
7
0 / 0

[Hibernate-JIRA] Created: (ANN-808) @Enumerated(ORDINAL) does not work on VARCHAR columns

by Eduardo Costa (JIRA)

@Enumerated(ORDINAL) does not work on VARCHAR columns ----------------------------------------------------- Key: ANN-808 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-808 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.1.GA Environment: Tested on Postgres, but the problem should be reproductible on any DB vendor Reporter: Eduardo Costa Copied from http://forum.hibernate.org/viewtopic.php?t=995698: ========== Suppose I have this enum: public enum Status { OK, NOK, NOT_APPLICABLE } And this property: @Column(name = "status") @Enumerated(EnumType.ORDINAL) private Status status; And this table (legacy, CANNOT be changed): CREATE TABLE tb_xxx ( id bigint NOT NULL, status character varying(1) NOT NULL, ) It leads to this exception: java.lang.IllegalArgumentException: No enum const class mypkg.Status.1 java.lang.Enum.valueOf(Enum.java:196) org.hibernate.type.EnumType.nullSafeGet(EnumType.java:110) Taking a look at EnumType.java, it is clear that Hibernate imposes ordinal stored as number and name stored as varchar. ========= IMHO, this is a "specification gap": JPA does not consider what to do if I'm trying to map a legacy enumerated value. Since I'm defining @Enumerated as "ordinal" and I have "0", "1", "2" on my database, I believe Hibernate should consider what I'm defining, not what an ancient DBA defined. Otherwise, I can't map this using only Hibernate Annotations/JPA (BTW, this code works with TopLink, only changing JPA provider on persistence.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

12 years, 3 months

2
2
0 / 0

[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

12 years, 3 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

12 years, 4 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-6896) Metamodel.managedType(...) implemented incorrectly

by Oliver Gierke (JIRA)

Metamodel.managedType(...) implemented incorrectly -------------------------------------------------- Key: HHH-6896 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6896 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.6.8 Reporter: Oliver Gierke Section 5.1.1 of the JPA specification defines {{Metamodel.managedType(...)}} as follows: {quote} Return the metamodel managed type representing the entity, mapped superclass, or embeddable class. {quote} Nevertheless the {{MetamodelImpl}} only considers entities, which clearly violates the spec. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

3
2
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

12 years, 4 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-6911) Write DiscriminatorValue to DiscriminatorColumn when combined with InheritanceType#JOINED

by Steve Ebersole (JIRA)

Write DiscriminatorValue to DiscriminatorColumn when combined with InheritanceType#JOINED ----------------------------------------------------------------------------------------- Key: HHH-6911 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6911 Project: Hibernate Core Issue Type: Improvement Components: annotations, metamodel Reporter: Steve Ebersole Priority: Minor The JPA spec states that {{DiscriminatorColumn}} can be used in conjunction with JOINED inheritence. The only section that seems to deal with this combination is _11.1.10 DiscriminatorColumn Annotation_ where it says {quote} For the SINGLE_TABLE mapping strategy, and typically also for the JOINED strategy, the persistence provider will use a type discriminator column. The DiscriminatorColumn annotation is used to define the discriminator column for the SINGLE_TABLE and JOINED inheritance mapping strategies. {quote} Apparently this is meant to imply that even if providers do not need/use the discriminator for concrete class resolution (reading) they are still expected to write it out to the database. Dunno, thats just what we have been told :) Anyway, like I said, Hibernate itself does not need the discriminator column/value to interpret the concrete classes. However, in the interest of portability we certainly *could* write it out. Longer term -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

6
12
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

12 years, 4 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

12 years, 4 months

3
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2011