October 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-575) More useful error message on bridge indexing failure

by Ben Dotte (JIRA)

More useful error message on bridge indexing failure ---------------------------------------------------- Key: HSEARCH-575 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-575 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.2.0.Final Environment: Hibernate 3.5.3, SQL Server Reporter: Ben Dotte Priority: Minor I have run into occasional error messages during initial indexing while trying to setup my field mappings like the one below. The problem with this error is that it doesn't tell me which class or field is failing. With over 300 mapped fields across many classes, I have a hard time tracking down the culprit. Could bridge exceptions be wrapped and rethrown with information about the type and field? java.lang.ClassCastException: java.lang.Long cannot be cast to java.lang.String at org.hibernate.search.bridge.builtin.StringBridge.objectToString(StringBridge.java:38) ~[hibernate-search-3.2.0.Final.jar:3.2.0.Final] at org.hibernate.search.bridge.TwoWayString2FieldBridgeAdaptor.objectToString(TwoWayString2FieldBridgeAdaptor.java:50) ~[hibernate-search-3.2.0.Final.jar:3.2.0.Final] at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.index(EntityConsumerLuceneworkProducer.java:140) ~[hibernate-search-3.2.0.Final.jar:3.2.0.Final] at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.indexAllQueue(EntityConsumerLuceneworkProducer.java:117) ~[hibernate-search-3.2.0.Final.jar:3.2.0.Final] at org.hibernate.search.batchindexing.EntityConsumerLuceneworkProducer.run(EntityConsumerLuceneworkProducer.java:92) ~[hibernate-search-3.2.0.Final.jar:3.2.0.Final] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [na:1.6.0_20] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [na:1.6.0_20] at java.lang.Thread.run(Thread.java:619) [na:1.6.0_20] -- 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, 8 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-5640) Import DialectFactory and DialectResolver services

by Steve Ebersole (JIRA)

Import DialectFactory and DialectResolver services -------------------------------------------------- Key: HHH-5640 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5640 Project: Hibernate Core Issue Type: Task Components: core Reporter: Steve Ebersole Fix For: 4.0.0.Alpha1 -- 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, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5639) Import ConnectionProvider service

by Steve Ebersole (JIRA)

Import ConnectionProvider service --------------------------------- Key: HHH-5639 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5639 Project: Hibernate Core Issue Type: Task Components: core Reporter: Steve Ebersole Assignee: Gail Badner Fix For: 4.0.0.Alpha1 -- 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, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-606) Exceptions during indexing are logged but swallowed when using local transactions (not JTA)

by Emmanuel Bernard (JIRA)

Exceptions during indexing are logged but swallowed when using local transactions (not JTA) ------------------------------------------------------------------------------------------- Key: HSEARCH-606 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-606 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.3.0.Beta1 Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.3.0.Beta2 -- 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, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-366) The documentation refers to http://repository.jboss.com/maven2: this should be fixed

by Emmanuel Bernard (JIRA)

The documentation refers to http://repository.jboss.com/maven2: this should be fixed ------------------------------------------------------------------------------------ Key: HV-366 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-366 Project: Hibernate Validator Issue Type: Improvement Components: documentation Affects Versions: 4.1.0.Final Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik See http://docs.jboss.org/hibernate/stable/validator/reference/en-US/html_sin... -- 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, 8 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HV-307) Support @Past/@Future annotations at types from the Joda Time API

by Gunnar Morling (JIRA)

