[hibernate-dev] HSearch + JBoss Cache Design (Was: Re: Changes to Hibernate classes)
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.