cc'ing hibernate-dev.


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

> Those discussions should really go to hibernate-dev@(protected).
> 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=@(protected)() )
> 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@(protected)






_______________________________________________
hibernate-dev mailing list
hibernate-dev@(protected)
https://lists.jboss.org/mailman/listinfo/hibernate-dev