[hibernate-dev] Mutable natural key caching?

[Elias Ross]

I've been looking to optimize the caching of an application which uses
a mutable natural key, an account phone number.

Hibernate does not yet support optimized caching of
@NaturalId(mutable=false), because of how the current natural ID
relies on immutable IDs. The caching associates a QueryKey -> results
and it's impossible to evict the QueryKey since the natural keys are
embedded in it.

One solution I considered was to create an association between a set
of natural ID values and "QueryKey". When a query is made with mutable
natural keys, an association would be made. This could be done within
"StandardQueryCache." And then when an entity is updated or removed,
if there are mutable natural keys, Hibernate could locate the query
and remove it as well. I'm not sure how I could implement this part.
I'm guessing I'd have to add a method to QueryCache to do the removal.

public interface QueryCache {

...
public void remove(NaturalIdAssocation nia) throws HibernateException;

}

public class NaturalIdAssociation implements Serializeable {
  Type type;
  Set keys;
}

Actually, thinking this over, having this removal operation would fix
some other issues when non-mutable natural id entities are removed.
For instance, HHH-3478, a problem found using EntityManager and
natural IDs.

Thoughts?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Spellchecker in HSearch

[Emmanuel Bernard]

Alright so John showed interest in the are. Go open a JIRA issue and  
let's keep the ball rolling,

--
Emmanuel Bernard
http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com 
 | http://twitter.com/emmanuelbernard

Hibernate Search in Action (http://is.gd/Dl1)

On  Sep 13, 2008, at 10:19, Emmanuel Bernard wrote:

OK I looked at the SpellChecker code from the Lucene contrib) and  
there is no trivial way to integrate it more nicely into Hibernate  
Search. They did not really plan for flexibility.


But it's doable to fork this code and make a spellchecker feature in  
Hibernate Search. Here are a few limitations they have that we need  
to remove. Here is a proposal.
 - 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();

Of course this needs to be refined.

This is probably 3 or 4 days of work but unfortunately we cannot do  
that for the book it seems. I would be wort mentioning in the  
section that a more integrated solution in on it's way.


--
Emmanuel Bernard
http://in.relation.to/Bloggers/Emmanuel | http://blog.emmanuelbernard.com 
 | http://twitter.com/emmanuelbernard

Hibernate Search in Action (http://is.gd/Dl1)

On  Sep 12, 2008, at 09:15, John Griffin wrote:



Here's the file as a zip. Maybe the pdf wasn't passing.

Also, Nermina pointed out to me that I skipped section 7.3. So ANY  
reference

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev