[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
13 years, 9 months
[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
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-5680) IN expression does not conform to JPA spec.
by Azuo Lee (JIRA)
IN expression does not conform to JPA spec.
-------------------------------------------
Key: HHH-5680
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5680
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.0
Reporter: Azuo Lee
According to JPA 2.0 spec 4.6.9, the sytax for an IN expression should be:
in_expression ::=
{state_field_path_expression | type_discriminator} [NOT] IN
{ ( in_item {, in_item}* ) | (subquery) | collection_valued_input_parameter }
in_item ::= literal | single_valued_input_parameter
Note that parentheses are required only if a subquery, or one or more listerals or single_valued_input_parameters is used, but should be absent if a collection_valued_input_parameter is used.
For example, with the following query parameters:
p1 : String "01";
p2 : String "02";
p3 : List containing 2 Strings "01" and "02";
the following IN expressions should all be legal, per JPA spec:
IN ("01", "02")
IN (:p1, :p2)
IN (:p1)
IN :p3
but the following expressions are ILLEGAL:
IN :p1
IN (:p3)
Current Hibernate implementation requires parentheses as mandatory in an IN expression, this is not conform to the JPA spec.
Using of parentheses in an IN expression provides a strict syntax to distinguish between a single_valued_input_parameter and a collection_valued_input_parameter, which is more reliable than "guessing" the semantics of the parameter by examining its Java 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, 9 months
[Hibernate-JIRA] Created: (HHH-5694) Unique constraint violation when removing an item from a unidirectional OneToMany ordered List
by Pascal Thivent (JIRA)
Unique constraint violation when removing an item from a unidirectional OneToMany ordered List
----------------------------------------------------------------------------------------------
Key: HHH-5694
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5694
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 3.6.0, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5.0-Final
Environment: Tested with Hibernate 3.5+ on H2, Derby, HSQLDB
Reporter: Pascal Thivent
I have a {{Foo}} entity that has a unidirectional ordered {{OneToMany}} {{List}} of {{Bars}}:
{code}
@Entity
public class Foo {
@Id @GeneratedValue
private Long id;
@OneToMany
@OrderColumn(name = "order_index")
@JoinTable(name = "foo_bar_map", joinColumns = @JoinColumn(name = "foo_id"), inverseJoinColumns = @JoinColumn(name = "bar_id"))
private List<Bar> bars;
//...
}
{code}
So let's say {{Foo#1}} holds a list with {{Bar#1}}, {{Bar#2}}, {{Bar#3}} (in that order). When removing {{Bar#1}} from the List and persisting [[Foo#1}}, Hibernate performs the following weird SQL:
{code}
delete from foo_bar_map where foo_id=1 and order_index=2
update foo_bar_map set bar_id=2 where foo_id=1 and order_index=0
{code}
And this obviously fails with a unique constraint violation. Why does Hibernate delete the last item from the join table? Why does Hibernate mess with the bar_id? Shouldn't Hibernate update the order_column instead?
I'm attaching a mavenized test allowing to reproduce, run {{mvn test}}.
FWIW, this works with the RI (run {{mvn test -Peclipselink,h2}}).
--
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, 9 months
[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
13 years, 10 months
[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
13 years, 10 months
[Hibernate-JIRA] Created: (HV-387) org.hibernate.validator.cfg.defs.GenericConstraintDef should (probably) not extend the raw type ConstraintDef
by Dag Hovland (JIRA)
org.hibernate.validator.cfg.defs.GenericConstraintDef should (probably) not extend the raw type ConstraintDef
-------------------------------------------------------------------------------------------------------------
Key: HV-387
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-387
Project: Hibernate Validator
Issue Type: Bug
Components: engine
Reporter: Dag Hovland
Assignee: Hardy Ferentschik
Priority: Trivial
Attachments: ConstraintDef.diff, GenericConstraintDef.diff
The class
org.hibernate.validator.cfg.defs.GenericConstraintDef
extends the raw type ConstraintDef. Using maven, it compiles, but in Eclipse (with jdk-1.6) We get
the following error:
"Name clash: The method groups(Class<?>...) of type GenericConstraintDef has the same erasure as
groups(Class...) of type ConstraintDef but does not override it"
and similar for the method "payload". The others methods give no errors. We do not understand why,
but it compiles after changing the definition to
public class GenericConstraintDef<A extends Annotation>
extends ConstraintDef<A>
and also replacing the "Class<?>" in the argument to the method "constraintType" with "Class<A>.
The fix seems more "correct", and I suggest this is changed in the source.
The file GenericConstraintDef.diff contains the mentioned fix, while ConstraintDef.diff adds type parameters to a few related methods in org.hibernate.validator.cfg.ConstraintDef
--
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, 10 months