[Hibernate-JIRA] Created: (HHH-2097) LAZY property results in org.hibernate.TransientObjectException after merge
by Reto Urfer (JIRA)
LAZY property results in org.hibernate.TransientObjectException after merge
---------------------------------------------------------------------------
Key: HHH-2097
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2097
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: Hibernate3.2 cr4 with Annotations cr2 and EntityManager cr2, Oracle10g R2, WindowsXP
Reporter: Reto Urfer
Priority: Critical
Attachments: BugLazyPropertyMerge.zip
Entity1 has a property e2 which references Entity2. This property is defined as follows.
@ManyToOne(fetch = FetchType.LAZY, optional = false)
private Entity2 e2;
If you have an instance e1 of Entity1 which has not initialized property e2 and you merge e1 to the EntityManager within a transaction, then you get the following exception during commit:
Exception in thread "main" javax.persistence.RollbackException: Error while commiting the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:63)
at com.test.Test.main(Test.java:42)
Caused by: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: com.test.Entity1.e2 -> com.test.Entity2
at org.hibernate.engine.CascadingAction$9.noCascade(CascadingAction.java:350)
at org.hibernate.engine.Cascade.cascade(Cascade.java:139)
at org.hibernate.event.def.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:130)
at org.hibernate.event.def.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:121)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:65)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106)
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:53)
... 1 more
I added a small Testproject to reproduce this bug.
--
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
14 years, 2 months
[Hibernate-JIRA] Created: (HSEARCH-115) Add a default value for indexing null value
by Julien Brulin (JIRA)
Add a default value for indexing null value
-------------------------------------------
Key: HSEARCH-115
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-115
Project: Hibernate Search
Issue Type: Improvement
Components: mapping
Reporter: Julien Brulin
Hi,
Null elements are not indexed by lucene then it's not easy to use a nullable property in lucene query.
I have a TagTranslation entity in my model with a nullable property language. In this case null is used as default language for tag translation.
Each translation may have many variations like synonyms.
Because I can specified a default value for null value in the @Field annotation like this @Field(index=Index.UN_TOKENIZED, store=Store.NO, default='null'), i can't search a cat tag with a default translation like this : +value:cat* +lang:null
<pre></code>
@Entity()
@Table(name="indexing_tag_trans")
@org.hibernate.annotations.Cache(usage=org.hibernate.annotations.CacheConcurrencyStrategy.READ_WRITE)
@Indexed
public class TagTranslation implements java.io.Serializable {
private static final long serialVersionUID = -1065316566731456110L;
@Id
@GeneratedValue(strategy=GenerationType.IDENTITY)
@DocumentId
private Integer id;
@Field(index=Index.UN_TOKENIZED, store=Store.NO)
private String language;
@Field(index=Index.TOKENIZED, store=Store.YES)
private String value;
@OneToMany(cascade=CascadeType.ALL, fetch=FetchType.LAZY)
@org.hibernate.annotations.Fetch(org.hibernate.annotations.FetchMode.SUBSELECT)
@JoinColumn(name="translation_id")
@IndexedEmbedded
private List<TagVariation> variations = new LinkedList<TagVariation>();
public TagTranslation() { }
...
</code>
</pre>
What do you think about that ?
Ps: sorry for english write, i am a french guy.
--
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
14 years, 2 months
[Hibernate-JIRA] Created: (ANN-668) Method in entity with return type of ArrayList<Object[]> causes failure to build session factory
by Clint Popetz (JIRA)
Method in entity with return type of ArrayList<Object[]> causes failure to build session factory
------------------------------------------------------------------------------------------------
Key: ANN-668
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-668
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Environment: Hibernate 3.2.X, no database needed (happens during factory build before connecting to db)
Reporter: Clint Popetz
Attachments: propertyTypeExtractorBug.tar.gz
The following source:
@javax.persistence.Entity
public class TestEntity {
@javax.persistence.Id
public int Id;
public java.util.ArrayList<Object[]> badMethod() { return null; }
public static void main(String args[]) {
new org.hibernate.cfg.AnnotationConfiguration().addAnnotatedClass(TestEntity
.class).configure().buildSessionFactory();
}
}
will cause:
java.lang.IllegalArgumentException: No PropertyTypeExtractor available for type void
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.toXType(JavaReflectionManager.java:164)^M
at org.hibernate.annotations.common.reflection.java.JavaXMethod.create(JavaXMethod.java:18)
at org.hibernate.annotations.common.reflection.java.JavaReflectionManager.getXMethod(JavaReflectionManager.java:128)
at org.hibernate.annotations.common.reflection.java.JavaXClass.getDeclaredMethods(JavaXClass.java:114)
at org.hibernate.validator.ClassValidator.initValidator(ClassValidator.java:214)
at org.hibernate.validator.ClassValidator.<init>(ClassValidator.java:133)
at org.hibernate.validator.event.ValidateEventListener.initialize(ValidateEventListener.java:91)
at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:356)
at org.hibernate.cfg.Configuration.getInitializedEventListeners(Configuration.java:1304)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
Changing the return type to List<Object[]> avoids the bug.
Attached is a tgz of an ant-buildable project; typing "ant run" will illustrate the bug.
--
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
14 years, 3 months
[Hibernate-JIRA] Created: (HHH-2319) StatelessInterceptor
by Max Rydahl Andersen (JIRA)
StatelessInterceptor
--------------------
Key: HHH-2319
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2319
Project: Hibernate3
Type: New Feature
Components: core
Versions: 3.2.1
Reporter: Max Rydahl Andersen
It would make sense to have an Interceptor for StatelessSession to solve the following usecases:
Log/adjust SQL: onPrepareStatement
Proper entityname handling: instantiate/getEntity
Maybe also tx interaction: afterTransationBegin/beforeTransactionCompletion/afterTransactionCompletion
Technically it could be solved by just allowing to pass in a normal interceptor to a StatelessSession and just
document that the state oriented callbacks will not be called. Alternatively we can create a StatelessInterceptor that
only implement the releavant methods and wrap that instance into an internal Interceptor.
--
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
14 years, 3 months
[Hibernate-JIRA] Created: (HHH-2007) Hibernate doesn't support optional one-to-one associations
by Andrei Iltchenko (JIRA)
Hibernate doesn't support optional one-to-one associations
----------------------------------------------------------
Key: HHH-2007
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2007
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Reporter: Andrei Iltchenko
Hibernate doesn't properly support optional one-to-one associations, e.g. Person (0..1) -- (0..1) Passport.
The Hibernate books and reference all talk of two ways of mapping one-to-one associations:
1. using a many-to-one fk association with a unique constraint on the fk;
2. using a pk association.
the trouble with both of them is that they enforce the mandatory property of an association end, which sometimes is not desirable. The first way enforces the mandatory property with the uniqueness constraint on the fk, the other by using the fact that one table's pk is its fk.
I tried to see if I could adapt the 1st way of representing one-to-ones to
support optional association ends. What I did was simply remove the unique and not null constrains from DDL generated (without removing it it would be impossible to have a Person record that doesn't reference a Passport record):
from
CREATE TABLE Person (
PassUniqueId VARCHAR (32) NOT NULL,
version INTEGER NOT NULL,
uniqueId VARCHAR (32) NOT NULL,
name VARCHAR (40) NULL,
PRIMARY KEY (uniqueId),
UNIQUE(PassUniqueId),
FOREIGN KEY (PassUniqueId) REFERENCES Passport (uniqueId)
);
to
CREATE TABLE Person (
PassUniqueId VARCHAR (32) NULL,
version INTEGER NOT NULL,
uniqueId VARCHAR (32) NOT NULL,
name VARCHAR (40) NULL,
PRIMARY KEY (uniqueId),
FOREIGN KEY (PassUniqueId) REFERENCES Passport (uniqueId)
);
but leave the uniqueness attribute in the mapping file:
<many-to-one
name="pass"
class="application.business.logic.Passport"
cascade="save-update,merge"
unique="true"
>
<column name="PassUniqueId"/>
</many-to-one>
The resulting solution worked fine and I was able to create instances of Person not linked to a Passport. However Hibernate didn't succed in keeping the association from degrading into a many-to-one. It enabled me to create two Persons linked with the same Passport:
PASSUNIQUEID | VIRSION | UNIQUEID | Name
================================================
0d8b3919fffff | 1 | 0d5fb1dcfff | John
0d8b3919fffff | 0 | 10fd07bdfff | Sam
A subsequent attempt at retrieving such Persons with Hibernate failed:
org.hibernate.HibernateException: More than one row with the given identifier was found: 0d8b3919ffffffd60151e135b6da0164, for class: application.business.logic.Passport.
Hibernate should be able to impose the single end property of such associations without relying on the underlying RDBMS engine and never allow them to degrade to many-to-ones.
--
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
14 years, 3 months