August 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6337) Add root and subclass bindings to EntityBinding

by Gail Badner (JIRA)

Add root and subclass bindings to EntityBinding ----------------------------------------------- Key: HHH-6337 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6337 Project: Hibernate Core Issue Type: Task Affects Versions: 4.0.0.Beta1 Reporter: Gail Badner Assignee: Gail Badner -- 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

12 years, 9 months

2
10
0 / 0

[Hibernate-JIRA] Created: (HHH-6498) Update entity persisters and tuplizers to use EntityBinding superclass and subclass information

by Gail Badner (JIRA)

Update entity persisters and tuplizers to use EntityBinding superclass and subclass information ----------------------------------------------------------------------------------------------- Key: HHH-6498 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6498 Project: Hibernate Core Issue Type: Task Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-770) Range facets: .below on numeric null values (AssertionFailure: Unsupported range type)

by Elmer van Chastelet (JIRA)

Range facets: .below on numeric null values (AssertionFailure: Unsupported range type) -------------------------------------------------------------------------------------- Key: HSEARCH-770 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-770 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 3.4.0.Final Environment: Using Hibernate 3.4.0 final, independent on on platform. Reporter: Elmer van Chastelet Attachments: RangeFacetNumericNullValueFail.zip An assertion failure ("Unsupported range type") is thrown, when getting facets ( facetmanager.getFacets( facetName ) ) after narrowing on a facet ( facetmanager.getFacetGroup( facetingName ).selectFacets( facet )) in the following situation: - Using a range facet with _.below_ constraint - on a _numeric field_ (i.e. has @NumericField annotation) - the field has a _null_ value for at least one indexed entity Attached is a unit test that throws this exception. My guess is that entities with null values are included in the result of the below facet, so probably null is evaluated to be 'lower' than any valid Integer. The lowest value found is probably used somewhere to set some range during .selectFacets( facetName ). This range is then used again when calling .getFacets( facetingName ), which tries to obtain the type from a null value -> AssertionFailure: Unsupported range type. RangeFacetNumericNullValueFail.zip includes a unit test (testRangeBelowWithNullValues() in org.hibernate.search.test.query.facet.RangeFacetingTest) and the modified files which are used by this test (like Truck.java) Exception trace: org.hibernate.annotations.common.AssertionFailure: Unsupported range type at org.hibernate.search.query.dsl.impl.RangeFacetImpl.createNumericRangeQuery(RangeFacetImpl.java:146) at org.hibernate.search.query.dsl.impl.RangeFacetImpl.getFacetQuery(RangeFacetImpl.java:55) at org.hibernate.search.query.engine.impl.FacetManagerImpl.createSelectionGroupQuery(FacetManagerImpl.java:160) at org.hibernate.search.query.engine.impl.FacetManagerImpl.getFacetFilter(FacetManagerImpl.java:146) at org.hibernate.search.query.engine.impl.HSQueryImpl.buildFilters(HSQueryImpl.java:650) at org.hibernate.search.query.engine.impl.HSQueryImpl.getQueryHits(HSQueryImpl.java:384) at org.hibernate.search.query.engine.impl.HSQueryImpl.queryDocumentExtractor(HSQueryImpl.java:275) at org.hibernate.search.query.engine.impl.FacetManagerImpl.getFacets(FacetManagerImpl.java:110) See also: [topic in Hibernate user forum|https://forum.hibernate.org/viewtopic.php?f=9&t=1011030] -- 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

12 years, 9 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3028) Memory consumption when query cache is enabled

by Markus Heiden (JIRA)

Memory consumption when query cache is enabled ---------------------------------------------- Key: HHH-3028 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028 Project: Hibernate3 Issue Type: Bug Components: caching (L2), core Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, Oracle 9i Reporter: Markus Heiden As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug describes a memory consumption issue which is located in ActionQueue/EntityAction. Some snippets from ActionQueue: private ArrayList executions; public void execute(Executable executable) { final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled(); if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) { executions.add( executable ); } ... } This code leads to a kind of memory leak, because if the "executable" is added to "executions", the related entity which is referenced from the "executable" is prevented from being garbage collected until the transaction ends. So if one needs to insert large amounts of transient objects in one transaction, there is no chance to get rid of the inserted objects by flushing and evicting them, if e.g. the query cache is enabled. One solution to this problem might be to rework the above "if" condition to only add objects to "executions" if this is really needed. The problem is to determine when it is really needed. Some snippets from EntityAction (which implements Executable): private final Object instance; public final Serializable getId() { if ( id instanceof DelayedPostInsertIdentifier ) { return session.getPersistenceContext().getEntry( instance ).getId(); } return id; } public final Object getInstance() { return instance; } Another solution might be to set the reference to the related entity (field "instance" in EntityAction) to null after flushing. This does not prevent "executions" from being filled, but the related entities might be garbage collected and so the memory consumption is acceptable. The problem is that subclasses of EntityAction use the "instance" field for post transaction work. The are currently two workarounds to this problems: 1) To always disable the query cache 2) To use shorter transactions Workaround 1 is not really acceptable, because it prohibits the use of a very useful feature. Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks transactional safety. -- 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

