[Hibernate-JIRA] Created: (HHH-6043) PostLoad method invoked before collection initialised
by Setanta Mathews (JIRA)
PostLoad method invoked before collection initialised
-----------------------------------------------------
Key: HHH-6043
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6043
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 3.6.2
Environment: Windows 7 64-bit, hibernate 3.6.2 final, sun java 1.6 64 bit
Reporter: Setanta Mathews
Attachments: bugTestCase.rar
Hi,
I had been monitoring this bug under Jboss's https://issues.jboss.org/browse/JBAS-5474 . However the issue was recently closed.
The description for that bug was
{quote}
I have a bean with a @OneToMany relation mapping like
private List<TherapieeinheitBean> therapieeinheiten;
@OneToMany(
cascade = {CascadeType.REFRESH},
fetch = FetchType.EAGER,
mappedBy="therapiekatalog"
)
with FetchType.EAGER and a simnple @PostLoad like
@PostLoad
public void postLoad() { System.out.println("!!!!!!!!!! postLoad !!!!!!!!!!"); System.out.print("size: " + therapieeinheiten.size()); }
When an entity of this bean is loaded JBoss trows
org.hibernate.LazyInitializationException: illegal access to loading collection
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:341)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentBag.iterator(PersistentBag.java:249)
at de.visiodesk.therapiekatalog.TherapiekatalogBean.postLoad(TherapiekatalogBean.java:170)
.
.
.
and prints the messages
WARN [LoadContexts] fail-safe cleanup (collections) : org.hibernate.engine.loading.CollectionLoadContext@2c8ce9<rs=Ingres-ResultSet[18523]>
WARN [CollectionLoadContext] On CollectionLoadContext#cleanup, localLoadingCollectionKeys contained [206] entries
afterwards. The PostLoad method should be called after the data was completely loaded. Is there a workaround for this Problem? I found some other ressources on the net where peole had the same problem, but I saw no resolution, no hint, no workaround.
{quote}
I can confirm that this issue still exists for the Hibernate 3.6.2 release.
The attached bugTestCase.rar contains a modified version of the test that was originally attached to the JBoss bug. I've changed it to work with spring and JPA.
Note that the attached test passes as the test is annotated with @Test(expected=PersistenceException.class)
The stack trace from the exception thrown is
{code}
javax.persistence.PersistenceException: org.hibernate.LazyInitializationException: failed to lazily initialize a collection, no session or session was closed
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1214)
at org.hibernate.ejb.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:635)
at org.hibernate.ejb.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:589)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:240)
at $Proxy18.find(Unknown Source)
at org.hibernate.bugs.lazyinitexception.LazyInitBug.testAccessAssociatedSetInPostLoad(LazyInitBug.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.springframework.test.context.junit4.statements.RunBeforeTestMethodCallbacks.evaluate(RunBeforeTestMethodCallbacks.java:74)
at org.springframework.test.context.junit4.statements.RunAfterTestMethodCallbacks.evaluate(RunAfterTestMethodCallbacks.java:82)
at org.springframework.test.context.junit4.statements.SpringRepeat.evaluate(SpringRepeat.java:72)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:240)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:180)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:49)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.hibernate.LazyInitializationException: failed to lazily initialize a collection, no session or session was closed
at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationException(AbstractPersistentCollection.java:383)
at org.hibernate.collection.AbstractPersistentCollection.throwLazyInitializationExceptionIfNotConnected(AbstractPersistentCollection.java:375)
at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:122)
at org.hibernate.collection.PersistentSet.size(PersistentSet.java:162)
at org.hibernate.bugs.lazyinitexception.Parent.postLoad(Parent.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.hibernate.ejb.event.BeanCallback.invoke(BeanCallback.java:37)
at org.hibernate.ejb.event.EntityCallbackHandler.callback(EntityCallbackHandler.java:94)
at org.hibernate.ejb.event.EntityCallbackHandler.postLoad(EntityCallbackHandler.java:87)
at org.hibernate.ejb.event.EJB3PostLoadEventListener.onPostLoad(EJB3PostLoadEventListener.java:47)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:250)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:982)
at org.hibernate.loader.Loader.doQuery(Loader.java:857)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:274)
at org.hibernate.loader.Loader.loadEntity(Loader.java:2037)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:86)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:76)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3293)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:285)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:152)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1090)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:1005)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:998)
at org.hibernate.ejb.AbstractEntityManagerImpl.find(AbstractEntityManagerImpl.java:614)
... 36 more
{code}
A copy of the
--
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
11 years, 11 months
[Hibernate-JIRA] Created: (HHH-2280) Not-Null Constraint-Violation with unidirectional one-to-many mapping
by Robert Herschke (JIRA)
Not-Null Constraint-Violation with unidirectional one-to-many mapping
---------------------------------------------------------------------
Key: HHH-2280
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2280
Project: Hibernate3
Type: Bug
Versions: 3.2.0.cr4
Environment: Hibernate 3.2.0.cr4, Oracle 10XE
Reporter: Robert Herschke
Priority: Blocker
Attachments: one-to-many-test.zip
In some cases it is neccessary to have an unidirectional one-to-many mapping, but not using Join-Tables due to a legacy database system.
So it must be possible, to have a one-to-many mapping just via a foreign-key-mapping. The Child-Object must not know the Parent-Object in this case.
It must also be possible, to pay respect to a NOT-NULL-Constraint at this foreign-key due to restrictions on legacy database systems.
Hibernate doesn't support this, but throw a NOT-NULL-Constraint Violation Exception. The documentation says, "this is unusual" - to which I want to dissent.
See the attached testcase for details, that is adopted from your "one-to-many" testcase found in the 3.2.0 sources.
--
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
11 years, 11 months
[Hibernate-JIRA] Created: (HHH-4459) Query with Composite Primary Key parameter crashes when query cache is on
by Karol Bienkowski (JIRA)
Query with Composite Primary Key parameter crashes when query cache is on
-------------------------------------------------------------------------
Key: HHH-4459
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4459
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.3.2
Environment: Hibernate Core 3.3.2.GA, MySQL and H2
Reporter: Karol Bienkowski
I have an entity with a composite identifier (primary key) annotated with EmbeddedId:
@Embeddable
public class CompositeKey implements Serializable {
(...)
}
@Entity
public class EntityWithCompositeKey {
@EmbeddedId
public CompositeKey pk;
(...)
}
When executing query ...
FROM EntityWithCompositeKey e WHERE e.pk = :pk
... where ":pk" is bound to an instance of CompositeKey ...
query.setParamter("pk", new CompositeKey(..))
... I get the following exception:
javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of hhhxxxx.CompositeKey.a
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:614)
at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:76)
at hhhxxxx.HHHHxxxxTest.testGetByCompositeId(HHHHxxxxTest.java:46)
(...)
Caused by: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of hhhxxxx.CompositeKey.a
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:58)
at org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValue(AbstractComponentTuplizer.java:87)
at org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValues(AbstractComponentTuplizer.java:93)
at org.hibernate.tuple.component.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:109)
at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:376)
at org.hibernate.type.ComponentType.getHashCode(ComponentType.java:194)
at org.hibernate.engine.TypedValue.hashCode(TypedValue.java:66)
at java.util.HashMap$Entry.hashCode(Unknown Source)
at java.util.AbstractMap.hashCode(Unknown Source)
at org.hibernate.cache.QueryKey.generateHashCode(QueryKey.java:196)
at org.hibernate.cache.QueryKey.<init>(QueryKey.java:173)
at org.hibernate.cache.QueryKey.generateQueryKey(QueryKey.java:128)
at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2144)
at org.hibernate.loader.Loader.list(Loader.java:2121)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:401)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1149)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:67)
... 21 more
Caused by: java.lang.IllegalArgumentException: Can not set int field hhhxxxx.CompositeKey.a to [Ljava.lang.Object;
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(Unknown Source)
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(Unknown Source)
at sun.reflect.UnsafeIntegerFieldAccessorImpl.getInt(Unknown Source)
at sun.reflect.UnsafeIntegerFieldAccessorImpl.get(Unknown Source)
at java.lang.reflect.Field.get(Unknown Source)
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:55)
... 40 more
It used to work on 3.3.1.GA but fails in 3.3.2.GA. Turning off query cache works.
The direct reason for the error is that TypedValue.value is an Object[] but ComponentType.getHashCode() expects TypedValue.value to be of CompositeKey type.
I'll attach the working test case replicating the issue in a moment.
--
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
11 years, 11 months
[Hibernate-JIRA] Created: (HHH-6005) DefaultComponentSafeNamingStrategy breaks @ElementCollection of @Embeddables
by Artem Troitskiy (JIRA)
DefaultComponentSafeNamingStrategy breaks @ElementCollection of @Embeddables
----------------------------------------------------------------------------
Key: HHH-6005
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6005
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-Final
Reporter: Artem Troitskiy
Priority: Minor
{{DefaultComponentSafeNamingStrategy}} is incompatible with {{@ElementCollection}} of {{@Embeddable}} objects.
Given the following classes
{code:java}
@Entity
public class Foo {
@ElementCollection
private List<Bar> bars;
...
}
@Embeddable
public class Bar {
private String name;
...
}
{code}
and DefaultComponentSafeNamingStrategy as a naming strategy, Hibernate generates the schema with the following incorrect table:
bq. create table Foo_bars (Foo_id bigint not null, bars_collection&&element_name varchar(255))
{{.collection&&element.}} is an internal placeholder that should be removed before use of property name. Other naming strategies effectively remove it by using the part of property name after the last {{.}}, but {{DefaultComponentSafeNamingStrategy}} doesn't, it just replaces {{.}} with {{_}}.
Here is a workaround:
{code:java}
public class FixedDefaultComponentSafeNamingStrategy extends DefaultComponentSafeNamingStrategy {
@Override
public String propertyToColumnName(String propertyName) {
return super.propertyToColumnName(propertyName.replace(".collection&&element.", "."));
}
}
{code}
--
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
11 years, 11 months
[Hibernate-JIRA] Created: (HHH-5209) org.hibernate.hql.ast.QuerySyntaxException when running a JPQL query with a MEMBER OF on an @ElementCollection
by Pascal Thivent (JIRA)
org.hibernate.hql.ast.QuerySyntaxException when running a JPQL query with a MEMBER OF on an @ElementCollection
--------------------------------------------------------------------------------------------------------------
Key: HHH-5209
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5209
Project: Hibernate Core
Issue Type: Bug
Components: core, entity-manager
Affects Versions: 3.5.1
Environment: Hibernate EM 3.5.1, HSQLDB, Derby, H2
Reporter: Pascal Thivent
Priority: Blocker
Attachments: QueryTest.patch
I have an entity with an attribute of type {{Set<String>}} annotated as {{@ElementCollection}}. Running a query with a {{MEMBER OF}} on this attribute fails with Hibernate (but works with the RI):
{code}
select user from User user where :role member of user.roles
{code}
This is valid JPQL but Hibernate is not able to generate the corresponding SQL properly:
{code:java}
java.lang.IllegalArgumentException: org.hibernate.hql.ast.QuerySyntaxException: unexpected end of subtree [select user from org.hibernate.ejb.test.User user where :role member of user.roles]
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1222)
at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1168)
at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:271)
at org.hibernate.ejb.test.query.QueryTest.testMemberOfElementCollection(QueryTest.java:110)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:154)
at org.hibernate.test.annotations.HibernateTestCase.runTest(HibernateTestCase.java:95)
at org.hibernate.test.annotations.HibernateTestCase.runBare(HibernateTestCase.java:83)
at org.hibernate.ejb.test.TestCase.runBare(TestCase.java:224)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: org.hibernate.hql.ast.QuerySyntaxException: unexpected end of subtree [select user from org.hibernate.ejb.test.User user where :role member of user.roles]
at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:54)
at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:47)
at org.hibernate.hql.ast.ErrorCounter.throwQueryException(ErrorCounter.java:82)
at org.hibernate.hql.ast.QueryTranslatorImpl.generate(QueryTranslatorImpl.java:244)
at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:205)
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:98)
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:1761)
at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:268)
... 19 more
{code}
I'm not sure this would be the right place (this seems to be a problem in Hibernate Core actually) but I've implemented a test method in {{org.hibernate.ejb.test.query.QueryTest}} demonstrating the problem. The patch is 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
11 years, 11 months
[Hibernate-JIRA] Created: (HSEARCH-269) Spell check functionality needed
by John Griffin (JIRA)
Spell check functionality needed
--------------------------------
Key: HSEARCH-269
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-269
Project: Hibernate Search
Issue Type: New Feature
Components: engine, mapping
Affects Versions: 3.2.0
Reporter: John Griffin
Assignee: John Griffin
>From Emmanuel:
- more than one field and even more than one index should be the source of the dictionary
- declaring which field is part of a dictionary should be declarative @AddToDictionary(name="main-dictionary")
(with probably an optional field name(s))
- for a given dictionary name, we need to associate an index and probably a field prefix (to share the same index
for all dictionaries). This couold be by annotations or in the configuration (not sure)
- this index should be kept like any other DirectoryProvider in the HSearch intrastructure (we could then reuse
ReaderProvider internally and don't have leaks).
- we will probably add a manual dictionary reindex method and the SpellChecker API should be in the SearchFactory.
sf.getDictionary("main-dictionary").spellcheck(word, suggestion);
sf.getDictionary("main-dictionary").spellcheck(word, suggestion, entity, properties...); //not sure how useful is this one really
sf.getDictionary("main-dictionary").reindex();
this needs to be refined.
--
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
11 years, 11 months