Why go with this rather than the current NH Search trunk - there's not that much left? Ok, here's the current status of NH Search... General --------------- 1. Directory of both project and test aligned with Hibernate.Search - this makes it easier to check what has/hasn't been ported 2. Placeholder files in the code project for items that have not be ported yet, generally included so that stuff compiles. 3. Placeholder files in test project, but not included in project until actually written. Code ------- Attributes - All attributes ported, slightly different from the Hibernate one due to .NET capabilities, e.g. we don't need attribute collection classes. Backend - Fully ported as far as I am aware. Bridge - Fully ported Cfg - Our implementation due to config differences Engine - Largely done, DocumentExtractor needs testing, but need to check tests/test coverage on ObjectLoader/ProjectionLoader/QueryLoader Event - FullTextIndexCollectionEventListener still to be done Filter - About 2-3 classes still need porting Impl - SearchFactoryImpl completed, not sure where FullTextSessionImpl goes to, might be redundant once the listener stuff is completed Query - Some stuff not achievable here yet (needs ScrollableResult) Reader - Fully ported Store - Largely done, need to finish/test optimizer strategy stuff Tests -------- Attributes - Done, 83% coverage Backend - Done apart from optimize, 73% coverage Bridge - Done, 89% Cfg - Some work still to do, 73% coverage Engine - Document builder at 73% coverage, see stuff above above ObjectLoader etc Event - Done, 89% coverage Filter - TBD Impl - TBD, only 33% coverage Query - 75% Reader - 40% still need tests for shared/not-shared & custom readers Store - 75% Store/Optimization - TBD Hope that gives a reasonable description, feel free to ask questions. Paul
_____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Ayende Rahien Sent: 01 October 2008 05:06 To: [email protected] Subject: Re: NHibernate Search Questions You can see current status here: https://nhcontrib.svn.sourceforge.net/svnroot/nhcontrib/branches/nh-search-b ig-port-from-hs-r15224 org.hibernate.search - 100% org.hibernate.search.annotations - 100% org.hibernate.search.backend - 90%: - Workspace - Not touched at the moment. org.hibernate.search.backend.configuration - 90% - Environment.WORKER_THREADPOOL_SIZE - not ported - Environment.WORKER_WORKQUEUE_SIZE - not ported org.hibernate.search.backend.impl.jms - not ported, we need an MSMQ impl org.hibernate.search.backend.impl.lucene - 100% org.hibernate.search.bridge.builtin - not ported all value type bridges, all are satisfied using ValueTypeBridge org.hibernate.search.bridge - ported org.hibernate.search.cfg - seems like we can't really use that, and there is a working implementation already, deferring inspecting that for now Related to that, I couldn't port ContextHolder properly, needs further review. Solr integration (InitContext.BuildAnalyzer & SolrAnalyzerBuilder) is not there. org.hibernate.search.engine - 100% org.hibernate.search.event - ported, note that this binds us to NH 2.1 SearchFactoryImpl.indexStrategy - not sure how to deal with that. Again, problem with differences between NH config and Hib config. On Mon, Sep 29, 2008 at 9:10 PM, Kailuo Wang <[EMAIL PROTECTED]> wrote: roger. On Mon, Sep 29, 2008 at 1:46 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: Okay, that make sense. I am now going through the source code and comparing hib to nh. In particular, me and Fabio would like to make an alpha 1 release, but I would like to have a solid understanding on the difference that we have between the two. If you can watch the commit stream for today and tomorrow, and comment on what you think, I would be grateful. On Mon, Sep 29, 2008 at 8:39 PM, Kailuo Wang <[EMAIL PROTECTED]> wrote: When I ported that part, there is no WorkType.COLLECTION yet, so basically I let that Layer class do nothing. Once we have WorkType.COLLECTION, we just need to un-comment the line return type != WorkType.COLLECTION ; and return type == WorkType.COLLECTION; On Mon, Sep 29, 2008 at 12:03 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: What is the deal with BatchedQueueingProcessor.Layer ? It looks like it is supposed to process collection on second go, but it always process everything in the first go, and nothing in the second. LuceneWork and derivatives looks like a classic textbook DON'T DO THIS example for how not to use inheritance. I am leaning toward making the behavior use polymorphism rather than explicit checks everywhere. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "NHibernate Contrib - Development Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com.ar/group/nhcdevs?hl=en -~----------~----~----~----~------~----~------~--~---