12 years, 9 months

8
12
0 / 0

[Hibernate-JIRA] Created: (HHH-6564) JBoss AS6 and earlier transaction manager jndi lookup is wrong

by Scott Marlow (JIRA)

JBoss AS6 and earlier transaction manager jndi lookup is wrong -------------------------------------------------------------- Key: HHH-6564 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6564 Project: Hibernate Core Issue Type: Bug Affects Versions: 4.0.0.Beta5 Reporter: Scott Marlow Assignee: Scott Marlow Priority: Minor Fix For: 4.0.0.next When I fixed HHH-6543 (AS7 support), I broke support for earlier releases of AS7. java:/TransactionManager is correct for earlier releases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-597) Inconsistent treatment of extended FullTextIndexEventListener

by Ben Dotte (JIRA)

Inconsistent treatment of extended FullTextIndexEventListener ------------------------------------------------------------- Key: HSEARCH-597 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-597 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.2.0.Final Environment: Hibernate 3.5.3, SQL Server 2005 Reporter: Ben Dotte Priority: Minor In my hibernate.cfg.xml file I have specified my own hibernate event listener class that extends from FullTextEventListener.java. ContextHelper nicely allows this (line 50): if ( candidate instanceof FullTextIndexEventListener ) { ... } However, with debug-level logging turned on, I see a number of log messages from EventSourceTransactionContext line 116 "FullTextIndexEventListener was not registered as FlushEventListener". This is because it looks for an exact class match: if ( listener.getClass().equals( FullTextIndexEventListener.class ) ) { ... } Could we change this to be FullTextIndexEventListener.class.isAssignableFrom(listener.getClass()) instead? I also noticed an == check for the same thing in EventListenerRegister.isPresentInListeners(). -- 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

12 years, 9 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-839) Upgrade to Infinispan 5.0.0.FINAL

by Sanne Grinovero (JIRA)

Upgrade to Infinispan 5.0.0.FINAL --------------------------------- Key: HSEARCH-839 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-839 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.Alpha1 unfortunately it seems a version upgrade is not enough. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-681) NotSerializableException when NumericField gets serialized in JMSBackendQueueProcessor

by Katrin E. (JIRA)

NotSerializableException when NumericField gets serialized in JMSBackendQueueProcessor -------------------------------------------------------------------------------------- Key: HSEARCH-681 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-681 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.3.0.Final Environment: Master-Slave-Architecture Reporter: Katrin E. We have a master-slave-architecture which delegates an index update to the master. We have NumericFields in the index to perform NumericRangeQueries. When the slave tries to inform the master via JMSBackendQueueProcessor the object including a NumericField gets serialized. A NotSerializableException occurs on a NumericTokenStream. The NumericField extends AbstractField, which implements Serializable, but it cannot be serialized because it stores the precisionStep in the underlying NumericTokenStream, which is not serializable. This might be a lucene issue, but Hibernate Search gets affected for NumericRangeQueries. There is an issue on the lucene jira as well but isn't resolved yet: https://issues.apache.org/jira/browse/LUCENE-2707 Here is a code snippet to test the serialization of a NumericField: NumericField number = new NumericField("number", 4); number.setFloatValue(42f); try { FileOutputStream fout = new FileOutputStream("number.txt"); ObjectOutputStream oos = new ObjectOutputStream(fout); oos.writeObject(number); oos.close(); } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } -- 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

12 years, 9 months

4
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-830) Make LuceneWork use Class<?> instead of the raw type

by Emmanuel Bernard (JIRA)

Make LuceneWork use Class<?> instead of the raw type ---------------------------------------------------- Key: HSEARCH-830 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-830 Project: Hibernate Search Issue Type: Improvement Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Priority: Minor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-757) Explicitly control binary format of possibly serialized elements sent to the backend

by Sanne Grinovero (JIRA)

Explicitly control binary format of possibly serialized elements sent to the backend ------------------------------------------------------------------------------------ Key: HSEARCH-757 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-757 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 4.0.0.Alpha1 Our current operations include the serialized form of an org.apache.lucene.Document, but Lucene is not providing any more guarantees that this objects are serializable; we need to specify an alternative set of objects to carry over the needed information. -- 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

12 years, 9 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2011