Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

FastFacetedSearch (MultiStringIndex & MultiStringIndexCache) #9

Closed
wants to merge 7 commits into
from

Conversation

Projects
None yet
6 participants

No description provided.

sisve commented Oct 19, 2013

It would be awesome if formatting commits could be done different from functionality commits, so only the later need to be reviewed. Anyhow, in MultiStringIndexCache.CreateValue seems to use List<Int32>[] retArray for an lookup of documentId => list-if-indexes pointing to String[] mterms. (I like the idea of a value pool to perform something similar to interning.) However, the mterms array is initiated with new String[reader.MaxDoc + 1], it will not support cases where a reader have more unique terms than documents (you silently break out from that in line 920).

Sorry for lots of formatting in logical commit. I'd fix it. Also I'd add support for cases where a reader have more unique terms than documents, as you said.

Member

synhershko commented Apr 22, 2014

@sisve have you looked at this? are we good for pulling this in (probably need to go through the mailing list first, tho)

sisve commented Apr 22, 2014

A quick check shows that the issues regarding mterms is fixed. I've got some (perhaps mental) issues with the public order-field of MultiStringIndex. It seems to be some kind of lookup from FacetCollector.Collect (documentId => stringValues[]), but the fact that it's a public field, and named order, makes my insides itch. (I'm itchy that way...)

Member

synhershko commented Apr 22, 2014

I think you are right. Something in the way this PR is done highlights bad API on our part. I think it would be best to differ this to v4 where we are more flexible on making API changes.

Contributor

geobmx540 commented Nov 8, 2014

@synhershko @azubanov Is this still valid?

Contributor

NightOwl888 commented Jan 10, 2015

In case anyone needs faceted search before Lucene.Net 4.8 is available, I have just completed a .NET port of version 3.2.0 of the BoboBrowse faceted search engine, which is implemented on top of Lucene.Net, and compatible with Lucene.Net 3.0.3.

NuGet package (pre-release): https://www.nuget.org/packages/BoboBrowse.Net/
Documentation: https://github.com/NightOwl888/BoboBrowse.Net/wiki
Repository: https://github.com/NightOwl888/BoboBrowse.Net

It is currently in beta. All unit tests are passing, and it has worked flawlessly in the 3 projects I have tested it with. However, I am seeking a wider test audience in order to make certain it is stable before the official release.

Please report any issues you find (or just report in if you can't find any issues) on GitHub: https://github.com/NightOwl888/BoboBrowse.Net/issues

Thanks

Member

synhershko commented Jan 11, 2015

@geobmx540 I think we can close this in favor of moving forward with 4.8? backward support for v3 is dropped in favor of putting all resources in pushing v4 forward

Contributor

geobmx540 commented Jan 11, 2015

Agreed @synhershko

@asfgit asfgit closed this in 9d9e50f Jan 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment