September 2010 - hibernate-issues

[Hibernate-JIRA] Created: (HHH-5136) map-key-column is broken

by Harald Wellmann (JIRA)

map-key-column is broken ------------------------ Key: HHH-5136 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5136 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5.1 Environment: Hibernate 3.5.1, PostgreSQL 8.4.3 Reporter: Harald Wellmann Priority: Critical I have an entity with a Map<String, Embeddable> with unexpected behaviour. The problem is that annotation mappings and the equivalent XML mappings yield different results. (For brevity, I'm leaving out the getters and setters and the SQL constraints in the following examples.) Here is my Embeddable: {code:java} @Embeddable public class LocalizedString { private String language; private String text; } {code} And this is the containing entity: {code:java} @Entity public class Amenity { @Id @Column(name = "amenity_id") @GeneratedValue private long id; @ElementCollection @CollectionTable(name = "amenity_name", joinColumns = @JoinColumn(name = "amenity_id")) @MapKeyColumn(name = "language_map_key") private Map<String, LocalizedString> names = new HashMap<String, LocalizedString>(); } {code} Hibernate generates the following collection table: {code:sql} CREATE TABLE amenity_name ( amenity_id bigint NOT NULL, "language" character varying(255), "text" character varying(255), language_map_key character varying(255) NOT NULL ) {code} Now when replacing the annotations by the following XML mapping {code:xml} <?xml version="1.0" encoding="UTF-8"?> <entity-mappings version="2.0" xmlns="http://java.sun.com/xml/ns/persistence/orm" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_2_0.xsd"> <entity class="Amenity"> <attributes> <id name="id"> <column name="amenity_id"/> <generated-value /> </id> <element-collection name="names"> <map-key-column name="language_map_key" /> <collection-table name="amenity_name"> <join-column name="amenity_id" referenced-column-name="amenity_id"/> </collection-table> </element-collection> </attributes> </entity> <embeddable class="LocalizedString"> <attributes> <basic name="language"></basic> <basic name="text"></basic> </attributes> </embeddable> </entity-mappings> {code} the generated SQL looks like this: {code:sql} CREATE TABLE amenity_names ( amenity_amenity_id bigint NOT NULL, "language" character varying(255), "text" character varying(255), names_key character varying(255) NOT NULL ) {code} It seems that the map-key-column and collection-table settings are simply ignored. Another question: The column language_map_key is actually redundant, I would like to use the language column as map key instead. The JPA 2.0 spec is a bit vague on this case. When the map value is an entity, @MapKey can be used to select a property of the entity value as map key, but it is not clear to me whether the spec supports supressing the separate key column when the map value is an embeddable. I tried using @MapKeyColumn(name="language"), but then Hibernate complained about a duplicate column. Eclipselink (the version contained in Glassfish v3) accepts this usage and suppresses the duplicate column, i.e. the join table has the form {code:sql} CREATE TABLE amenity_name ( amenity_id bigint NOT NULL, "language" character varying(255), "text" character varying(255) ) {code} -- 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, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4581) Embedded objects in criteria API does not work

by Jaroslaw Lewandowski (JIRA)

Embedded objects in criteria API does not work ---------------------------------------------- Key: HHH-4581 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4581 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.5.0-Beta-2 Reporter: Jaroslaw Lewandowski It not possible to use Embedded attribute in Criteria API. E.g. having the following entity @Entity class Client { @Embedded private Name name; } @Embeddable public class Name implements Serializable { @Basic private String firstName; @Basic private String lastName; } The following throws an exception CriteriaBuilder cb = em.getCriteriaBuilder(); CriteriaQuery<ClientCard> cq = cb.createQuery(Client.class); Root<ClientCard> root = cq.from(ClientCard.class); cq.where(cb.equal(root.get(Client_.name).get(Name_.firstName)), "blah"); em.createQuery(cq).getResultList(); Saying that Name is not managed entity: Caused by: java.lang.IllegalArgumentException: Not an managed type: class com.phorest.memento.server.domain.Name at org.hibernate.ejb.metamodel.MetamodelImpl.managedType(MetamodelImpl.java:171) at org.hibernate.ejb.criteria.JoinImpl.<init>(JoinImpl.java:54) at org.hibernate.ejb.criteria.FromImpl.constructJoin(FromImpl.java:193) at org.hibernate.ejb.criteria.FromImpl.join(FromImpl.java:176) at org.hibernate.ejb.criteria.FromImpl.join(FromImpl.java:169) at org.hibernate.ejb.criteria.FromImpl.get(FromImpl.java:559) -- 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, 4 months

4
10
0 / 0

[Hibernate-JIRA] Created: (HHH-3659) statistics: Execution time of a query

by Anthony Patricio (JIRA)

statistics: Execution time of a query ------------------------------------- Key: HHH-3659 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3659 Project: Hibernate Core Issue Type: New Feature Components: query-hql, query-sql Affects Versions: 3.3.1 Reporter: Anthony Patricio Priority: Trivial Currently we have min, average and max execution time. Could be useful to log each query execution time. -- 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, 4 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3007) Unchanged persistent set gets marked dirty on session.merge()

