[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 [EMAIL 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(...),
                                           [EMAIL 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
[EMAIL PROTECTED]






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