[hibernate-dev] [HSEARCH] Breaking some contracts

[Sanne Grinovero]

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 <emmanuel at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>