August 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6594) Interceptor.onPrepareStatement no longer being called

by John Verhaeg (JIRA)

Interceptor.onPrepareStatement no longer being called ----------------------------------------------------- Key: HHH-6594 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6594 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.CR1 Reporter: John Verhaeg Fix For: 4.0.0.next It looks like this processing has been rewritten in 4.0 and the interceptor call got left out -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-874) Javadocs of IndexShardingStrategy are incorrect

by Hardy Ferentschik (JIRA)

Javadocs of IndexShardingStrategy are incorrect ----------------------------------------------- Key: HSEARCH-874 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-874 Project: Hibernate Search Issue Type: Bug Components: documentation Affects Versions: 4.0.0.Alpha1 Reporter: Hardy Ferentschik Fix For: 4.0.0.Alpha2 See _getIndexManagersForDeletion_ and _getIndexManagersForQuery_ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-878) Remove option to change the number of backend threads when starting a MassIndexer

by Sanne Grinovero (JIRA)

Remove option to change the number of backend threads when starting a MassIndexer --------------------------------------------------------------------------------- Key: HSEARCH-878 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-878 Project: Hibernate Search Issue Type: Remove Feature Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.Alpha2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-877) Remove option to override the BatchBackend to customize MassIndexer

by Sanne Grinovero (JIRA)

Remove option to override the BatchBackend to customize MassIndexer ------------------------------------------------------------------- Key: HSEARCH-877 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-877 Project: Hibernate Search Issue Type: Remove Feature Components: massindexer Reporter: Sanne Grinovero Fix For: 4.0.0.Alpha2 The backend used by the MassIndexer is now not different than the standard backend; there still is a BatchBackend concept, but this is currently just a forwarding component sending work to the real backend. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-875) Bad variable names in HSQueryImpl

by Hardy Ferentschik (JIRA)

Bad variable names in HSQueryImpl --------------------------------- Key: HSEARCH-875 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-875 Project: Hibernate Search Issue Type: Improvement Affects Versions: 4.0.0.Alpha1 Reporter: Hardy Ferentschik Priority: Trivial Fix For: 4.0.0.Alpha2 variables of type _IndexManager_ are called _directoryProviders_, eg line 576 Some remains of the latest refactoring around DirectoryProviders vs IndexManagers -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-836) Evaluate the need to send the writing schema over with the message

by Emmanuel Bernard (JIRA)

Evaluate the need to send the writing schema over with the message ------------------------------------------------------------------ Key: HSEARCH-836 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-836 Project: Hibernate Search Issue Type: Bug Components: serialization Affects Versions: 4.0 Reporter: Emmanuel Bernard Avro knows to read a message serialized by a different writer assuming certain conditions described in their spec http://avro.apache.org/docs/1.5.1/spec.html But both reader and writer schema should be provided up deserialization GenericDatumReader(Schema writer, Schema reader, GenericData data) Should we embed the schema with each message? It looks like a significant payload. If we don't, we can use the major.minor version numbers that are before the avro stream. But that will only work if the receiver is more recent that the writer. In all case, we need a prototype to test backward compatibility. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6612) org.hibernate.session.isDirty() flushes new rows in a Collection which has items mapped with id generator "identity"

by Emre BAKKAL (JIRA)

org.hibernate.session.isDirty() flushes new rows in a Collection which has items mapped with id generator "identity" -------------------------------------------------------------------------------------------------------------------- Key: HHH-6612 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6612 Project: Hibernate Core Issue Type: Bug Components: annotations, core Affects Versions: 3.0 final Environment: Hibernate 3.0, MySql 5.5.11, JBoss 5.1, JBoss Seam 2.2.1 Reporter: Emre BAKKAL Priority: Critical If we call org.hibernate.session.isDirty() after we added a new row to a mapped collection in a managed Entity, dirty check forces an id assign and executes an insert. I see that this behavior is caused by my collection items having id generator(annotated by javax.persistence.Id and javax.persistence.GeneratedValue(strategy = javax.persistence.GenerationType.IDENTITY)) and mapped with cascade type "all"(javax.persistence.CascadeType.ALL), but still it's an unexpected behavior. Shouldn't it return true when it found a new row? I couldn't find a workaround for this behavior. I wanted to give user a choice to save the changes or not, if there are changes which have been made. Setting org.hibernate.FlushMode to "NEVER" does not help either. This behavior prevents using this method for change tracking, and is not compatible with the description of the method.. Best Regards.. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6597) org.hibernate.session.isDirty() flushes new rows in a Collection which has items mapped with id generator "identity"

by Emre BAKKAL (JIRA)

