I am working on top of the current trunk, I branched the trunk because I didn't want to commit to there uncompilable code.
On Wed, Oct 1, 2008 at 11:10 AM, Paul Hatcher <[EMAIL PROTECTED]> wrote: > 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-big-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 -~----------~----~----~----~------~----~------~--~---
