September 2010 - hibernate-issues

[Hibernate-JIRA] Created: (HHH-2835) Setting org.hibernate.type logging to debug produces no logging

by Jeremy Grodberg (JIRA)

Setting org.hibernate.type logging to debug produces no logging --------------------------------------------------------------- Key: HHH-2835 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2835 Project: Hibernate3 Issue Type: Bug Components: core, documentation Affects Versions: 3.2.5, 3.2.4 Environment: Hibernate 3.2.4.ga and Hibernate 3.2.5.ga with MySQL5Dialect (configured with Hibernate Annotations 3.3.0.ga and Spring 2.0.6) Reporter: Jeremy Grodberg Priority: Minor According to the online documentation (labeled as version 3.2.2 at this moment), Table 3.9 "Hibernate Log Categories", as viewed here today: http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configurat... Setting the log4j category "org.hibernate.type" to debug should "Log all JDBC parameters". However, it produces no output at all. When I go on to set "org.hibernate" to debug, I get output like this: DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0) DEBUG: org.hibernate.SQL - select count(*) from album where genreID=? DEBUG: org.hibernate.loader.Loader - bindNamedParameters() 126 -> genreId [1] DEBUG: org.hibernate.jdbc.AbstractBatcher - about to open ResultSet (open ResultSets: 0, globally: 0) DEBUG: org.hibernate.loader.Loader - result row: DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close ResultSet (open ResultSets: 1, globally: 1) DEBUG: org.hibernate.jdbc.AbstractBatcher - about to close PreparedStatement (open PreparedStatements: 1, globally: 1) Note that the JDBC parameters are logged under org.hibernate.loader but nothing appears under org.hibernate.type. FYI, genreId is, in this case, a Long. Perhaps this is expected/desired when using annotations? If so, then please update the documentation. If not, please restore the logging. -- 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, 6 months

10
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2228) ant eg fails - bad release notes quick start

by Brian Brooks (JIRA)

ant eg fails - bad release notes quick start -------------------------------------------- Key: HHH-2228 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2228 Project: Hibernate3 Type: Bug Components: documentation Versions: 3.2.0.ga Environment: hibernate 3.2.0.ga Microsoft Windows XP [Version 5.1.2600] java version "1.5.0_07" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_07-b03) Java HotSpot(TM) Client VM (build 1.5.0_07-b03, mixed mode) Reporter: Brian Brooks Priority: Minor The hibernate 3.2.0.ga release notes http://sourceforge.net/project/shownotes.php?release_id=455849&group_id=4... read as Get Up And Running Quick ------------------------ Demo: (1) copy your JDBC driver to the lib directory (2) edit etc/hibernate.properties (3) run "ant eg" or "build eg" (4) browse the sourcecode in eg/org/hibernate/auction This directions are incorrect. Below is the ant output if these steps are followed. Also, I had to put junit*.jar and antlr*all*.jar in my ANT_HOME/lib before ant eg would work. C:\hibernate-3.2>ant eg Buildfile: build.xml [taskdef] Could not load definitions from resource clovertasks. It could not b e found. eg: [javac] Compiling 8 source files to C:\hibernate-3.2\build\eg [javac] C:\hibernate-3.2\eg\org\hibernate\auction\Main.java:10: cannot find symbol [javac] symbol : class FetchMode [javac] location: package org.hibernate [javac] import org.hibernate.FetchMode; [javac] ^ [javac] C:\hibernate-3.2\eg\org\hibernate\auction\Main.java:11: cannot find symbol [javac] symbol : class FlushMode [javac] location: package org.hibernate [javac] import org.hibernate.FlushMode; [javac] ^ [javac] C:\hibernate-3.2\eg\org\hibernate\auction\Main.java:12: cannot find symbol [javac] symbol : class LockMode [javac] location: package org.hibernate [javac] import org.hibernate.LockMode; [javac] ^ .... -- 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, 6 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-572) a plea to reconsider deprecating luceneOptions.getStore(), luceneOptions.getIndex() etc

by Jason Eacott (JIRA)

