Cool I definitely like the immutable SearchFactory. while you're thinking about a new contract to accomodate the new requirements, could you also consider the following so that we won't have to break twice:
1) Lucene's new near-real-time indexing enables you to open an IndexReader from the currently open IndexWriter (to share some open buffers). This means a ReaderProvider could benefit from somehow getting a reference to the currently opened IndexWriter - makes sense only when using a Lucene backend so it should be optional. 2) If we really need HSEARCH-152, it would need the DirectoryProvider to be able to get access to the relevant Workspace: it needs to ask the current IndexWriter to take snapshots and prevent the IW to be closed while it's replicating. Seems there's going to be a mutual dependency, so one of the two will likely not be able to be immutable. Workspace could register itself back to the DP? I didn't thinkg about it yet, but would likely need to change the contracts too. 3) About Infinispan DirectoryProvider : seems a good time to workout the SPI idea you where having, to be able to plug it in while it's built by a separate module? Reminder: that's a requirement for InfinispanDP because it needs Java6. The DP itself is trivial to implement, if you pave the road to this pattern. sorry for being the complicator at this round... please make it as simple as possible, just consider that these are on the "todo soon" list too. Cheers, Sanne 2010/6/7 Emmanuel Bernard <emman...@hibernate.org>: > Trying again with the txt extension this time. > > > > > On 7 juin 2010, at 16:34, Emmanuel Bernard wrote: > >> Hi guys >> I've been working on HSEARCH-397 lately. >> I had to do HSEARCH-541. I had to change the initialize contract of many >> SPIs: >> - ReaderProvider >> - Worker >> - DirectoryProvider >> - BackendQueueProcessorFactory >> - OptimizerStrategy >> >> The idea is to pass a BuildContext, WritableBuildContect and >> WorkerBuildContext object to initialize and containing a subset of the >> SearchFactoryImplementor contract. >> For services that require a reference to the SFI, I've provided an >> getUnititializedSearchFactoryImplementor() whose object cannot be used until >> after initialize is done. >> >> The bad news is that it breaks some semi public contracts. The good news is >> that it opens the doors to: >> - create a SearchFactoryBuilder (that will help solve HSEARCH-397) >> - make SearchFactoryImpl immutable (Sanne will like it).. >> >> What do you think? I think the benefit is worth breaking the contracts. I've >> attached the burst of patches that lead to this. >> >> >> >> PS Maybe I could create a SFImplementor simulator for legacy >> implementations, but that complicates things. >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
