NHibernate Search Questions

[Ayende Rahien]

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.

[Kailuo Wang]

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;

[Ayende Rahien]

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.

[Kailuo Wang]

roger.

[Ayende Rahien]

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.

[Paul Hatcher]

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: nhc...@googlegroups.com [mailto:nhc...@googlegroups.com] On Behalf Of Ayende Rahien
Sent: 01 October 2008 05:06
To: nhc...@googlegroups.com
Subject: Re: NHibernate Search Questions

[Ayende Rahien]

I am working on top of the current trunk, I branched the trunk because I didn't want to commit to there uncompilable code.

[paulh]

Ah, ok

---

From: "Ayende Rahien" <aye...@ayende.com>
Sent: 01 October 2008 09:15

[Fabio Maulo]

2008/10/1 Ayende Rahien <aye...@ayende.com>

org.hibernate.search.event - ported, note that this binds us to NH 2.1

Hi.

Which special behavior of NH2.1 (the trunk of NH) are you using ?

--
Fabio Maulo

[Ayende Rahien]

IPostCollectionXXX

[Fabio Maulo]

Ups...

If you wire NHSR release to NH2.1 release we have a problem... or better who don't like to work with "trunks" have a problem.

If you are sure that Collection Listeners is the only one thing you are using of NH2.1 we can back port it to the NH2.0.x branch, release NH2.0.2 and let NHSR have a release ASAP.

2008/10/1 Ayende Rahien <aye...@ayende.com>

--
Fabio Maulo

[Ayende Rahien]

I agree with that, but currently I think we should wait until the port is finished before we can see what the full deps are.

[Fabio Maulo]

Ok. When the port is done let me know, I can back port Collection-Listeners pretty quickly and then we can try what happen with that branch (mean I send you the working-copy and if there are no problem we can commit the work on the 2.0 branch).

2008/10/1 Ayende Rahien <aye...@ayende.com>

--
Fabio Maulo

[Fabio Maulo]

Continue the mystery.... in the project and more in the JIRA where NHSR have two strange "blocker" issues.

2008/10/1 Fabio Maulo <fabio...@gmail.com>

Ok. When the port is done let me know, I can back port Collection-Listeners pretty quickly and then we can try what happen with that branch (mean I send you the working-copy and if there are no problem we can commit the work on the 2.0 branch).

2008/10/1 Ayende Rahien <aye...@ayende.com>

I agree with that, but currently I think we should wait until the port is finished before we can see what the full deps are.

--
Fabio Maulo