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
