Re: [hibernate-dev] [AND] Search: changing the way we search
Thanks fo that very valuable input. Let me through some ideas. This email is about the AND problem. On 03 Mar 2014, at 17:11, Guillaume Smet wrote: > > 1/ the aforementioned detail about sorting: we need AND badly in plain > text search; > > > III. So let's add an AND option... > --- > > Yeah, well, that's not so easy. > > Let's take a look at the code, especially our dear friend > ConnectedMultiFieldsTermQueryBuilder . > > When I started to look at HSEARCH-917, I thought it would be quite > easy to build lucene queries using a Lucene QueryParser instead of all > the machinery in ConnectedMultiFieldsTermQueryBuilder. It's not. > > Here are pointers to the main problems I have: > 1/ the getAllTermsFromText is cute when you want to OR the terms but > really bad when you need AND, especially when you use analyzers which > returns several tokens for a term (this is the case when you use the > SynonymFilter or the WordDelimiterFilter); Why do you say “especially”? Isn’t it “only" > 2/ the fieldBridge thing is quite painful for plain text search as we > are not sure that all the fields have the same fieldBridge and, thus, > the search terms might be different for each fields after applying the > fieldBridge. That would lead to different term queries but on different fields. So I am not sure I follow the problem you are describing. Any chance you can rephrase it? > > These problems are not so easy to solve in an absolute kind of way. > That's why I haven't made any progress on this problem. > > Let's illustrate the problem: > - you search for "several words in my content" (without ", it's not a > phrase query, just terms) > - you search in the fields title, summary and content so you expect to > find at least one occurrence of each term in one of these fields; If I understand you, you wan to find several and words and in and my and content in title or in summary or in content but all terms should be present in one of the field. Is that correct? What’s the use case behind? Or is that you want to find several and words and in and my and content but across all of the fields mentioned? > - for some reason, you have a different fieldBridge on one of the > fields and it's quite hard to define "at least one occurrence of each > term in one of these fields" as the fieldBridge might transform the > text. > > My point is that I don't see a way to fix the current DSL without > breaking some cases (note that the current code only works because > only the OR operator is supported) even if we might consider they are > weird. > >> From my perspective, a plainText branch of the DSL could ignore the > fieldBridge machinery but I'm not sure it's a good idea. That's why I > would like some feedback about this before moving in this direction. We already do some magic depending on the fieldbridge we have (especially the built-in ones vs custom ones). We might enable some features iif we know the field is built-in and predictable. Or literally if that is the same one. So, if we go and enable different classes of analyzers per field, I think we can solve the AND problem, the stack needs to be separated into: - an tokenizer that splits the stream into words - a set of filters that only normalise the words (lower case, accept, stemming, stop words probably, etc). - a set of filters that inject multiple tokens per initial “word” (ngrams and synonyms) It is ver possible that the first set of filter is always naturally before the second set of analyzers. Any counter example? With this, we can AND the various words and OR the second stream of tokens (or forbid them initially). We would apply the analysis in two phases. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Wildcard] Search: changing the way we search
This email is about wildcard On 03 Mar 2014, at 17:11, Guillaume Smet wrote: > > And why is it not ideal: > 3/ wildcard and analyzers are really a pain with Lucene and you need > to implement your own cleaning stuff to get a working wildcard query. > > > IV. About wildcard queries > -- > > Let's say it frankly: wildcard queries are a pain in Lucene. > > Let's take an example: > - You index "Parking" and you have a LowerCaseFilter so your index > contains "parking"; > - You search for Parking without wildcard, it will work; > - You search for Parki* with wildcard, yeah, it won't work. > > This is due to the fact that for wildcards, the analyzers are ignored. > Usually, because if you use ? or *, they can be replaced by the > filters you use in your analyzers. > > While we all understand the Lucene point of view from a technical > perspective, I don't think we can keep this position for Hibernate > Search as a user friendly search framework on top of Hibernate. > > At Open Wide, we have a quite complex method which rewrites a search > as a working autocompletion search which might work most of the time > (with a high value of most...). It's kinda ugly, far from perfect and > I'm wondering if we could have something more clever in Search. I once > talked with Emmanuel about having different analyzers for Indexing, > Querying (this is the Solr way) and Wildcards/Fuzzy search (this is > IMHO a good idea as the way you want to normalize your wildcard query > highly depends on the analyzer used to index your data). I would like to separate the notion of autosuggestion from the wildcard problem. To me they are separate and I would love to Hibernate Search to offer an autosuggest and spell checker API. Back to wildcard. If we have an analyser stack that separates normaliser filters from filters generating additional tokens (see my email [AND]), then it is piece of cake to apply the right filters, raise an exception if someone tries to wildcard on ngrams, and simply ignore the synonym filter. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Wildcard] Search: changing the way we search
On Tue, Mar 4, 2014 at 11:09 AM, Emmanuel Bernard wrote: > I would like to separate the notion of autosuggestion from the wildcard > problem. To me they are separate and I would love to Hibernate Search to > offer an autosuggest and spell checker API. AFAICS from the changelog of each version, autosuggest is still a vast work in progress in Lucene/Solr. > Back to wildcard. If we have an analyser stack that separates normaliser > filters from filters generating additional tokens (see my email [AND]), then > it is piece of cake to apply the right filters, raise an exception if someone > tries to wildcard on ngrams, and simply ignore the synonym filter. In theory, yes. But for the tokenization, we use WhitespaceTokenizer and WordDelimiterFilter which generates new tokens (for example, depending on the options you use, you can index wi-fi as wi and fi, wi-fi and wifi). The problem of this particular filter is also that we put it after the ASCIIFoldingFilter because we want the input to be as clean as possible but before the LowerCaseFilter as WordDelimiterFilter can do its magic on case change too. If you separate normalizer from tokenizer, I don't think it's going to be easy to order them adequately. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [AND] Search: changing the way we search
Hi Emmanuel, On Tue, Mar 4, 2014 at 11:09 AM, Emmanuel Bernard wrote: >> Here are pointers to the main problems I have: >> 1/ the getAllTermsFromText is cute when you want to OR the terms but >> really bad when you need AND, especially when you use analyzers which >> returns several tokens for a term (this is the case when you use the >> SynonymFilter or the WordDelimiterFilter); > > Why do you say "especially"? Isn't it "only" It's been a while, that's why I wasn't categorical. But, as far as I recall from my work back then, I think you're right. >> 2/ the fieldBridge thing is quite painful for plain text search as we >> are not sure that all the fields have the same fieldBridge and, thus, >> the search terms might be different for each fields after applying the >> fieldBridge. > > That would lead to different term queries but on different fields. So I am > not sure I follow the problem you are describing. Any chance you can rephrase > it? This point is related to the one below. > If I understand you, you wan to find several and words and in and my and > content in title or in summary or in content but all terms should be present > in one of the field. Is that correct? What's the use case behind? It's probably the most common use case we have. Let's say you have an entity called "Hotel whatever" and in its description it says it does have a swimming pool but the word "hotel" doesn't appear in the description (my example isn't the best chosen but I think you can easily imagine it does happen on real data). Our user is looking for "hotel swimming pool", and we want "Hotel whatever" to match. Of course, if you use a OR with a sort by score, it does work (more or less) but the main issue is that our customers don't want too many unrelated results. They only want items which really match the query. Moreover, they often don't want the results sorted by score so the OR + sort by score approach is really not acceptable. This is why we use MultiFieldQueryParser with AND as the default operator a lot when using Lucene directly and the (e)dismax parser when using Solr. >>> From my perspective, a plainText branch of the DSL could ignore the >> fieldBridge machinery but I'm not sure it's a good idea. That's why I >> would like some feedback about this before moving in this direction. > > We already do some magic depending on the fieldbridge we have (especially the > built-in ones vs custom ones). > We might enable some features iif we know the field is built-in and > predictable. Or literally if that is the same one. > > So, if we go and enable different classes of analyzers per field, I think we > can solve the AND problem, the stack needs to be separated into: > - an tokenizer that splits the stream into words > - a set of filters that only normalise the words (lower case, accept, > stemming, stop words probably, etc). > - a set of filters that inject multiple tokens per initial "word" (ngrams and > synonyms) > > It is ver possible that the first set of filter is always naturally before > the second set of analyzers. Any counter example? > > With this, we can AND the various words and OR the second stream of tokens > (or forbid them initially). We would apply the analysis in two phases. See my points in my other email. I'll try to write some code to explain what I would like to do. I'll keep you posted when I have something consistent. -- Guillaume ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Empty/null] Search: changing the way we search
On 03 Mar 2014, at 17:11, Guillaume Smet wrote: > 2/ we often need to add a clause only if the text isn't empty or the > object not null and we then need to add more logic than the fluent > approach allows it (I don't have any ideas/proposals for this one but > I think it's worth mentioning). > > > V. The "don't add this clause if null/empty" problem > > > Ideas welcome! > Can you explain with more details the use cases you are thinking about? Maybe a code example of how you would have to do it today. There are two problems I can think of: 1. the DSL tend to die in horrible pain if the input turns out full of stop words or other edge cases like that. We should list and test these 2. the user wants to add the input regardless of the value to make the DSL work at it’s best We might be able to address 2. even though I don’t think this solution covers everything. a. we could be smart and eliminate the boolean query when there is a single clause b. if we could have a marker NoopQuery object, we could silently ignore it and remove it from the boolean clause. The problem with the NoopQuery is that it could mena 3 things: - fail - return nothing - return everything ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Wildcard] Search: changing the way we search
On 04 Mar 2014, at 12:09, Guillaume Smet wrote: > On Tue, Mar 4, 2014 at 11:09 AM, Emmanuel Bernard > wrote: >> I would like to separate the notion of autosuggestion from the wildcard >> problem. To me they are separate and I would love to Hibernate Search to >> offer an autosuggest and spell checker API. > > AFAICS from the changelog of each version, autosuggest is still a vast > work in progress in Lucene/Solr. So? :) > >> Back to wildcard. If we have an analyser stack that separates normaliser >> filters from filters generating additional tokens (see my email [AND]), then >> it is piece of cake to apply the right filters, raise an exception if >> someone tries to wildcard on ngrams, and simply ignore the synonym filter. > > In theory, yes. > > But for the tokenization, we use WhitespaceTokenizer and > WordDelimiterFilter which generates new tokens (for example, depending > on the options you use, you can index wi-fi as wi and fi, wi-fi and > wifi). Ok that poses a problem for the wildcard if wi and if are separated. But I don’t think it’s an issue for the AND case as we would get the expected query: - hotel AND wi-fi - hotel AND wi AND fi And to be fair, how do you plan to make wildcard and wi fi work together in Lucene (any solution available). The solution I can think of is to index the property with an analyzer stack that does not split words like that in two tokens. > > The problem of this particular filter is also that we put it after the > ASCIIFoldingFilter because we want the input to be as clean as > possible but before the LowerCaseFilter as WordDelimiterFilter can do > its magic on case change too. > > If you separate normalizer from tokenizer, I don't think it's going to > be easy to order them adequately. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [AND] Search: changing the way we search
On 04 Mar 2014, at 12:24, Guillaume Smet wrote: > Hi Emmanuel, > > On Tue, Mar 4, 2014 at 11:09 AM, Emmanuel Bernard > wrote: > >> If I understand you, you wan to find several and words and in and my and >> content in title or in summary or in content but all terms should be present >> in one of the field. Is that correct? What's the use case behind? > > It's probably the most common use case we have. > > Let's say you have an entity called "Hotel whatever" and in its > description it says it does have a swimming pool but the word "hotel" > doesn't appear in the description (my example isn't the best chosen > but I think you can easily imagine it does happen on real data). > > Our user is looking for "hotel swimming pool", and we want "Hotel > whatever" to match. OK so you want the words hotel + swimming pool to be present somewhere in the sum of the corpus of title and description. That’s the second case I was describing then. Indeed it kinda fails if you don’t order by score but rather alphabetically or by distance. Have you considered the following: your query should only consider the top n, or the results whose score reaches 70% of the top score and then do your business sort on this subset. Anyways, to address this, one need to target fields that are: - using the same fieldbridge - using the same analyzer - do the trick I was describing around filters like ngrams (and then or) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [AND] Search: changing the way we search
On Tue, Mar 4, 2014 at 1:36 PM, Emmanuel Bernard wrote: > OK so you want the words hotel + swimming pool to be present somewhere in the > sum of the corpus of title and description. That's the second case I was > describing then. Indeed it kinda fails if you don't order by score but rather > alphabetically or by distance. > Have you considered the following: your query should only consider the top n, > or the results whose score reaches 70% of the top score and then do your > business sort on this subset. It doesn't work. Users want the results which really match and we can't have missing results or additional results. They search for something and they want to find exactly what they are looking for. Note: this is really 99.9% of our use cases, probably because we mostly develop business applications. > Anyways, to address this, one need to target fields that are: > - using the same fieldbridge > - using the same analyzer > - do the trick I was describing around filters like ngrams (and then or) That's when I stopped my work on HSEARCH-917. I wasn't sure I could decently require such conditions, at least not in the current API. I started to wonder if we could introduce a text() branch in parallel to keyword() and phrase() but never really posted about it. I would like to separate the user responsibility from the developer responsibility: - the user defines his search query. It's a little more clever than just a term search: he can use + - and "": that's why I would like to use a QueryParser directly (most of our users don't use it but some of them need it); - the developer defines how the search is done: it can search on several fields: for each field, the developer can define a boost (this is supported by the SimpleQueryParser) AND he can also define if it's a fuzzy query (not supported out of the box by the SimpleQueryParser). (we could even imagine to support minimum should match as the dismax parser does) Because, this is really what we need on a daily basis: my user don't really know if his search needs to be fuzzy or not. And I would like to be able to make the decision for him because I know the corpus of documents and I know it's going to be needed. I don't know if it looks like something interesting to you? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Wildcard] Search: changing the way we search
On Tue, Mar 4, 2014 at 1:24 PM, Emmanuel Bernard wrote: > And to be fair, how do you plan to make wildcard and wi fi work together in > Lucene (any solution available). The solution I can think of is to index the > property with an analyzer stack that does not split words like that in two > tokens. I don't use them for wildcard queries but I do use them for plain text queries and I need to be able to do that in that case. If we define a tokenizer phase then a normalizer phase in the analyzer definition, I won't be able to do so for my plain text queries. Or do you have something more specific to wildcard queries in mind? ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [Wildcard] Search: changing the way we search
On 04 Mar 2014, at 15:07, Guillaume Smet wrote: > On Tue, Mar 4, 2014 at 1:24 PM, Emmanuel Bernard > wrote: >> And to be fair, how do you plan to make wildcard and wi fi work together in >> Lucene (any solution available). The solution I can think of is to index the >> property with an analyzer stack that does not split words like that in two >> tokens. > > I don't use them for wildcard queries but I do use them for plain text > queries and I need to be able to do that in that case. If we define a > tokenizer phase then a normalizer phase in the analyzer definition, I > won't be able to do so for my plain text queries. Or do you have > something more specific to wildcard queries in mind? I am not quite sure what you are referring to by plain text query. To me that would be qb.keyword().onFields(“title”, “description”).matching(search).createQuery(); or very close to that. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Team meeting minutes
Here are the meeting minutes. I did add a manual summary since I don’t know how to effectively use the bot to its full potential. ## Validator 5.1 is out and plan to push it to WildFly as soon as they permit. ## Search ### MoreLikeThis Functional enough MoreLikeThis is out. Emmanuel needs to open JIRa issues for the remaining work Sanne needs to explore influence of minTermFreq / mindDocFreq over false positive due content pollution ### Release Release 5.0 Alpha 2 planned for Wednesday. Still need: - HSEARCH-1513 - maybe HSEARCH-1508 Keep an eye on Infinispan 7 changes to be able to roll back to 6 if schedule clash ### Roadmap Sanne to update http://hibernate.org/search/roadmap/ or JIRA with tiered focus to reach 5.0 final Sanne to place dates for each of these milestones to keep us honest. Might be kept team private to avoid noise. Sanne to steal a bit of Brett’s time from Steve around OSGi ### free-form Emmanuel to focus next on free-form as soon as mininal work on MLT is done (identified embedded elements) ## OGM Worked on Wildfly module bug (protected visibility). Davide to move forward to patch ORM to remove the OGM code duplication. Redis is Davide’s relaxation task. ### Neo4J Davide to focus on Neo4J (rebase, remote support and query support) ### Next release With Gunnar soon going dark (holiday and preparation for summit, things are a bit undefined. All bets on Neo4J and Davide Gunnar focuses on closing near-ending tasks by end of week (incl Adrian’s PR) ### Longer term Gunnar to explore optimisation related to embedded associations Gunnar to explore recovery API ### Emmanuel Not planning to work actively on a OGM features in the next 2 months. Negotiable. Working on Search has priority. ## CI Instabilities seen on Search should be gone now. ## Summit Gunnar and Sanne might be busy preparing Summit for a week. That’ll be a toll of 2 weeks off main project work. ## ORM Lots of very intimate back patting going on around performance improvement. Someone needs to take the lead and write a blog post on 4.2 vs 4.3 perf wise and the performance improvements tricks used. ## Full Minutes Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-04-14.52.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-04-14.52.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2014/hibernate-dev.2014-03-04-14.52.log.html ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [AND] Search: changing the way we search
On 04 Mar 2014, at 15:02, Guillaume Smet wrote: > On Tue, Mar 4, 2014 at 1:36 PM, Emmanuel Bernard > wrote: >> OK so you want the words hotel + swimming pool to be present somewhere in >> the sum of the corpus of title and description. That's the second case I was >> describing then. Indeed it kinda fails if you don't order by score but >> rather alphabetically or by distance. >> Have you considered the following: your query should only consider the top >> n, or the results whose score reaches 70% of the top score and then do your >> business sort on this subset. > > It doesn't work. Users want the results which really match and we > can't have missing results or additional results. > > They search for something and they want to find exactly what they are > looking for. > > Note: this is really 99.9% of our use cases, probably because we > mostly develop business applications. > >> Anyways, to address this, one need to target fields that are: >> - using the same fieldbridge >> - using the same analyzer >> - do the trick I was describing around filters like ngrams (and then or) > > That's when I stopped my work on HSEARCH-917. I wasn't sure I could > decently require such conditions, at least not in the current API. > > I started to wonder if we could introduce a text() branch in parallel > to keyword() and phrase() but never really posted about it. > > I would like to separate the user responsibility from the developer > responsibility: > - the user defines his search query. It's a little more clever than > just a term search: he can use + - and "": that's why I would like to > use a QueryParser directly (most of our users don't use it but some of > them need it); > - the developer defines how the search is done: it can search on > several fields: for each field, the developer can define a boost (this > is supported by the SimpleQueryParser) AND he can also define if it's > a fuzzy query (not supported out of the box by the SimpleQueryParser). > (we could even imagine to support minimum should match as the dismax > parser does) > > Because, this is really what we need on a daily basis: my user don't > really know if his search needs to be fuzzy or not. And I would like > to be able to make the decision for him because I know the corpus of > documents and I know it's going to be needed. > > I don't know if it looks like something interesting to you? Yes a text() branch injecting whatever from the user and letting the developer customise what needs to be searched makes sense to me. We can explore that but I am a bit skeptical that it will turn into a true `text()` clause rather than be a bit more friendly in other branches of the DSL. I’m happy to be proven wrong. But I am a bit confused and would love some code example to start from (as in doing what is required). searchInput ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [AND] Search: changing the way we search
On Tue, Mar 4, 2014 at 6:27 PM, Emmanuel Bernard wrote: > Yes a text() branch injecting whatever from the user and letting the > developer customise what needs to be searched makes sense to me. > We can explore that but I am a bit skeptical that it will turn into a true > `text()` clause rather than be a bit more friendly in other branches of the > DSL. > I'm happy to be proven wrong. But I am a bit confused and would love some > code example to start from (as in doing what is required). I think we mostly agree. It's just that I don't know if we'll find an acceptable way to change the behavior of the keyword() branch without breaking any applications out there. I'll post as soon as I have a working prototype of what I would like to achieve and then we can discuss from there. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Team meeting minutes
2014-03-04 18:05 GMT+01:00 Emmanuel Bernard : ## ORM > > Lots of very intimate back patting going on around performance improvement. > LOL. Was this your test whether anyone would be reading up to here :) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Team meeting minutes
On 4 Jan 2014, at 18:05, Emmanuel Bernard wrote: > Here are the meeting minutes. > I did add a manual summary since I don’t know how to effectively use the bot > to its full potential. > > ## Validator > > 5.1 is out and plan to push it to WildFly as soon as they permit. I am ways ahead of you guys - https://issues.jboss.org/browse/WFLY-3052 It is actually already merged. Not sure why the issue is not marked as such yet. > ## Search > > ### MoreLikeThis > > Functional enough MoreLikeThis is out. > Emmanuel needs to open JIRa issues for the remaining work > Sanne needs to explore influence of minTermFreq / mindDocFreq over false > positive due content pollution ### ClassLoaderService I am almost ready with the ClassLoaderService stuff. My working branch https://github.com/hferentschik/hibernate-search/commits/HSEARCH-1121 is compiling, rebased on top of current master and passing all tests. I still have a couple of TODOs to address, but it should be ready to be merged in a bit. Feel free to have a look and provide feedback. Once I am ready with this I will look into the upgrade to Lucene 4.7, mainly because the upgrade affects mainly the faceting code. Gives me also another reason to get back into this ;-) —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Team meeting minutes
On 03/04/2014 02:32 PM, Hardy Ferentschik wrote: > > On 4 Jan 2014, at 18:05, Emmanuel Bernard wrote: > >> Here are the meeting minutes. >> I did add a manual summary since I don’t know how to effectively use the bot >> to its full potential. >> >> ## Validator >> >> 5.1 is out and plan to push it to WildFly as soon as they permit. > > I am ways ahead of you guys - https://issues.jboss.org/browse/WFLY-3052 > It is actually already merged. Not sure why the issue is not marked as such > yet. I just closed it. After the WildFly committer merges the change, they usually don't update the jira. > >> ## Search >> >> ### MoreLikeThis >> >> Functional enough MoreLikeThis is out. >> Emmanuel needs to open JIRa issues for the remaining work >> Sanne needs to explore influence of minTermFreq / mindDocFreq over false >> positive due content pollution > > ### ClassLoaderService > > I am almost ready with the ClassLoaderService stuff. My working branch > https://github.com/hferentschik/hibernate-search/commits/HSEARCH-1121 > is compiling, rebased on top of current master and passing all tests. I still > have a couple of TODOs to address, but it should be ready to be merged > in a bit. Feel free to have a look and provide feedback. > > Once I am ready with this I will look into the upgrade to Lucene 4.7, mainly > because the upgrade affects mainly the faceting code. > Gives me also another reason to get back into this ;-) > > —Hardy > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Team meeting minutes
On 4 Jan 2014, at 20:41, Scott Marlow wrote: > On 03/04/2014 02:32 PM, Hardy Ferentschik wrote: >> >> On 4 Jan 2014, at 18:05, Emmanuel Bernard wrote: >> >>> Here are the meeting minutes. >>> I did add a manual summary since I don’t know how to effectively use the >>> bot to its full potential. >>> >>> ## Validator >>> >>> 5.1 is out and plan to push it to WildFly as soon as they permit. >> >> I am ways ahead of you guys - https://issues.jboss.org/browse/WFLY-3052 >> It is actually already merged. Not sure why the issue is not marked as such >> yet. > > I just closed it. After the WildFly committer merges the change, they > usually don't update the jira. I see. Good to know. —Hardy ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Team meeting minutes
On Tue 2014-03-04 20:32, Hardy Ferentschik wrote: > > On 4 Jan 2014, at 18:05, Emmanuel Bernard wrote: > > > Here are the meeting minutes. > > I did add a manual summary since I don’t know how to effectively use the > > bot to its full potential. > > > > ## Validator > > > > 5.1 is out and plan to push it to WildFly as soon as they permit. > > I am ways ahead of you guys - https://issues.jboss.org/browse/WFLY-3052 > It is actually already merged. Not sure why the issue is not marked as such > yet. > > > ## Search > > > > ### MoreLikeThis > > > > Functional enough MoreLikeThis is out. > > Emmanuel needs to open JIRa issues for the remaining work > > Sanne needs to explore influence of minTermFreq / mindDocFreq over false > > positive due content pollution > > ### ClassLoaderService > > I am almost ready with the ClassLoaderService stuff. My working branch > https://github.com/hferentschik/hibernate-search/commits/HSEARCH-1121 > is compiling, rebased on top of current master and passing all tests. I still > have a couple of TODOs to address, but it should be ready to be merged > in a bit. Feel free to have a look and provide feedback. Sweet :) ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