by Lars Koedderitzsch (JIRA)

Unchanged persistent set gets marked dirty on session.merge() ------------------------------------------------------------- Key: HHH-3007 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3007 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Reporter: Lars Koedderitzsch Persistent sets are marked dirty on session.merge() even if there have been no changes to the collection. This is especially painful when the collection is immutable and results in an "changed an immutable collection instance" exception on flush. I tracked the behaviour down a bit and believe the problem to be in CollectionType.replace(). Here the passed in orginal PersistentSet is replaced by a plain HashSet in this line: Object result = target == null || target == original ? instantiateResult( original ) : target; The "result" object (HashSet) is then passed to the CollectionType.replaceElements() method (instead of the original PersistentSet). In CollectionType.replaceElements() the code to clear the dirty state of the collection does not execute anymore, because the passed-in "original" collection is the described HashSet and *not* the original PersistentSet. This way the PersistentSet remains marked dirty. A workaround is to manually clear the dirty state of an immutable collection after merge but before flush. -- 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, 4 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HV-362) Including Annotation Processor in Eclipse results in java.lang.OutOfMemoryError: Java heap space

by Marcel Tietze (JIRA)

Including Annotation Processor in Eclipse results in java.lang.OutOfMemoryError: Java heap space ------------------------------------------------------------------------------------------------ Key: HV-362 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-362 Project: Hibernate Validator Issue Type: Bug Components: annotation-processor Affects Versions: 4.1.0.Final Environment: eclipse.buildId=I20100608-0911 java.version=1.6.0_15 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=de_DE Framework arguments: -product org.eclipse.epp.package.jee.product Command-line arguments: -os win32 -ws win32 -arch x86 -product org.eclipse.epp.package.jee.product Reporter: Marcel Tietze Assignee: Hardy Ferentschik Priority: Minor I added the annotation processor like in http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html/ch0... chapter 8.4.2.1. Eclipse described. After a while the build process stops and the following exception occures: {code} An internal error occurred during: "Building Workspace". java.lang.OutOfMemoryError: Java heap space at org.eclipse.jdt.core.dom.ASTNode$NodeList.<init>(ASTNode.java:1112) at org.eclipse.jdt.core.dom.Block.<init>(Block.java:70) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:511) at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:180) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2709) at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1266) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:876) at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:577) at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:888) at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:859) at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356) at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:271) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:217) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:142) at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:627) at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:338) at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:60) at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254) at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:178) at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:629) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:172) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:203) at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:255) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:258) at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:311) at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:343) at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:344) {code} -- 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, 4 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-577) IllegalArgumentException when trying to delete proxy class

by Tom (JIRA)

IllegalArgumentException when trying to delete proxy class ---------------------------------------------------------- Key: HSEARCH-577 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-577 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.2.1 Environment: Hibernate Search 3.2.1 Hibernate Core 3.5.2 Reporter: Tom Attachments: ProxyTestCase.zip I'm receiving an IllegalArgumentException while trying to delete an entity that is a part of a @ContainedIn/@IndexedEmbedded relationship. I created a testcase to reproduce the error i'm seeing. The original issue that prompted this was actually a ClassCastException as discussed in this thread https://forum.hibernate.org/viewtopic.php?f=9&t=1006381 however in creating the test case i was unable to replicate that particular error, but ran into this one, which seemed similar. -- 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, 4 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-513) Hibernate Search 3.2.0.CR1 listeners cause long delays when indexing entities saved in different transactions

