[Hibernate-JIRA] Created: (HHH-2933) DialectFactory dialects should be in a properties file
by Mikael Kopteff (JIRA)
DialectFactory dialects should be in a properties file
------------------------------------------------------
Key: HHH-2933
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2933
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.5
Reporter: Mikael Kopteff
Currently the DialectFactory has the static attribute MAPPERS, that hold the dialects. If the dialect is not found, Hibernate will throw an exception. There is already an TODO tag, set for this.So, could this be possibly done, so that the values really are a) in a properties file or b)additions could be made to the map programmaticaly by users.
This would be more flexible for advanced users, that work with experimental jdbc drivers(that don't return a standard name for the database).
The current trunk version of DialectFactory:
// TODO : this is the stuff it'd be nice to move to a properties file or some other easily user-editable place
private static final Map MAPPERS = new HashMap();
static {
MAPPERS.put( "HSQL Database Engine", new VersionInsensitiveMapper( "org.hibernate.dialect.HSQLDialect" ) );
MAPPERS.put( "H2", new VersionInsensitiveMapper( "org.hibernate.dialect.H2Dialect" ) );
MAPPERS.put( "MySQL", new VersionInsensitiveMapper( "org.hibernate.dialect.MySQLDialect" ) );
etc.....
--
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
17 years, 6 months
[Hibernate-JIRA] Created: (HSEARCH-232) Using SnowballPorterFilterFactory throws NoClassDefFoundError
by Hardy Ferentschik (JIRA)
Using SnowballPorterFilterFactory throws NoClassDefFoundError
-------------------------------------------------------------
Key: HSEARCH-232
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-232
Project: Hibernate Search
Issue Type: Bug
Reporter: Hardy Ferentschik
Assignee: Hardy Ferentschik
Fix For: 3.1.0.Beta2
Trying to use SnowballPorterFilterFactory in @AnalyzerDef will currently throw the following exception:
java.lang.NoClassDefFoundError: org/apache/solr/request/QueryResponseWriter
at org.apache.solr.analysis.SnowballPorterFilterFactory.init(SnowballPorterFilterFactory.java:42)
The problem is SnowballPorterFilterFactory contains a log statement using SolrCore.log.fine(). SolrCore itself has then a whole list of other import statements including QueryResponseWriter. Within Hibernate Search we use a custom/shrinked version of the solr jar which only contains the classes needed for analysis. QueryResponseWriter should of course not be required (see http://repository.jboss.org/maven2/org/hibernate/apache/lucene/solr/apach...).
The problem does not occur when the full solr jar is used.
We need to start a discussion with the solr developers regrading this logging issue.
Example annotation causing the error:
@AnalyzerDef(name="customanalyzer",
tokenizer = @TokenizerDef(factory = StandardTokenizerFactory.class),
filters = {
@TokenFilterDef(factory = LowerCaseFilterFactory.class),
@TokenFilterDef(factory = SnowballPorterFilterFactory.class,params = {
@Parameter(name="language", value= "English")
}),
})
--
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
17 years, 6 months
[Hibernate-JIRA] Created: (HHH-3310) Using Nested DetachedCriteria (Sub-Selects) throwing NullPointerException
by Roshan Dawrani (JIRA)
Using Nested DetachedCriteria (Sub-Selects) throwing NullPointerException
-------------------------------------------------------------------------
Key: HHH-3310
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3310
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 10g
Reporter: Roshan Dawrani
Attachments: Nested_Subselects.zip
Hi,
We have come across an issue with the usage of nested subselects in the sql query with hibernate 3.2.5.
We get the following exception when there is more than one level of sub-selects in the query :
----------------------------------------------------------------------------------------------------------------------
java.lang.NullPointerException
at org.hibernate.criterion.SubqueryExpression.getTypedValues(SubqueryExpression.java:80)
at org.hibernate.loader.criteria.CriteriaQueryTranslator.getQueryParameters(CriteriaQueryTranslator.java:251)
at org.hibernate.criterion.SubqueryExpression.toSqlString(SubqueryExpression.java:55)
at org.hibernate.loader.criteria.CriteriaQueryTranslator.getWhereCondition(CriteriaQueryTranslator.java:334)
at org.hibernate.loader.criteria.CriteriaJoinWalker.<init>(CriteriaJoinWalker.java:71)
at org.hibernate.loader.criteria.CriteriaLoader.<init>(CriteriaLoader.java:67)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1550)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)
at NestedDetachedCriteriaTest.testNestedDetachedCriteria(Unknown Source)
----------------------------------------------------------------------------------------------------------------------
The actual query that gets fired is like:
----------------------------------------------------------------------------------------------------------------------
select this_.name as y0_ from cat this_ where this_.name =
(select this0__.name as y0_ from cat this0__ where this0__.parent_id =
(select this0__.parent_id as y0_ from cat this0__ where this0__.name =
(select this0__.name as y0_ from cat this0__ where this0__.cat_id = ?)))
----------------------------------------------------------------------------------------------------------------------
We investigated the issue and have fixed it by making some changes in org.hibernate.criterion.SubqueryExpression class.
The attached file has the following contents:
1. SubqueryExpression.java - Fix we have made to SubqueryExpression class.
2. NestedDetachedCriteriaTest.zip - A test case to highlight the nested sub-select issue (testNestedDetachedCriteria).
Regards,
Roshan
--
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
17 years, 6 months
[Hibernate-JIRA] Created: (HSEARCH-219) Manual indexing strategy not implemented
by Fol De Rol (JIRA)
Manual indexing strategy not implemented
----------------------------------------
Key: HSEARCH-219
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-219
Project: Hibernate Search
Issue Type: Bug
Components: engine
Affects Versions: 3.0.1.GA
Reporter: Fol De Rol
Priority: Blocker
It looks impossible to implement fully manual strategy of indexing because of mandating event listeners to be registered.
See org.hibernate.search.util.ContextHelper.java:25:
//FIXME this sucks since we mandante the event listener use
This causes a side effect to my application that stores an indication that the certain object is indexed in a child collection. So, when I complete manual indexing of an object, I add an element to this collection (actually, the cluster node identifier). This causes the Hibernate Search event listener to be triggered because the dependent collection has been modified which in its turn adds one more indexing job. Finally, I get an endless recursion.
--
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
17 years, 6 months
[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
17 years, 6 months
[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
17 years, 6 months