org.hibernate.session.isDirty() flushes new rows in a Collection which has items mapped with id generator "identity" -------------------------------------------------------------------------------------------------------------------- Key: HHH-6597 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6597 Project: Hibernate Core Issue Type: Bug Components: annotations, core Affects Versions: 3.0 final Environment: JBoss 5.1, JBoss Seam 2.2.1, Hibernate 3.0, MySql 5.5.11 Reporter: Emre BAKKAL If we call org.hibernate.session.isDirty() after we add a new row to a mapped collection in a managed Entity, dirty check forces an id assign and executes an insert. I see that this behavior is caused because of my collection items having id generator and mapped with cascade type all, but still it's an unexpected behavior. Shouldn't it return true when it found a new row? I couldn't find a workaround for this behavior. I wanted to give user a choice to save the changes or not, if there are changes which have been made. Setting FlushMode to NEVER does not help either. This behavior prevents using this method for change tracking, and is not compatible with the description of the method.. Best Regards.. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6610) Support for EHCache 2.0's Write-Behind

by Deejay (JIRA)

Support for EHCache 2.0's Write-Behind -------------------------------------- Key: HHH-6610 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6610 Project: Hibernate Core Issue Type: New Feature Components: caching (L2) Reporter: Deejay I'd like to be able to use Hibernate with a second-level write-behind cache. In particular it would be most useful to use EHCache 2, and distribute it using Terracotta. This would enable writes to be made in a throttled way, reducing the risk of sudden spikes of activity. I gather that EHCache supports this usage pattern, but Hibernate's use of EHCache does not. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5894) [ENVERS] Loading collections from envers entity fails due to QueryException

by Sven Rienstra (JIRA)

[ENVERS] Loading collections from envers entity fails due to QueryException --------------------------------------------------------------------------- Key: HHH-5894 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5894 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.1 Environment: Hibernate 3.6.1 Oracle 10g Ubuntu Reporter: Sven Rienstra Priority: Blocker When I'm trying to load a collection from an envers entity it fails due to an incorrect HQL query: Caused by: org.hibernate.QueryException: could not resolve property: domein_id of: nl.protopics.zwip.model.gvo.Faq_AUD [select e from nl.protopics.zwip.model.gvo.Faq_AUD e where e.domein_id = :domein_id and e.originalId.REV.id = (select max(e2.originalId.REV.id) from nl.protopics.zwip.model.gvo.Faq_AUD e2 where e2.originalId.REV.id <= :revision and e.originalId.id = e2.originalId.id) and REVTYPE != :delrevisiontype] at org.hibernate.persister.entity.AbstractPropertyMapping.propertyException(AbstractPropertyMapping.java:81) at org.hibernate.persister.entity.AbstractPropertyMapping.toType(AbstractPropertyMapping.java:75) at org.hibernate.persister.entity.AbstractEntityPersister.toType(AbstractEntityPersister.java:1465) at org.hibernate.hql.ast.tree.FromElementType.getPropertyType(FromElementType.java:315) at org.hibernate.hql.ast.tree.FromElement.getPropertyType(FromElement.java:487) at org.hibernate.hql.ast.tree.DotNode.getDataType(DotNode.java:611) at org.hibernate.hql.ast.tree.DotNode.prepareLhs(DotNode.java:263) at org.hibernate.hql.ast.tree.DotNode.resolve(DotNode.java:210) at org.hibernate.hql.ast.tree.FromReferenceNode.resolve(FromReferenceNode.java:117) at org.hibernate.hql.ast.tree.FromReferenceNode.resolve(FromReferenceNode.java:113) at org.hibernate.hql.ast.HqlSqlWalker.resolve(HqlSqlWalker.java:880) at org.hibernate.hql.antlr.HqlSqlBaseWalker.expr(HqlSqlBaseWalker.java:1330) at org.hibernate.hql.antlr.HqlSqlBaseWalker.exprOrSubquery(HqlSqlBaseWalker.java:4471) at org.hibernate.hql.antlr.HqlSqlBaseWalker.comparisonExpr(HqlSqlBaseWalker.java:3944) at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:2047) at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1972) at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1972) at org.hibernate.hql.antlr.HqlSqlBaseWalker.whereClause(HqlSqlBaseWalker.java:831) at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:617) at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:301) at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:244) at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:254) at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:185) at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:101) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80) at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:124) at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156) at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135) at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1770) at org.hibernate.envers.entities.mapper.relation.query.OneAuditEntityQueryGenerator.getQuery(OneAuditEntityQueryGenerator.java:99) at org.hibernate.envers.entities.mapper.relation.lazy.initializor.AbstractCollectionInitializor.initialize(AbstractCollectionInitializor.java:62) at org.hibernate.envers.entities.mapper.relation.lazy.proxy.CollectionProxy.checkInit(CollectionProxy.java:50) at org.hibernate.envers.entities.mapper.relation.lazy.proxy.CollectionProxy.iterator(CollectionProxy.java:70) mappings: Domein class, from where I call getFaqs() @OneToMany(cascade = CascadeType.ALL, mappedBy = "domein") private List<Faq> faqs = new ArrayList<Faq>(); Faq mapping: @ManyToOne private Domein domein; Works fine with 3.6.0. -- 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, 7 months

4
12
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 August 2011