by Florin Haizea (JIRA)

Hibernate Search 3.2.0.CR1 listeners cause long delays when indexing entities saved in different transactions ------------------------------------------------------------------------------------------------------------- Key: HSEARCH-513 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-513 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.2.0.CR1 Environment: Hibernate 3.5.1-Final Spring 3.0.2 MySQL Connector 5.1.6 Reporter: Florin Haizea Attachments: HibernateSearchJira.zip I have 3 entities Person, Event and ParentOfBirthEvent. I save about 8000 Person objects in batches of 20, each batch is being saved in a different transaction. After a sufficient number of entities have been persisted (the saving and indexing of initial batches takes between150ms and 500ms) the indexing of the entities that are saved in some of the following batches takes a very large amount of time (sometime even minutes for a whole batch). The problem is that in order for these delays to appear there has to be a certain relationship between the objects saved in the current batch and objects saved in previous batches. The only way in which I can reproduce this 100% is by importing a file (which was submitted by one of the users of our app), creating entities based on the data in that file and saving the entities in batches of 20. When I reach batch number 273 or so the indexing starts taking a lot of time. If I removed the @IndexedEmbedded annotation from the "parent" field in the ParentOfBirthEvent class the problem is solved. Also, if I removed all the hibernate search listeners from the sessionFactory the problem is solved. -- 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, 4 months

7
68
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-570) Optimize the o^2 loop in DocumentBuilderIndexedEntity.addWorkToQueue

by Sanne Grinovero (JIRA)

Optimize the o^2 loop in DocumentBuilderIndexedEntity.addWorkToQueue -------------------------------------------------------------------- Key: HSEARCH-570 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-570 Project: Hibernate Search Issue Type: Improvement Affects Versions: 3.3.0.Alpha1, 3.2.1, 3.2.0.Final Reporter: Sanne Grinovero Fix For: 3.3.0 there's a long-standing comment in the method: bq. //TODO with the caller loop we are in a n^2: optimize it using a HashMap for work recognition Apparently it has a critical impact in some scenarios: [this forum post|https://forum.hibernate.org/viewtopic.php?f=9&t=1006054] mentions the algorithm "running for days" in a 1000 elements change in a single transaction. -- 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, 4 months

2
8
0 / 0

[Hibernate-JIRA] Created: (METAGEN-29) Embedded generic types not supported by metamodel generator

by Adrian Hummel (JIRA)

Embedded generic types not supported by metamodel generator ----------------------------------------------------------- Key: METAGEN-29 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-29 Project: Hibernate Metamodel Generator Issue Type: Bug Components: processor Affects Versions: 1.0.0-CR-1 Environment: Hibernate 3.5.0-CR-2 Reporter: Adrian Hummel Assignee: Hardy Ferentschik Priority: Critical Attachments: bugreport.zip Scenario: I have a @MappedSuperclass defining an abstract entity. This class has a technical primary key and a business identity. The business identity is realized by means of a generic embeddable (e.g. for a Customer class there is a corresponding CustomerId class for its business identity). The JPAMetaModelEntityProcessor does generate the AbstractEntity_ class but does only include the primary key field but omits the generic field for the business identity (which leads to subsequent errors when accessing this field using a CriteriaBuilder). Attached a mini project with a test case which illustrates the problem. -- 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, 4 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4539) Make UPPER and LOWER work on MS SQL Server text and ntext columns

by Sergiu Dumitriu (JIRA)

Make UPPER and LOWER work on MS SQL Server text and ntext columns ----------------------------------------------------------------- Key: HHH-4539 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4539 Project: Hibernate Core Issue Type: Improvement Components: query-sql Affects Versions: 3.3.2 Environment: MS SQL Server Reporter: Sergiu Dumitriu Trying to use UPPER or LOWER on a text column results in: ERROR util.JDBCExceptionReporter - Argument data type text is invalid for argument 1 of upper function. http://databases.aspfaq.com/database/why-do-i-get-argument-data-type-text... suggests a workaround, which I think should be automatically used by Hibernate, so that the HQL query can work with other dialects. -- 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, 4 months

3
3
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 September 2010