[hibernate-dev] Re: Changes to Hibernate classes

[Manik Surtani]

cc'ing hibernate-dev.


On 2 Jun 2008, at 23:57, Emmanuel Bernard wrote:

> Those discussions should really go to hibernate-dev at lists.jboss.org.  
> No need to hide that :)
>
> On  Jun 2, 2008, at 12:46, Navin Surtani wrote:
>
>> A couple more things have cropped up: -
>>
>>  * Where do you create and register FullTextIndexEventListeners?
>
> It's either done explicitly by the user, or done by Hibernate  
> Annotations
> http://www.hibernate.org/hib_docs/search/reference/en/html_single/#d0e880
>
>>
>>  * 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.

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.

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.

> 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?

Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik at jboss.org