March 2010 - hibernate-issues - Jboss List Archives

[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

15 years, 5 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HBX-1042) Make DocHelper robust against failing buildSettings()

by Arnout Engelen (JIRA)

Make DocHelper robust against failing buildSettings() ----------------------------------------------------- Key: HBX-1042 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1042 Project: Hibernate Tools Issue Type: Improvement Components: hbm2doc Reporter: Arnout Engelen Attachments: dochelper.diff.txt DocHelper calls cfg.buildSettings(). to get the Dialect, default catalog name and default schema name. However, cfg.buildSettings() may fail with a HibernateException (example below). It would be nice to have DocHelper handle this more gracefully. Attached is a simple patch that does this. (background: I'd like to use the Configuration I'm getting from a Spring LocalSessionFactoryBean, which after initial creation leaves its LocalDataSourceConnectionProvider in a state that yiels a HibernateException when calling 'configure()' on it, which buildSettings() does. Because of this issue, I cannot use the DocExporter for my Spring-based hibernate configurations) -- 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, 5 months

2
10
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-275) support new NIOFSDirectory, a multithreaded optimized FSDirectory

by Sanne Grinovero (JIRA)

support new NIOFSDirectory, a multithreaded optimized FSDirectory ----------------------------------------------------------------- Key: HSEARCH-275 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-275 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Assignee: Sanne Grinovero # LUCENE-753: Added new Directory implementation org.apache.lucene.store.NIOFSDirectory, which uses java.nio's FileChannel to do file reads. On most non-Windows platforms, with many threads sharing a single searcher, this may yield sizable improvement to query throughput when compared to FSDirectory, which only allows a single thread to read from an open file at a time. (Jason Rutherglen via Mike McCandless) -- 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, 5 months

3
14
0 / 0

[Hibernate-JIRA] Created: (HV-70) Add @Equals(property="name")

by Juergen Zimmermann (JIRA)

Add @Equals(property="name") ---------------------------- Key: HV-70 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-70 Project: Hibernate Validator Issue Type: New Feature Affects Versions: 3.1.0.CR2 Reporter: Juergen Zimmermann It would be nice to have something like: public class Customer implements Serializable { private String password; @Equals(property="password") // the name of the property above private String password2; ... } Such entity classes would be helpful for user interfaces e.g. inside registration pages where you want to avoid typos or ensure that a human being is registering. -- 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, 5 months

4
4
0 / 0

[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

15 years, 5 months

4
28
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-390) HibernateSearchResourceLoader uses default charset for reading resources

by Ivan Holub (JIRA)

HibernateSearchResourceLoader uses default charset for reading resources ------------------------------------------------------------------------ Key: HSEARCH-390 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-390 Project: Hibernate Search Issue Type: Bug Components: analyzer Affects Versions: 3.1.1.GA Reporter: Ivan Holub HibernateSearchResourceLoader uses default charset for reading resources. So stop words are not working for other languages. @AnalyzerDef(name="ru", tokenizer=(a)TokenizerDef(factory=StandardTokenizerFactory.class), filters={ @TokenFilterDef(factory=StandardFilterFactory.class), @TokenFilterDef(factory=LowerCaseFilterFactory.class), @TokenFilterDef(factory=StopFilterFactory.class, params=@Parameter(name="words", value="stopwords/stopwords_ru.txt")), @TokenFilterDef(factory=SnowballPorterFilterFactory.class, params=@Parameter(name="language", value="Russian")) stopwords/stopwords_ru.txt is UTF-8 file To fix the problem I constructed Analyzer in separate class and without using AnalyzerDef. -- 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, 5 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-416) Analyze Payload and how this could be used to store id and class in the index and not the document

by Emmanuel Bernard (JIRA)

Analyze Payload and how this could be used to store id and class in the index and not the document -------------------------------------------------------------------------------------------------- Key: HSEARCH-416 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-416 Project: Hibernate Search Issue Type: Sub-task 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

15 years, 5 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-228) Write a reliability test under stress

by Emmanuel Bernard (JIRA)

Write a reliability test under stress ------------------------------------- Key: HSEARCH-228 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-228 Project: Hibernate Search Issue Type: Task Reporter: Emmanuel Bernard Fix For: 3.1.0 Write an app inserting, updating deleting concurrently Also searching concurrently and make sure data is reliable during search all that during stress conditions. -- 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, 5 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-119) Enable lucene similarity seach based on term frequency vector by QBE-like query

by Xin Wu (JIRA)

Enable lucene similarity seach based on term frequency vector by QBE-like query --------------------------------------------------------------------------------- Key: HSEARCH-119 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-119 Project: Hibernate Search Issue Type: New Feature Reporter: Xin Wu Scenario: Your bookstore application needs a function as follow: When a user see a list of books, there is a similar books button for each book. If user clicks this button of one book item, the similar books will be listed. The similarity is evaluated by all terms in summary of the book and similarity score is dirived from Lucene search similarity package which uses term frequency vectors in calculation. It will compare the target in all corresponding documents in the index and return the hits in order. Note: this funtion is not same as fuzzy query which still needs a definite query condition. In the contrast, similarity search only needs one or several fields (of object/document)to be specified and the rest will be automatically caculated by lucene. A QBE-like API should be used to make such query. You can specify the fields in such query. Please see discussion about this topic in the forum: http://forum.hibernate.org/viewtopic.php?t=979692 -- 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, 5 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-469) Filter caching using causes excessive memory use

by Dobes Vandermeer (JIRA)

Filter caching using causes excessive memory use ------------------------------------------------ Key: HSEARCH-469 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-469 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.1.1.GA Environment: hibernate-core-3.3.2.GA Reporter: Dobes Vandermeer The CachingWrapperFilter uses the reader instance (CacheableMultiReader) as a key for the caching. However, the reader instance keeps pointers to byte arrays in its "normsCache" and in the "normsCache" of its sub-readers; each array has one byte for each document in the index and in some cases there will be multiple of these arrays associated with differet fields. For an index with millions of records this can result in an apparent "leak" of hundreds of megabytes of memory as those readers are not re-used and the MRU cache used by default will keep up to 128 hard references to the readers by default. The search system must either re-use or delete the normsCache, OR the cache key for these filters should be tied to something else that doesn't keep references to potentially huge data arrays. Otherwise the scalability of the search subsystem is significantly impacted when using filters, as you must have enough heap to accommodate up to 128 times as many copies of the norms arrays. -- 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, 5 months

3
14
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 March 2010