Support @Past/@Future annotations at types from the Joda Time API ----------------------------------------------------------------- Key: HV-307 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-307 Project: Hibernate Validator Issue Type: New Feature Affects Versions: 4.1.0 Reporter: Gunnar Morling Assignee: Hardy Ferentschik Background: =========== The Bean Validation API specifies the annotations @Past and @Future, which are allowed at the JDK types Date and Calendar. Due to several issues and restrictions of these JDK types the open-source Joda Time API (http://joda-time.sourceforge.net/) which provides alternative date/time types became quite popular within the last years. To do: ====== * Hibernate Validator should add support for @Past/@Future for the Joda API date/times types by providing ConstraintValidator implementations for these types. * The Joda Time API should be added as optional dependency to HV. Upon runtime HV should check reflectively if Joda is on the class path. If that's the case, the Joda validators should be registered. * The HV reference guide should mention the additional types at which the @Past/@Future are supported. -- 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, 8 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-605) @ContainedIn does not work on deletes.

by Kyrill Alyoshin (JIRA)

@ContainedIn does not work on deletes. -------------------------------------- Key: HSEARCH-605 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-605 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.2.1 Reporter: Kyrill Alyoshin So, let's say we have a @Indexed entity Vendor (the parent) that is in a bi-directional @OneToMany relationship with entity Address (the child). Vendor maps the collection of Address'es as @IndexedEmbedded. Address is NOT @Indexed but does map its parent vendor association as @ContainedIn. Whenever Address entity is retrieved and session.delete'ed, the parent Vendor's index is NOT updated. Everything works fine with update operations. This obviously happens because the collection of addresses in parent vendor still contains the deleted address. (If the deleted address is manually removed from collection, everything works fine). Now... I realize that it is not in Hibernate style to automatically severe the association when a child entity is deleted. However, it seems that Hibernate Search should provide such functionality. This does lead to very subtle, hard to diagnose bugs. I assume when Vendor's collection is flushed it is fairly trivial to detect which addresses have been deleted and which not (inside the listener). -- 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, 8 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-604) Add better exception handling for FulltextQueryImpl.calculateTopDocsRetrievalSize()

by Hardy Ferentschik (JIRA)

Add better exception handling for FulltextQueryImpl.calculateTopDocsRetrievalSize() ----------------------------------------------------------------------------------- Key: HSEARCH-604 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-604 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.3.0.Beta1 Reporter: Hardy Ferentschik Fix For: 3.3.0.Beta2 Having a page offset of {{0}} and a page size of {{0}} (arguably a bad combination) you get a {code} java.lang.IllegalArgumentException: nDocs must be > 0 at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:169) at org.apache.lucene.search.Searcher.search(Searcher.java:181) {code} We should improve the code and error handling. With a page size of {{0}} we can return just the empty list. See also - https://forum.hibernate.org/viewtopic.php?f=9&t=994710 -- 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, 8 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5608) Performance problem with cascadeOnFlush

by mikhailfranco (JIRA)

Performance problem with cascadeOnFlush ---------------------------------------- Key: HHH-5608 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5608 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Environment: Hibernate 3.5.2 JPA 2.0 HSQLDB 2.0.0 and PostgreSQL 8.4 Windows XP 2002 JDK 1.6.0_11 Reporter: mikhailfranco Performance of adding entities to the database degrades as O(n^2) or worse. The problem seems to be in AbstractFlushingEventListener. The method prepareEntityFlushes() calls cascadeOnFlush() for every object in the session cache, so cascadeOnFlush ends up being called n^2 times. The cascadeOnFlush method seems to be very slow, even when there is nothing to do, i.e. no actual cascading. It appears to create a new Cascade object and do lots of work in cascade() for every invocation. Also see the description given in this thread: http://www.mail-archive.com/nhusers@googlegroups.com/msg14727.html > I think there is a problem with our mapping or something with how > we're using NHibernate. Whenever we've done performance testing we've > always noticed that NH takes up a large amount of time and usually > it's a ridiculous amount of time based on how little data should be > saved. > > I started doing some profiling to try to see what we're doing wrong > and I noticed during one test that there were 50 calls to > PrepareEntityFlushes which is an acceptable amount of calls but then I > noticed it resulted in 584,441 calls to CascadeOnFlush. > > So my question is does this number seem a bit excessive > or is this normal? Clearly this is really very excessive ! He goes on to say: > I've made another interesting discovery. The problem was actually > caused by the fact we were calling a Flush() after every SaveOrUpdate > (silly way to try to make sure we had an Id -- we're handling things > differently now). By switching to AutoFlush we were able to take > something that took an operation that took 2 hours (and spent +90% of > the time in NH code) and lower it to 4 minutes. In my case, I do not call flush(), but add lots of entities in transactions. The profiler shows 800 calls to commit, and 85,000 calls to cascadeOnFlush. There are no cascade relationships declared for the entities being persisted. Not sure what the solution could be, probably some combination of: - making cascade check more efficient, don't create objects, truncate cascade quickly if there is no work to do, etc. - limit the size of the cache, use bounded cache, maybe LRU algorithm, etc. - give some kind of diagnostic warning if a large cache is configured, with lots of cascade relationships in the ORM -- 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, 8 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HV-383) Update VCS information in pom

by Hardy Ferentschik (JIRA)

Update VCS information in pom ----------------------------- Key: HV-383 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-383 Project: Hibernate Validator Issue Type: Task Components: build Affects Versions: 4.1.0.Final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.2.0 * also remove the svn keyword specific tags from the source 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, 8 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2010