Re: [hibernate-dev] Hibernate Search, more API changes in SearchFactory
On 24 juil. 2011, at 21:19, Sanne Grinovero wrote:
> Hello,
> I'm thinking to hide the ReaderProvider API from the public interface;
> it will still be available at SPI level, but I would prefer to keep
> the option open to remove the ReaderProvider altogether in a near
> future (replacing it by something similar).
SPI for which purpose? Which integration framework would need it?
>
> This API is currently used when the end user needs "low level" access
> to the index by getting control of an IndexReader, but currently he
> needs to pass in the DirectoryProviders (gone already),
> so I'd transform the API usage from current:
>
> DocumentBuilder builderForX = searchFactory.getDocumentBuilder();
> DirectoryProvider[] targetDps = // find out which DPs you want from
> each documentBuilder (??? -- quite some questions on this usually)
> IndexReader indexreader =
> searchFactory.getReaderProvider().openReader( targetDps );
> try {
> //play with reader
> }
> finally {
> searchFactory.getReaderProvider().closeReader( indexReader );
> }
>
> into this:
>
> IndexReader indexReader = getSearchFactory().openIndexReader(
> LargeDocument.class, OtherType,class );
> try {
> //play with reader
> }
> finally {
> searchFactory.closeReader( indexReader );
> }
My slight concern is that you no longer an select one shard or a subset of and
open an indexReader on top of it. Is that a valid use case?
Should these method be hosted on SearchFactory or on some other object
accessible from the SF?
>
> Or for the closing stage we could go so far to require only
> indexReader.close();
We could have done that for the previous API I think but I introduced the close
method to be more symmetric and make it easier to track bugs.
PS don't forget to mention all that in the migration guide.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Search, more API changes in SearchFactory
2011/7/25 Emmanuel Bernard :
>
> On 24 juil. 2011, at 21:19, Sanne Grinovero wrote:
>
>> Hello,
>> I'm thinking to hide the ReaderProvider API from the public interface;
>> it will still be available at SPI level, but I would prefer to keep
>> the option open to remove the ReaderProvider altogether in a near
>> future (replacing it by something similar).
>
> SPI for which purpose? Which integration framework would need it?
Not that I know of, we could demote it to the implementor level.
>> This API is currently used when the end user needs "low level" access
>> to the index by getting control of an IndexReader, but currently he
>> needs to pass in the DirectoryProviders (gone already),
>> so I'd transform the API usage from current:
>>
>> DocumentBuilder builderForX = searchFactory.getDocumentBuilder();
>> DirectoryProvider[] targetDps = // find out which DPs you want from
>> each documentBuilder (??? -- quite some questions on this usually)
>> IndexReader indexreader =
>> searchFactory.getReaderProvider().openReader( targetDps );
>> try {
>> //play with reader
>> }
>> finally {
>> searchFactory.getReaderProvider().closeReader( indexReader );
>> }
>>
>> into this:
>>
>> IndexReader indexReader = getSearchFactory().openIndexReader(
>> LargeDocument.class, OtherType,class );
>> try {
>> //play with reader
>> }
>> finally {
>> searchFactory.closeReader( indexReader );
>> }
>
> My slight concern is that you no longer an select one shard or a subset of
> and open an indexReader on top of it. Is that a valid use case?
Not sure if that's a common use case, but is certainly valid. There
are alternative strategies which involves more hops; method names are
not final as I expect them to be set when we'll review my pull
request, currently it would look like as:
searchFactory.getIndexMappingForEntity(Class
entityType).getIndexManagers() [ shardIndex ] .openReader();
or alternatively:
searchFactory.getAllIndexesManager().getIndexManager(String
targetIndexName).openReader();
But both these methods won't return a MultiReader but a vanilla
read-only IndexReader, targeting the single index.
BTW, likely the [ shardIndex ] will be replaced by a map instead of an
array, so get( String shardName ) to better fit with dynamic sharding.
Cheers,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] IRC Developer Meeting 7/25
Meeting ended Mon Jul 25 16:17:03 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2011/hibernate-dev.2011-07-25-15.11.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2011/hibernate-dev.2011-07-25-15.11.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2011/hibernate-dev.2011-07-25-15.11.log.html -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Metamodel component binding
Here is the work I have been doing on component bindings: https://github.com/sebersole/hibernate-core/tree/HHH-6480 Hardy, the test is currently failing for annotations because components are currently being pushed to org.hibernate.metamodel.source.annotations.entity.ConfiguredClass#simpleAttributeMap instead of org.hibernate.metamodel.source.annotations.entity.ConfiguredClass#embeddedClasses -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Metamodel component binding
On 07/25/2011 02:20 PM, Steve Ebersole wrote: > Hardy, the test is currently failing for annotations because components > are currently being pushed to > org.hibernate.metamodel.source.annotations.entity.ConfiguredClass#simpleAttributeMap > instead of > org.hibernate.metamodel.source.annotations.entity.ConfiguredClass#embeddedClasses I should clarify... Even if the components get pushed to that embeddedClasses map the test will still fail because I have not integrated that piece in. I was basically feeling my way around that code but had to stop when I hit that condition. -- st...@hibernate.org http://hibernate.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
