[Hibernate-JIRA] Created: (HSEARCH-647) WorkPlan causes ConcurrentModificationException on finding new entity types during processContainedInAndPrepareExecution
by Sanne Grinovero (JIRA)
WorkPlan causes ConcurrentModificationException on finding new entity types during processContainedInAndPrepareExecution
------------------------------------------------------------------------------------------------------------------------
Key: HSEARCH-647
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-647
Project: Hibernate Search
Issue Type: Bug
Components: engine
Affects Versions: 3.3.0.CR2
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Fix For: 3.3.0.Final
org.hibernate.HibernateException: Error while indexing in Hibernate Search (before transaction completion)
at org.hibernate.search.backend.impl.EventSourceTransactionContext$DelegateToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTransactionContext.java:175)
at org.hibernate.engine.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:543)
at org.hibernate.engine.ActionQueue.beforeTransactionCompletion(ActionQueue.java:216)
at org.hibernate.impl.SessionImpl.beforeTransactionCompletion(SessionImpl.java:571)
at org.hibernate.jdbc.JDBCContext.beforeTransactionCompletion(JDBCContext.java:250)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:138)
at my.code tx.commit();
Caused by: java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$ValueIterator.next(HashMap.java:822)
at org.hibernate.search.engine.WorkPlan.processContainedInAndPrepareExecution(WorkPlan.java:119)
at org.hibernate.search.backend.WorkQueue.prepareWorkPlan(WorkQueue.java:133)
at org.hibernate.search.backend.impl.BatchedQueueingProcessor.prepareWorks(BatchedQueueingProcessor.java:124)
at org.hibernate.search.backend.impl.PostTransactionWorkQueueSynchronization.beforeCompletion(PostTransactionWorkQueueSynchronization.java:89)
at org.hibernate.search.backend.impl.EventSourceTransactionContext$DelegateToSynchronizationOnBeforeTx.doBeforeTransactionCompletion(EventSourceTransactionContext.java:172)
... 7 more
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-5751) MappingException: using @Column in Embedded ID classes fail when also used in an @JoinColumn in the entity class
by Karsten Wutzke (JIRA)
MappingException: using @Column in Embedded ID classes fail when also used in an @JoinColumn in the entity class
----------------------------------------------------------------------------------------------------------------
Key: HHH-5751
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5751
Project: Hibernate Core
Issue Type: Bug
Components: annotations, core, metamodel
Affects Versions: 3.6.0
Environment: Hibernate 3.6, JavaSE, HSQLDB, Ant
Reporter: Karsten Wutzke
Priority: Critical
Attachments: zips-hib-embeddedid-column-broken.zip
Here's the DB design (DDL):
CREATE TABLE Countries
(
iso_code CHAR(2) NOT NULL,
name VARCHAR(50) NOT NULL,
PRIMARY KEY (iso_code)
);
CREATE TABLE Zips
(
country_code CHAR(2) NOT NULL,
code VARCHAR(10) NOT NULL,
PRIMARY KEY (country_code, code),
FOREIGN KEY (country_code) REFERENCES Countries (iso_code)
);
Here's the Zip class + composite primary key class:
@Entity
@Table(name = "Zips")
public class Zip implements Serializable
{
@EmbeddedId
private ZipId embeddedId;
@ManyToOne
@JoinColumn(name = "country_code", referencedColumnName = "iso_code")
private Country country = null;
...
}
@Embeddable
public class ZipId implements Serializable
{
@Column(name = "country_code", insertable = false, updatable = false)
private String countryCode;
@Column(name = "code")
private String code;
...
}
Hibernate stack trace:
Exception in thread "main" javax.persistence.PersistenceException: [PersistenceUnit: zips] Unable to build EntityManagerFactory
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:911)
at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:57)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:32)
at tld.zips.Main.main(Main.java:27)
Caused by: org.hibernate.MappingException: Repeated column in mapping for entity: tld.zips.model.Zip column: country_code (should be mapped with insert="false" update="false")
at org.hibernate.mapping.PersistentClass.checkColumnDuplication(PersistentClass.java:675)
at org.hibernate.mapping.PersistentClass.checkPropertyColumnDuplication(PersistentClass.java:697)
at org.hibernate.mapping.PersistentClass.checkColumnDuplication(PersistentClass.java:719)
at org.hibernate.mapping.PersistentClass.validate(PersistentClass.java:473)
at org.hibernate.mapping.RootClass.validate(RootClass.java:235)
at org.hibernate.cfg.Configuration.validate(Configuration.java:1332)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1835)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:902)
... 4 more
The problem here is the @Column on the @Embeddable composite primary key class. country_code is mapped as read-only (insertable = false, updatable = false) in the composite primary key class. The above syntax is JPA-compatible. Clearly, there's no other clean way where to put the @Column annotations but into the @Embeddable class. It's incomprehensible why this doesn't work. @Embeddable classes allow @Basic, @Column, @Enumerated, @Temporal, @Lob, and @Embedded on its columns, so this should work.
The exception vanishes when putting the insertable = false, updatable = false on the @JoinColumn, but this is not what I want. I prefer my associations to be writable...
The above syntax works perfectly with EclipseLink!
--
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, 5 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, 5 months
[Hibernate-JIRA] Updated: (HHH-1268) Unidirection OneToMany causes duplicate key entry violation when removing from list
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268?page=c... ]
Gail Badner updated HHH-1268:
-----------------------------
Affects Version/s: 3.5.6
3.6.0
> Unidirection OneToMany causes duplicate key entry violation when removing from list
> -----------------------------------------------------------------------------------
>
> Key: HHH-1268
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268
> Project: Hibernate Core
> Issue Type: Bug
> Affects Versions: 3.1, 3.5.6, 3.6.0
> Environment: 3.1 final
> MySql 4.1.14 using MYISAM tables
> Reporter: Rex Madden
> Assignee: Gail Badner
> Fix For: 3.2.x, 3.3.x
>
> Attachments: src.zip
>
>
> Simple OneToMany parent/child relationship using the default table structure (2 tables and a join table)
> Add 3 children to the parent. Flush. Remove the first child. Flush throws error:
> Exception in thread "main" org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:69)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:202)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:230)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:143)
> at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980)
> at UnidirectionalOneToManyRemoveFromListBug.main(UnidirectionalOneToManyRemoveFromListBug.java:27)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86)
> Caused by: java.sql.BatchUpdateException: Duplicate key or integrity constraint violation, message from server: "Duplicate entry '5' for key 2"
> at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1461)
> at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
> at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195)
> ... 11 more
> The problem is that there is a unique key on the relationship table that gets violated. The session removes the last row in the relationship table, then attempts to rewrite the child_id's. It fails since there is a uniqueness constraint on that column.
--
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, 5 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, 5 months
[Hibernate-JIRA] Created: (HHH-5727) Collection member declaration not handling optional AS in HQL.
by Dave Stephan (JIRA)
Collection member declaration not handling optional AS in HQL.
--------------------------------------------------------------
Key: HHH-5727
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5727
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2, 3.2.4.sp1
Reporter: Dave Stephan
HQL:
SELECT o FROM EntityBean AS o, IN (o.items) AS l WHERE l.itemValue = '1'
The log output gives the following:
2010-11-10 16:03:53,286 DEBUG [org.hibernate.hql.ast.QueryTranslatorImpl] (WorkerThread#0[127.0.0.1:60518]) parse() - HQL: SELECT o FROM EntityBean AS o, IN (o.items) AS l WHERE l.itemValue = '1'
2010-11-10 16:03:53,290 DEBUG [org.hibernate.hql.PARSER] (WorkerThread#0[127.0.0.1:60518]) Keyword 'AS' is being interpreted as an identifier due to: expecting IDENT, found 'AS'
2010-11-10 16:03:53,403 ERROR [org.hibernate.hql.PARSER] (WorkerThread#0[127.0.0.1:60518]) line 1:48: unexpected token: l
According to the jpa persistence spec the AS keyword is optional for collection declarations:
collection_member_declaration ::=
IN (collection_valued_path_expression) [AS] identification_variable
In hql.g we have:
inCollectionDeclaration!
: IN! OPEN! p:path CLOSE! a:alias
{ #inCollectionDeclaration = #([JOIN, "join"], [INNER, "inner"], #p, #a); }
;
Should this be a:asAlias rather than a:alias?
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-5740) EXTRA Lazy collection with inverse owner: PersistenSet still contains previosly removed elements
by Guenther Demetz (JIRA)
EXTRA Lazy collection with inverse owner: PersistenSet still contains previosly removed elements
-------------------------------------------------------------------------------------------------
Key: HHH-5740
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5740
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.0, 3.5.0-Final
Environment: Hibernate 3.6.0 (also 3.5.0 is affect of this bug), database indipendent (attached Testcase is based on hsqldb)
Reporter: Guenther Demetz
Priority: Critical
Attachments: TestExtraLazyCollectionWithInverseOwner.jar
When mapping a Set with inverse owner (= specifying mappedBy attribute)
and annotated with
@org.hibernate.annotations.LazyCollection (LazyCollectionOption.EXTRA)
then the removal of single elements doesn't work as expected:
the PersistentSet still contains elements which have previously removed.
..
assertTrue(a.assD.remove(d)); // removing element d from PersistentSet, this assert goes well
assertFalse(a.assD.contains(d)); // asserting PersistentSet doesn't contain element d anymore, FAILS !!
The contains method implementation of PersistentSet properly calls flush()
before executing the select-query, but anyway for some reason the registered DelayedOperation
(as before enqueued by the remove call) isn't properly brought to execution if the collection is declared with inverse owner.
This IMHO is a critical bug, as this behavior clearly violates the contracts of method
java.util.Set#remove(java.lang.Object) where the specifications says:
<quoted: "the set will not contain the specified element once the call returns">
Furthermore it could create serious damage to companies using hibernate:
imagine for example a company cancels a order-position and nevertheless the canceled position is subsequently delivered and invoiced to the customer.
Please see attached testcase for more details.
Thanks for attention.
--
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, 5 months