October 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HHH-1626) nullpointer on hql query using objects with many-to-one assosiation which contains formula columns

by Jens Bornemann (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1626?page=c... ] Jens Bornemann commented on HHH-1626: ------------------------------------- Ran into the same problem and fixed it today... (see this patch)... Index: project/core/src/main/java/org/hibernate/persister/entity/AbstractPropertyMapping.java =================================================================== RCS file: /project/core/src/main/java/org/hibernate/persister/entity/AbstractPropertyMapping.java,v retrieving revision 1.1 diff -u -r1.1 AbstractPropertyMapping.java --- project/core/src/main/java/org/hibernate/persister/entity/AbstractPropertyMapping.java 10 Oct 2008 16:56:57 -0000 1.1 +++ project/core/src/main/java/org/hibernate/persister/entity/AbstractPropertyMapping.java 10 Oct 2008 16:59:04 -0000 @@ -178,7 +178,7 @@ } } else if ( type.isEntityType() ) { - initIdentifierPropertyPaths( path, (EntityType) type, columns, factory ); + initIdentifierPropertyPaths( path, (EntityType) type, columns, formulaTemplates, factory ); } } @@ -186,6 +186,7 @@ final String path, final EntityType etype, final String[] columns, + final String[] formulaTemplates, final Mapping factory) throws MappingException { Type idtype = etype.getIdentifierOrUniqueKeyType( factory ); @@ -195,15 +196,15 @@ if ( etype.isReferenceToPrimaryKey() ) { if ( !hasNonIdentifierPropertyNamedId ) { String idpath1 = extendPath(path, EntityPersister.ENTITY_ID); - addPropertyPath(idpath1, idtype, columns, null); - initPropertyPaths(idpath1, idtype, columns, null, factory); + addPropertyPath(idpath1, idtype, columns, formulaTemplates); + initPropertyPaths(idpath1, idtype, columns, formulaTemplates, factory); } } if (idPropName!=null) { String idpath2 = extendPath(path, idPropName); - addPropertyPath(idpath2, idtype, columns, null); - initPropertyPaths(idpath2, idtype, columns, null, factory); + addPropertyPath(idpath2, idtype, columns, formulaTemplates); + initPropertyPaths(idpath2, idtype, columns, formulaTemplates, factory); } } > nullpointer on hql query using objects with many-to-one assosiation which contains formula columns > -------------------------------------------------------------------------------------------------- > > Key: HHH-1626 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1626 > Project: Hibernate Core > Issue Type: Bug > Components: core, query-hql > Affects Versions: 3.1.3 > Environment: hibernate 3.1.3 > mysql 4.x > Reporter: axel becker > Priority: Critical > Attachments: OrgResource.hbm.xml > > > -using the attached mapping > -executing this query: "from OrgResource as o where o.orgCategory.comp_id.companyId= :companyId and o.orgCategory.comp_id.categoryId= :categoryId " > results this exception: > java.lang.NullPointerException > at org.hibernate.persister.entity.AbstractPropertyMapping.toColumns(AbstractPropertyMapping.java:68) > at org.hibernate.persister.entity.BasicEntityPropertyMapping.toColumns(BasicEntityPropertyMapping.java:31) > at org.hibernate.persister.entity.AbstractEntityPersister.toColumns(AbstractEntityPersister.java:1257) > at org.hibernate.hql.ast.tree.FromElementType.toColumns(FromElementType.java:317) > at org.hibernate.hql.ast.tree.FromElementType.toColumns(FromElementType.java:290) > at org.hibernate.hql.ast.tree.FromElement.toColumns(FromElement.java:376) > at org.hibernate.hql.ast.tree.DotNode.getColumns(DotNode.java:97) > at org.hibernate.hql.ast.tree.DotNode.initText(DotNode.java:210) > at org.hibernate.hql.ast.tree.DotNode.resolve(DotNode.java:204) > at org.hibernate.hql.ast.tree.FromReferenceNode.resolve(FromReferenceNode.java:94) > at org.hibernate.hql.ast.tree.FromReferenceNode.resolve(FromReferenceNode.java:90) > at org.hibernate.hql.ast.HqlSqlWalker.resolve(HqlSqlWalker.java:725) > at org.hibernate.hql.antlr.HqlSqlBaseWalker.expr(HqlSqlBaseWalker.java:1215) > at org.hibernate.hql.antlr.HqlSqlBaseWalker.exprOrSubquery(HqlSqlBaseWalker.java:4032) > at org.hibernate.hql.antlr.HqlSqlBaseWalker.comparisonExpr(HqlSqlBaseWalker.java:3518) > at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1758) > at org.hibernate.hql.antlr.HqlSqlBaseWalker.logicalExpr(HqlSqlBaseWalker.java:1683) > at org.hibernate.hql.antlr.HqlSqlBaseWalker.whereClause(HqlSqlBaseWalker.java:776) > at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:577) > at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:281) > at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:229) > at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:218) > at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:158) > at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:109) > at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:75) > at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:54) > at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71) > at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:133) > at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:112) > at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1583) > i debugged the toColumns Mehtod and found the reason for the nullpointer. the formulaTemplatesByPropertyPath map doesnt contains an entry for "orgCategory.comp_id.companyId" which is the, as formula, mapped column. > in my opinion the bug is in the initPropertyPaths method. the "if ( type.isAssociationType() ) {" section never checks for formular columns -- 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

