[hibernate-dev] HSearch + JBoss Cache Design (Was: Re: Changes to Hibernate classes)

[Emmanuel Bernard]

On  Jun 2, 2008, at 19:26, Manik Surtani wrote:
>>
>>
>>>
>>> * How can the SearchFactoryImpl class /lazily /update the document
>>>   builder map in that same class? Would you suggest a subclass ?? In
>>>   JBC I don't know before-hand as to what types are going to be
>>>   indexed, so this will have to be done lazily.
>>
>> This is quite problematic as a lot of the concurrency scheme  
>> suppose we build all the metadata upfront in a concurrent-safe way.
>> I think we discussed that earlier and we agreed to pass a list of  
>> expected classes up front for now.
>
> Yes, of course.  We could use a classpath scanner, to scan for  
> annotations, but that can be problematic/unreliable/slow?  I guess  
> explicit declaration is the way to go then.

The main problem with the scanner is that you don't have any notion of  
packaging. You can't easily restrict to JAR in a natural way.

>
>
> Regarding how this is bootstrapped, I was thinking about publishing  
> this as a separate "edition" of JBoss Cache.  This project, lets  
> call it jbosscache-searchable for now, would have a dependency on  
> jbosscache-core and hibernate-search.  The central class could be a  
> org.jboss.cache.search.SearchableCache interface, which is a sub- 
> interface of org.jboss.cache.Cache, adding a single method:
>
> 	List<Object> find(Query q);
>
> One would create a SearchableCache using a SearchableCacheFactory,  
> which would expose a single method:
>
> 	SearchableCache createSearchableCache(Cache underlyingCache,  
> Class... typesToIndex);
>
> This method could then initialize and set up Hibernate Search  
> internals including document builder maps, etc., attach cache  
> listeners, and provide a proxy which proxies all normal cache  
> methods to the underlying cache, and handles the find() method the  
> way FullTextSession handles it.

Not too happy. Here is the reason. One of the key success of Hibernate  
Search is that it integrates as seamlessly as possible with Hibernate  
Core. Particularly all the init process is done transparently at HCore  
init time, with no need to hold a separate Search Factory. The  
Hibernate SessionFactory is the placeholder.
Where would your users store the SearchableCacheFactory?

Does JBCache has some sort of initialization hook that is run by the  
CacheFactory? That would be the ideal place.

>
>
> WDYT?
>
>
>>> * How can you pass a documentId directly to a Worker? The types
>>>   being indexed will not have the documentId annotation - this will
>>>   have to be generated based on Fqn and key. What type does this
>>>   have to be - can it be an Object?
>>
>> It can be an object provided that the final id (the FQN + key) can  
>> be transformed into a unique String.
>> The String can then be passed to Work when building it.
>
> Yes, this can be done.  We could create a wrapper class that is able  
> to convert between the two representations.

Is that wrapper specific to the actual object type or can it be generic?

>
>
>> To get DocumentBuilder work properly, we will need to adjust it to  
>> pickup a class level @ProvidedId (more likely a different  
>> annotation).
>>
>> @Indexed
>> @ProvidedId(name="id", //field name
>>                                           bridge= @FieldBridge(...),
>>                                           boost=@Boost() )
>> public class MyJBCCachedObject {
>> }
>>
>> @ProvidedId means that we won't be able to use @ContainedIn  
>> probably (as we don't have a getter). We can think about that later.
>>
>
> I'm guessing this is a marker to inform the DocumentBuilder not to  
> expect a @DocumentId field, and with information on how to fetch a  
> document id to be used in it's place?

Yup, but not only to fetch it (from Lucene), also to describe where to  
store it and how.