a plea to reconsider deprecating luceneOptions.getStore(), luceneOptions.getIndex() etc --------------------------------------------------------------------------------------- Key: HSEARCH-572 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-572 Project: Hibernate Search Issue Type: Deprecation Reporter: Jason Eacott Maybe I'm missing something, but for a fieldBridge I've noticed that it is now recommended to use luceneOptions.addFieldToDocument in place of document.add(new Field... This decision seems a bit overzealous and optimistic to me, especially given the current and significant lag in lucene version vs supported HibernateSearch version. for example - if luceneOptions.getStore(), luceneOptions.getIndex() etc are not deprecated then I can easily use them to create a custom field bridge for field types unknown to hibernateSearch. While these methods remain it is very easy to create a dynamic MapBridge for example that can choose to index a Map's key value pairs as Text or NumericFields as appropriate (Since HSearch currently has no support for NumericFields this is very useful). Without these methods, the options are much more limited. So I'd just like to ask that either these methods remain, or an alternate arrangement be made available whereby any lucene field type can be added to a document with suitable index, store, boost, termvector etc. Cheers. -- 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, 6 months

3
13
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-546) ProjectionLoader ignores FetchMode.JOIN set via a Criteria

by Hardy Ferentschik (JIRA)

ProjectionLoader ignores FetchMode.JOIN set via a Criteria ---------------------------------------------------------- Key: HSEARCH-546 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-546 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.2.0.Final Reporter: Hardy Ferentschik Fix For: 3.3.0 Hibernate Search allows you to optimize the fetching strategy for association by setting an optional {{Criteria}}: {code} Criteria fetchingStrategy = fullTextSession.createCriteria(Foo.class); fetchingStrategy.setFetchMode("foos", FetchMode.JOIN); fullTextQuery.setCriteriaQuery(fetchingStrategy); {code} This works fine for normal queries, however, in the case of projection queries and the use of {{FullTextQuery.THIS}} the fetch mode gets ignored. This is due to the fact that the {{ProjectionLoader}} internally uses {{MultiClassesQueryLoader}} in case {{FullTextQuery.THIS}} is projected. The logic from {{FullTextQueryImpl}} deciding which entity loader to use should really also be used within {{ProjectionLoader}}. See also {{FullTextQueryImpl.getLoader}} -- 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, 6 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-545) Unable to project FullTextQuery.SCORE when using a custom Sort

by Hardy Ferentschik (JIRA)

Unable to project FullTextQuery.SCORE when using a custom Sort -------------------------------------------------------------- Key: HSEARCH-545 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-545 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.2.0.Final Reporter: Hardy Ferentschik Fix For: 3.3.0 Due to [changes in Lucene|http://lucene.apache.org/java/2_9_0/changes/Changes.html#2.9.0.cha...] regarding the calculation of the score projections of {{FullTextQuery.SCORE}} return NaN when a custom sort is used. IndexSearcher javadoc: {quote} By default, no scores are computed when sorting by field (using Searcher.search(Query,Filter,int,Sort)). You can change that, per IndexSearcher instance, by calling IndexSearcher.setDefaultFieldSortScoring {quote} See also [Search forum thread|https://forum.hibernate.org/viewtopic.php?f=9&t=1005262] Without custom sort projecting on {{FullTextQuery.SCORE}} works as {{ProjectionQueryTest}} shows. -- 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, 6 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3778) Select expression results in more than one column having same name when using connected to Sybase

by vijay gudimella (JIRA)

Select expression results in more than one column having same name when using connected to Sybase -------------------------------------------------------------------------------------------------- Key: HHH-3778 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3778 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1 Environment: Windows XP, Jboss 4.2 GA, JPA Reporter: vijay gudimella The bug described in HB-705 is still a problem. The application runs fine with MySQL and JavaDb but throws the error "Select expression results in more than one column having same name " with Sybase. HB-705 is marked as "Incomplete" , and status as closed, will there be a "fix" or it is considered "fixed" -- 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, 6 months

4
6
0 / 0

[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

15 years, 6 months

3
7
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

15 years, 6 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

15 years, 6 months

2
4
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

15 years, 6 months

3
5
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 September 2010