16 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-3521) rss feed for www.hibernate.org page

by Amir Pashazadeh (JIRA)

rss feed for www.hibernate.org page ----------------------------------- Key: HHH-3521 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3521 Project: Hibernate Core Issue Type: New Feature Reporter: Amir Pashazadeh I know it is not an hibernate libraries issue, but could not find a better place. I believe it would be nice to have an RSS feed on first page of hibernate site (www.hibernate.org) about the topics and news on the first page. -- 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

16 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-511) reattach object from same session

by Alex Pires de Camargo (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-511?page=co... ] Alex Pires de Camargo commented on HHH-511: ------------------------------------------- This fix generated a problem on session.clear() performance, as posted on the forum: http://forum.hibernate.org/viewtopic.php?t=990508 I've tested Rodrigo Castro patch with good results. > reattach object from same session > --------------------------------- > > Key: HHH-511 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-511 > Project: Hibernate Core > Issue Type: Bug > Components: core > Reporter: Gavin King > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.4 > > Attachments: reattach-same-session.patch, reattach-same-session.patch > > > http://forum.hibernate.org/viewtopic.php?p=2231400#2231400 > There is a problem when you reattach a collection to the same session that it was previously attached to, after calling clear(). Hibernate checks the collections session reference, at reattach and concludes it is already attached. -- 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

16 years, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-238) DirectoryProviderFactory configuration problem

by Rafal Glowacz (JIRA)

DirectoryProviderFactory configuration problem ---------------------------------------------- Key: HSEARCH-238 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-238 Project: Hibernate Search Issue Type: Bug Reporter: Rafal Glowacz Because IdHashShardingStrategy fails after 1.7m ID is reached I decided to use my own version of strategy. I set up property common.hibernate.search.blogentry.sharding_strategy = com. ... .IdShardingStrategy and didn't work for me. As I checked problem exist in DirectoryProviderFactory and the way how properties are created ( new Properties( defaultProperties ) ). This constructor and the way how default properties are stored in this Object this both together doesn't work well. Problem exist: //define sharding strategy IndexShardingStrategy shardingStrategy; Properties shardingProperties = new Properties(); for (Map.Entry entry : indexProps[0].entrySet()) { if ( ( (String) entry.getKey() ).startsWith( SHARDING_STRATEGY ) ) { shardingProperties.put( entry.getKey(), entry.getValue() ); } } String shardingStrategyName = shardingProperties.getProperty( SHARDING_STRATEGY ); if ( shardingStrategyName == null) { if ( indexProps.length == 1 ) { shardingStrategy = new NotShardedStrategy(); } else { shardingStrategy = new IdHashShardingStrategy(); } } else { in this loop "for (Map.Entry entry : indexProps[0].entrySet()) {" this set is just empty so custom properties for sharding have been ignored. Workaround: Instead using new Properties(defaultProps) I'm using method: private static Properties createProperties(Properties indexSpecificDefaultProps) { Properties properties = new Properties(); properties.putAll(indexSpecificDefaultProps); return properties; } -- 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

16 years, 3 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-176) explicitly setting cfg property to lucene default

by Sanne Grinovero (JIRA)

explicitly setting cfg property to lucene default ------------------------------------------------- Key: HSEARCH-176 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-176 Project: Hibernate Search Issue Type: Improvement Components: directory provider, documentation Reporter: Sanne Grinovero Priority: Trivial As highlighted by previous patch for http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-153 , some configuration settings may be inherited, so it becomes difficult to explicitly set "default" settings on some settings as some values are "Integer.MAX_VALUE" or "null" but the cfg parser only accepts int values. Also if the users wants to explicitly set lucene defaults it needs to study the current lucene source code. I'm going to provide a patch to support besides current int values also "default" and "null" Strings, to explicitly configure H.Search to: "default" -> don't mess with the value "null" -> explicitly null the value Also someone may find it useful to represent "MAX_VALUE", what do you think about that, or other configurations that should be recognized? -- 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

16 years, 3 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-239) Search default properties are ignored when at least one shard property exist

by Rafal Glowacz (JIRA)

Search default properties are ignored when at least one shard property exist ---------------------------------------------------------------------------- Key: HSEARCH-239 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-239 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.0.0.GA Reporter: Rafal Glowacz I'm trying to use shared strategy for search. So my basic setup was: common.hibernate.search.default.indexBase = /lucene/index common.hibernate.search.default.optimizer.operation_limit.max = 1000 common.hibernate.search.default.optimizer.transaction_limit.max = 1000 common.hibernate.search.default.directory_provider = org.hibernate.search.store.FSDirectoryProvider common.hibernate.search.default.sharding_strategy = com.newbay.search.sharding.strategy.IdShardingStrategy common.hibernate.search.blogentry.sharding_strategy.nbr_of_shards = 5 But this won't work for me because when sharding configuration properties exist then those default ones are completely ignored - I can't understand that. To change this I changed ".default." to ".blogentry." and then I found the bug that the number of properties decides how many shards I want for current index. (nbrOfShards = nbrOfShards >= indexSpecificDefaultProps.size() ? nbrOfShards : indexSpecificDefaultProps.size();) So in this case I can't do anything. I'm looking for such config: common.hibernate.search.default.indexBase = /lucene/index common.hibernate.search.default.optimizer.operation_limit.max = 1000 common.hibernate.search.default.optimizer.transaction_limit.max = 1000 common.hibernate.search.default.directory_provider = org.hibernate.search.store.FSDirectoryProvider common.hibernate.search.default.sharding_strategy = com.newbay.search.sharding.strategy.IdShardingStrategy common.hibernate.search.website.sharding_strategy.nbr_of_shards = 2 common.hibernate.search.website.indexBase = /lucene/website common.hibernate.search.blogentry.sharding_strategy.nbr_of_shards = 5 common.hibernate.search.blogentry.indexBase = /lucene/blogentry But it doesn't work for now. My solution for this is to build properties in order: default, indexProps, shardProps //sharded nbrOfShards = nbrOfShards >= indexSpecificDefaultProps.size() ? nbrOfShards : indexSpecificDefaultProps.size(); ensureListSize(indexSpecificProps, nbrOfShards); for (int index = 0; index < nbrOfShards; index++) { Properties properties = new Properties(); properties.putAll(defaultProperties); properties.putAll(indexSpecificDefaultProps); if (indexSpecificProps.get(index) != null) { properties.putAll(indexSpecificProps.get(index)); } indexSpecificProps.set(index, properties); } return indexSpecificProps.toArray(new Properties[indexSpecificProps.size()]); -- 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

16 years, 3 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-263) Wrong analyzers used in IndexWriter

by Sanne Grinovero (JIRA)

Wrong analyzers used in IndexWriter ----------------------------------- Key: HSEARCH-263 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-263 Project: Hibernate Search Issue Type: Bug Components: analyzer Affects Versions: 3.1.0.Beta1 Reporter: Sanne Grinovero Priority: Critical when an IndexWriter is first opened during a transaction commit it is assigned the analyzer connected to the first entity written, if during the same transaction other entities are saved to the same index it will reuse the first one ( instead of the entity specified one). I have a testcase showing the problem ready for commit but need your opinion about how to solve it. I think the problem is that we register a ScopedAnalyzer for each DocumentBuilder, but there should be one per DirectoryProvider? In this case we should check at startup that no entities sharing an index define conflicting Analyzer rules. Another solution would be to let complete flexibility during analyzer definition, but reopen the IndexWriter when the entityType is different from the last one indexed. -- 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

16 years, 3 months

2
5
0 / 0

[Hibernate-JIRA] Created: (EJB-394) Apply similar patch provided in EJB-393 for branch v3_2_1_GA_CP

by Juraci Paixao Krohling (JIRA)

Apply similar patch provided in EJB-393 for branch v3_2_1_GA_CP --------------------------------------------------------------- Key: EJB-394 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-394 Project: Hibernate Entity Manager Issue Type: Patch Reporter: Juraci Paixao Krohling Attachments: ChangedEntityManagerSource_Branch_v3_2_1_GA_CP.diff Apply the same changes from EJB-393 in the branch v3_2_1_GA_CP . -- 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

16 years, 3 months

1
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-272) Improve contention on DirectoryProviders in lucene backend

by Sanne Grinovero (JIRA)

Improve contention on DirectoryProviders in lucene backend ---------------------------------------------------------- Key: HSEARCH-272 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-272 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.1.0.Beta1 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.1.0.Beta2 Currently the lucene backend doesn't acquire locks on DirectoryProvider(s) until needed, but releases them only at end of all work. So having a workqueue affecting DP A and B in this order: ABBB will have this locking: lockA, doA, lockB, doB,doB,doB, unlockA, unlockB. instead, this would be desirable: lockA, doA, unlockA, lockB, doB,doB,doB, unlockB Side-effect is that something like ABAB will be reordered to AABB (keeping correct order from a DP point of view). -- 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

16 years, 3 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-271) wrong Similarity used when sharing index among entities

by Sanne Grinovero (JIRA)

wrong Similarity used when sharing index among entities ------------------------------------------------------- Key: HSEARCH-271 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-271 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.0.Beta1 Reporter: Sanne Grinovero When the same IndexWriter is used during a transaction commit for two or more entities (sharing the same index) but having different Similarities, the Similarity used is the one from the first entity to be indexed. No warning is logged and it's hard to recognize without being a paranoid Similarity expert... If the two Entities share an object hierarchy, then Search correctly throws an exception during startup. Should we throw an exception also on index sharing or solve it to support different Similarities even on different obejcts being part of same tree? (to be consistent) -- 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

16 years, 3 months

1
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2008