[jira] [Updated] (LUCENE-5366) Add autoGeneratePhraseQueries into StandardQueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiki Sugawara updated LUCENE-5366: --- Attachment: LUCEN-5366_4x.patch patch for 4.x branch > Add autoGeneratePhraseQueries into StandardQueryParser > -- > > Key: LUCENE-5366 > URL: https://issues.apache.org/jira/browse/LUCENE-5366 > Project: Lucene - Core > Issue Type: Improvement > Components: core/queryparser >Affects Versions: 4.6 >Reporter: Taiki Sugawara > Attachments: LUCEN-5366.patch, LUCEN-5366_4x.patch > > > classic.QueryParser has an autoGeneratePhraseQueries but > flexible.standard.StandardQueryParser does not have it. > autoGeneratePhraseQueries feature is useful when using CJKAnalyzer. I wrote a > patch that adds this feature into StandardQueryParser. > Please apply this patch if you'd like. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5366) Add autoGeneratePhraseQueries into StandardQueryParser
[ https://issues.apache.org/jira/browse/LUCENE-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taiki Sugawara updated LUCENE-5366: --- Attachment: LUCEN-5366.patch > Add autoGeneratePhraseQueries into StandardQueryParser > -- > > Key: LUCENE-5366 > URL: https://issues.apache.org/jira/browse/LUCENE-5366 > Project: Lucene - Core > Issue Type: Improvement > Components: core/queryparser >Affects Versions: 4.6 >Reporter: Taiki Sugawara > Attachments: LUCEN-5366.patch > > > classic.QueryParser has an autoGeneratePhraseQueries but > flexible.standard.StandardQueryParser does not have it. > autoGeneratePhraseQueries feature is useful when using CJKAnalyzer. I wrote a > patch that adds this feature into StandardQueryParser. > Please apply this patch if you'd like. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5366) Add autoGeneratePhraseQueries into StandardQueryParser
Taiki Sugawara created LUCENE-5366: -- Summary: Add autoGeneratePhraseQueries into StandardQueryParser Key: LUCENE-5366 URL: https://issues.apache.org/jira/browse/LUCENE-5366 Project: Lucene - Core Issue Type: Improvement Components: core/queryparser Affects Versions: 4.6 Reporter: Taiki Sugawara classic.QueryParser has an autoGeneratePhraseQueries but flexible.standard.StandardQueryParser does not have it. autoGeneratePhraseQueries feature is useful when using CJKAnalyzer. I wrote a patch that adds this feature into StandardQueryParser. Please apply this patch if you'd like. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5541) Allow QueryElevationComponent to accept elevateIds and excludeIds as http parameters
[ https://issues.apache.org/jira/browse/SOLR-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842314#comment-13842314 ] Joel Bernstein commented on SOLR-5541: -- Wondering if having two separate elevation components would be confusing? Looking through the code it looks like the XML config loading happens on demand so it wouldn't get triggered by accident. Also the component needs to be switched on so it seems like it would be safe in the default list. > Allow QueryElevationComponent to accept elevateIds and excludeIds as http > parameters > > > Key: SOLR-5541 > URL: https://issues.apache.org/jira/browse/SOLR-5541 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 4.6 >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Minor > Fix For: 4.7 > > Attachments: SOLR-5541.patch > > > The QueryElevationComponent currently uses an xml file to map query strings > to elevateIds and excludeIds. > This ticket adds the ability to pass in elevateIds and excludeIds through two > new http parameters "elevateIds" and "excludeIds". > This will allow more sophisticated business logic to be used in selecting > which ids to elevate/exclude. > Proposed syntax: > http://localhost:8983/solr/elevate?q=*:*&elevatedIds=3,4&excludeIds=6,8 > The elevateIds and excludeIds point to the unique document Id. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5364) Review usages of hard-coded Version constants
[
https://issues.apache.org/jira/browse/LUCENE-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5364:
---
Attachment: LUCENE-5364-branch_4x.patch
LUCENE-5364-trunk.patch
slightly modified trunk patch, and branch_4x patch.
I'll wait a couple of days before committing, in case anybody wants to review.
> Review usages of hard-coded Version constants
> -
>
> Key: LUCENE-5364
> URL: https://issues.apache.org/jira/browse/LUCENE-5364
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/other
>Affects Versions: 5.0, 4.7
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-5364-branch_4x.patch, LUCENE-5364-trunk.patch,
> LUCENE-5364-trunk.patch
>
>
> There are some hard-coded {{Version.LUCENE_XY}} constants used in various
> places. Some of these are intentional and appropriate:
> * in deprecated code, e.g. {{ArabicLetterTokenizer}}, deprecated in 3.1, uses
> {{Version.LUCENE_31}}
> * to make behavior version-dependent (e.g. {{StandardTokenizer}} and other
> analysis components)
> * to test different behavior at different points in history (e.g.
> {{TestStopFilter}} to test position increments)
> But should hard-coded constants be used elsewhere?
> For those that should remain, and need to be updated with each release, there
> should be an easy way to find them.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1632: -- Attachment: SOLR-1632.patch Whoops - attached the wrong patch this morning. Anyway, here is a new one. * Attempted to make LRUStatsCache thread safe. * Lot's of little clean up / little improvements > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 5.0, 4.7 > > Attachments: 3x_SOLR-1632_doesntwork.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > distrib-2.patch, distrib.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1632: -- Attachment: (was: SOLR-1301.patch) > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 5.0, 4.7 > > Attachments: 3x_SOLR-1632_doesntwork.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, distrib-2.patch, > distrib.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5541) Allow QueryElevationComponent to accept elevateIds and excludeIds as http parameters
[ https://issues.apache.org/jira/browse/SOLR-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842301#comment-13842301 ] Hoss Man commented on SOLR-5541: Joel: This smells like the kind of thing that could easily be it's own Component (using a common base class with the existing QueryElevationComponent containing code refactored out of QEC) .. and since this new type of elevation wouldn't require any explicit XML configuration, it could concievably be be wired into the default list of components in SearchHandler. thoughts? > Allow QueryElevationComponent to accept elevateIds and excludeIds as http > parameters > > > Key: SOLR-5541 > URL: https://issues.apache.org/jira/browse/SOLR-5541 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 4.6 >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Minor > Fix For: 4.7 > > Attachments: SOLR-5541.patch > > > The QueryElevationComponent currently uses an xml file to map query strings > to elevateIds and excludeIds. > This ticket adds the ability to pass in elevateIds and excludeIds through two > new http parameters "elevateIds" and "excludeIds". > This will allow more sophisticated business logic to be used in selecting > which ids to elevate/exclude. > Proposed syntax: > http://localhost:8983/solr/elevate?q=*:*&elevatedIds=3,4&excludeIds=6,8 > The elevateIds and excludeIds point to the unique document Id. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5541) Allow QueryElevationComponent to accept elevateIds and excludeIds as http parameters
[ https://issues.apache.org/jira/browse/SOLR-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842298#comment-13842298 ] Joel Bernstein edited comment on SOLR-5541 at 12/7/13 7:18 PM: --- Initial patch, built from trunk was (Author: joel.bernstein): Initial patch > Allow QueryElevationComponent to accept elevateIds and excludeIds as http > parameters > > > Key: SOLR-5541 > URL: https://issues.apache.org/jira/browse/SOLR-5541 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 4.6 >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Minor > Fix For: 4.7 > > Attachments: SOLR-5541.patch > > > The QueryElevationComponent currently uses an xml file to map query strings > to elevateIds and excludeIds. > This ticket adds the ability to pass in elevateIds and excludeIds through two > new http parameters "elevateIds" and "excludeIds". > This will allow more sophisticated business logic to be used in selecting > which ids to elevate/exclude. > Proposed syntax: > http://localhost:8983/solr/elevate?q=*:*&elevatedIds=3,4&excludeIds=6,8 > The elevateIds and excludeIds point to the unique document Id. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5541) Allow QueryElevationComponent to accept elevateIds and excludeIds as http parameters
[ https://issues.apache.org/jira/browse/SOLR-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein updated SOLR-5541: - Attachment: SOLR-5541.patch Initial patch > Allow QueryElevationComponent to accept elevateIds and excludeIds as http > parameters > > > Key: SOLR-5541 > URL: https://issues.apache.org/jira/browse/SOLR-5541 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 4.6 >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Minor > Fix For: 4.7 > > Attachments: SOLR-5541.patch > > > The QueryElevationComponent currently uses an xml file to map query strings > to elevateIds and excludeIds. > This ticket adds the ability to pass in elevateIds and excludeIds through two > new http parameters "elevateIds" and "excludeIds". > This will allow more sophisticated business logic to be used in selecting > which ids to elevate/exclude. > Proposed syntax: > http://localhost:8983/solr/elevate?q=*:*&elevatedIds=3,4&excludeIds=6,8 > The elevateIds and excludeIds point to the unique document Id. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5541) Allow QueryElevationComponent to accept elevateIds and excludeIds as http parameters
Joel Bernstein created SOLR-5541: Summary: Allow QueryElevationComponent to accept elevateIds and excludeIds as http parameters Key: SOLR-5541 URL: https://issues.apache.org/jira/browse/SOLR-5541 Project: Solr Issue Type: Improvement Components: SearchComponents - other Affects Versions: 4.6 Reporter: Joel Bernstein Priority: Minor Fix For: 4.7 The QueryElevationComponent currently uses an xml file to map query strings to elevateIds and excludeIds. This ticket adds the ability to pass in elevateIds and excludeIds through two new http parameters "elevateIds" and "excludeIds". This will allow more sophisticated business logic to be used in selecting which ids to elevate/exclude. Proposed syntax: http://localhost:8983/solr/elevate?q=*:*&elevatedIds=3,4&excludeIds=6,8 The elevateIds and excludeIds point to the unique document Id. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5541) Allow QueryElevationComponent to accept elevateIds and excludeIds as http parameters
[ https://issues.apache.org/jira/browse/SOLR-5541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joel Bernstein reassigned SOLR-5541: Assignee: Joel Bernstein > Allow QueryElevationComponent to accept elevateIds and excludeIds as http > parameters > > > Key: SOLR-5541 > URL: https://issues.apache.org/jira/browse/SOLR-5541 > Project: Solr > Issue Type: Improvement > Components: SearchComponents - other >Affects Versions: 4.6 >Reporter: Joel Bernstein >Assignee: Joel Bernstein >Priority: Minor > Fix For: 4.7 > > > The QueryElevationComponent currently uses an xml file to map query strings > to elevateIds and excludeIds. > This ticket adds the ability to pass in elevateIds and excludeIds through two > new http parameters "elevateIds" and "excludeIds". > This will allow more sophisticated business logic to be used in selecting > which ids to elevate/exclude. > Proposed syntax: > http://localhost:8983/solr/elevate?q=*:*&elevatedIds=3,4&excludeIds=6,8 > The elevateIds and excludeIds point to the unique document Id. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842271#comment-13842271 ] Mark Miller commented on SOLR-1632: --- [~markus17], how was performance with your most recent patch compared to what you first reported? > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 5.0, 4.7 > > Attachments: 3x_SOLR-1632_doesntwork.patch, SOLR-1301.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > distrib-2.patch, distrib.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-1632) Distributed IDF
[ https://issues.apache.org/jira/browse/SOLR-1632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-1632: -- Attachment: SOLR-1301.patch This patch remove the new thread local by piggy backing on the existing thread local Solr uses for a request (which is already nicely cleaned up per request). I also attempted to make ExactStatsCache thread safe, but the whole design there needs a review I think. LRUStatsCache is certainly still not thread safe and needs to be fixed. > Distributed IDF > --- > > Key: SOLR-1632 > URL: https://issues.apache.org/jira/browse/SOLR-1632 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.5 >Reporter: Andrzej Bialecki >Assignee: Mark Miller > Fix For: 5.0, 4.7 > > Attachments: 3x_SOLR-1632_doesntwork.patch, SOLR-1301.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, SOLR-1632.patch, > distrib-2.patch, distrib.patch > > > Distributed IDF is a valuable enhancement for distributed search across > non-uniform shards. This issue tracks the proposed implementation of an API > to support this functionality in Solr. -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5357) Upgrade StandardTokenizer & co to latest unicode rules
[
https://issues.apache.org/jira/browse/LUCENE-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842265#comment-13842265
]
Robert Muir commented on LUCENE-5357:
-
{quote}
About back-compat: none of the JFlex-based tokenizers on trunk have
version-based behavior at this point, in contrast to branch_4x
{quote}
I would love if all these constants/parameters were completely removed in
trunk. if you look at the mailing lists, its obvious that users dont even
understand it at all. I dont know how index back compat got perverted into such
a thing that made all the analysis apis ugly and overcomplicated.
This stuff all hurts the project far more than any benefit it brings to the
rare few that understand it. I think it should be removed everywhere.
> Upgrade StandardTokenizer & co to latest unicode rules
> --
>
> Key: LUCENE-5357
> URL: https://issues.apache.org/jira/browse/LUCENE-5357
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/analysis
>Reporter: Robert Muir
>Assignee: Steve Rowe
> Fix For: 5.0, 4.7
>
> Attachments: LUCENE-5357.patch
>
>
> besides any change in data, the rules have also changed (regional indicators,
> better handling for hebrew, etc)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4963) Deprecate broken TokenFilter constructors
[
https://issues.apache.org/jira/browse/LUCENE-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842249#comment-13842249
]
Adrien Grand commented on LUCENE-4963:
--
The way to generate a query based on the token stream of the query string is
the responsibility of the query parser. For example, QueryParserBase has the
{{setEnablePositionIncrements}} method
http://lucene.apache.org/core/4_4_0/queryparser/org/apache/lucene/queryparser/classic/QueryParserBase.html#setEnablePositionIncrements(boolean)
which can be used to ignore holes in the token stream (which seems to be what
you are looking for).
> Deprecate broken TokenFilter constructors
> -
>
> Key: LUCENE-4963
> URL: https://issues.apache.org/jira/browse/LUCENE-4963
> Project: Lucene - Core
> Issue Type: Improvement
>Reporter: Adrien Grand
>Assignee: Adrien Grand
> Fix For: 4.4
>
> Attachments: LUCENE-4963.patch
>
>
> We have some TokenFilters which are only broken with specific options. This
> includes:
> * TrimFilter when updateOffsets=true
> * StopFilter, JapanesePartOfSpeechStopFilter, KeepWordFilter, LengthFilter,
> TypeTokenFilter when enablePositionIncrements=false
> I think we should deprecate these behaviors in 4.4 and remove them in trunk.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5364) Review usages of hard-coded Version constants
[
https://issues.apache.org/jira/browse/LUCENE-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5364:
---
Attachment: LUCENE-5364-trunk.patch
Patch for trunk.
I've added a comment above hard-coded versions that should be updated after a
release:
{code:java}
// :Post-Release-Update-Version.LUCENE_XY:
{code}
I'll make a separate branch_4x patch.
> Review usages of hard-coded Version constants
> -
>
> Key: LUCENE-5364
> URL: https://issues.apache.org/jira/browse/LUCENE-5364
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/other
>Affects Versions: 5.0, 4.7
>Reporter: Steve Rowe
>Priority: Minor
> Attachments: LUCENE-5364-trunk.patch
>
>
> There are some hard-coded {{Version.LUCENE_XY}} constants used in various
> places. Some of these are intentional and appropriate:
> * in deprecated code, e.g. {{ArabicLetterTokenizer}}, deprecated in 3.1, uses
> {{Version.LUCENE_31}}
> * to make behavior version-dependent (e.g. {{StandardTokenizer}} and other
> analysis components)
> * to test different behavior at different points in history (e.g.
> {{TestStopFilter}} to test position increments)
> But should hard-coded constants be used elsewhere?
> For those that should remain, and need to be updated with each release, there
> should be an easy way to find them.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5364) Review usages of hard-coded Version constants
[
https://issues.apache.org/jira/browse/LUCENE-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated LUCENE-5364:
---
Description:
There are some hard-coded {{Version.LUCENE_XY}} constants used in various
places. Some of these are intentional and appropriate:
* in deprecated code, e.g. {{ArabicLetterTokenizer}}, deprecated in 3.1, uses
{{Version.LUCENE_31}}
* to make behavior version-dependent (e.g. {{StandardTokenizer}} and other
analysis components)
* to test different behavior at different points in history (e.g.
{{TestStopFilter}} to test position increments)
But should hard-coded constants be used elsewhere?
For those that should remain, and need to be updated with each release, there
should be an easy way to find them.
was:
There are some hard-coded {{Version.LUCENE_XY}} constants used in various
places. Some of these are intentional and appropriate:
* in deprecated code, e.g. {{ArabicLetterTokenizer}}, deprecated in 3.1, uses
{{Version.LUCENE_31}}
* to make behavior version-dependent (e.g. {{StandardTokenizer}} and other
analysis components)
* to test different behavior at different points in history (e.g.
{{TestStopFilter}} to test position increments)
But should hard-coded constants be used elsewhere? Here are non-deprecated,
non-version-dependent-behavior cases that I found:
# {{Version.LUCENE_46}} is used in
{{lucene/suggest/src/java/org/apache/lucene/search/suggest/analyzing/FreeTextSuggester.java}}.
Mike McCandless said on #lucene-dev IRC that this should use the latest
version (i.e. {{Version.LUCENE_CURRENT}}).
# {{Version.LUCENE_40}} is used in
{{lucene/analysis/common/src/test/org/apache/lucene/analysis/core/TestStopAnalyzer.java}}.
I think this should be {{Version.TEST_VERSION_CURRENT}}.
# {{Version.LUCENE_40}} is used in {{testEndStopWord()}} in
{{lucene/analysis/common/src/test/org/apache/lucene/analysis/core/TestStopAnalyzer.java}}.
I think this should be changed to {{Version.TEST_VERSION_CURRENT}}, since,
unlike other {{Version}} constants used on branch_4x in this test class, no
version-dependent behavior is intended.
# {{Version.LUCENE_40}} is used in
{{lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/htmlentity.py}},
which generates {{HTMLCharacterEntities.flex}}, which is used by
{{HTMLStripCharFilter}}. This should be {{Version.LUCENE_CURRENT}}.
# {{Version.LUCENE_40}} is used in
{{lucene/analysis/common/src/java/org/apache/lucene/analysis/charfilter/HTMLStripCharFilter.jflex}},
which generates {{HTMLStripCharFilter.java}}. This should be
{{Version.LUCENE_CURRENT}}.
# {{Version.LUCENE_40}} is used in {{testStopList()}} in
{{lucene/analysis/common/src/test/org/apache/lucene/analysis/core/TestStopAnalyzer.java}}.
I think it should be {{Version.TEST_VERSION_CURRENT}}.
# {{Version.LUCENE_31}} is used to instantiate a bunch of {{CharArraySet}}-s in
{{/Users/sarowe/svn/lucene/dev/branches/branch_4x/lucene/analysis/common/src/java/org/apache/lucene/analysis/el/GreekStemmer.java}}.
I think these should be {{Version.LUCENE_CURRENT}}.
This is a partial list - I'll add more later.
> Review usages of hard-coded Version constants
> -
>
> Key: LUCENE-5364
> URL: https://issues.apache.org/jira/browse/LUCENE-5364
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/other
>Affects Versions: 5.0, 4.7
>Reporter: Steve Rowe
>Priority: Minor
>
> There are some hard-coded {{Version.LUCENE_XY}} constants used in various
> places. Some of these are intentional and appropriate:
> * in deprecated code, e.g. {{ArabicLetterTokenizer}}, deprecated in 3.1, uses
> {{Version.LUCENE_31}}
> * to make behavior version-dependent (e.g. {{StandardTokenizer}} and other
> analysis components)
> * to test different behavior at different points in history (e.g.
> {{TestStopFilter}} to test position increments)
> But should hard-coded constants be used elsewhere?
> For those that should remain, and need to be updated with each release, there
> should be an easy way to find them.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5357) Upgrade StandardTokenizer & co to latest unicode rules
[ https://issues.apache.org/jira/browse/LUCENE-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842206#comment-13842206 ] Steve Rowe commented on LUCENE-5357: No problem Robert, thanks for taking a look. About back-compat: none of the JFlex-based tokenizers on trunk have version-based behavior at this point, in contrast to branch_4x. It could be argued that that was because all previous back-compat version were for 3.X, but this issue introduced a 4.0 version, which puts it within the version X-1 window for trunk/5.0. Should I forward-port the 4.0 back-compat stuff from branch_4x for StandardTokenizer and UAX29URLEmailTokenizer? There are other analysis components on trunk that do different things based on version, so clearly the practice has not been abandoned on trunk. > Upgrade StandardTokenizer & co to latest unicode rules > -- > > Key: LUCENE-5357 > URL: https://issues.apache.org/jira/browse/LUCENE-5357 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Reporter: Robert Muir >Assignee: Steve Rowe > Fix For: 5.0, 4.7 > > Attachments: LUCENE-5357.patch > > > besides any change in data, the rules have also changed (regional indicators, > better handling for hebrew, etc) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1548830 - /lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFSLockFactory.java
OK! thanks for the fix! On Sat, Dec 7, 2013 at 7:21 PM, Uwe Schindler wrote: > Hi Han, > > I committed an even better fix for this, using the native javadocs linking > instead of an HTML link. By that its automatically also correct in > branch_4x (where the docs have to go to Java 6 SE javadocs). > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -Original Message- > > From: h...@apache.org [mailto:h...@apache.org] > > Sent: Saturday, December 07, 2013 11:34 AM > > To: comm...@lucene.apache.org > > Subject: svn commit: r1548830 - > > /lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleF > > SLockFactory.java > > > > Author: han > > Date: Sat Dec 7 10:34:21 2013 > > New Revision: 1548830 > > > > URL: http://svn.apache.org/r1548830 > > Log: > > broken link police > > > > Modified: > > > > lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFS > > LockFactory.java > > > > Modified: > > lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFS > > LockFactory.java > > URL: > > http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/ > > apache/lucene/store/SimpleFSLockFactory.java?rev=1548830&r1=1548829&r > > 2=1548830&view=diff > > == > > > > --- > > lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFS > > LockFactory.java (original) > > +++ > > lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFS > > LockFactory.java Sat Dec 7 10:34:21 2013 > > @@ -25,7 +25,7 @@ import java.io.IOException; > > * File#createNewFile()}. > > * > > * NOTE: the > - * > > href=" > http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#createNew > > File()">javadocs > > + * > > href=" > http://docs.oracle.com/javase/7/docs/api/java/io/File.html#createNe > > wFile()">javadocs > > * for File.createNewFile contain a vague > > * yet spooky warning about not using the API for file > > * locking. This warning was added due to > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Han Jiang Team of Search Engine and Web Mining, School of Electronic Engineering and Computer Science, Peking University, China
[jira] [Comment Edited] (LUCENE-5350) Add Context Aware Suggester
[
https://issues.apache.org/jira/browse/LUCENE-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842194#comment-13842194
]
Areek Zillur edited comment on LUCENE-5350 at 12/7/13 11:43 AM:
The Benchmark results (similar format to LookupBenchmark results) were as
follows:
{code}
-- input stats
Input size: 53022, numContexts: 2666, Avg. Input/Context: 20
-- construction time
AnalyzingSuggester input: 53022, time[ms]: 10140 [+- 149.13]
ContextAwareAnalyzingSuggester input: 53022, time[ms]: 1683 [+- 17.54]
-- RAM consumption
AnalyzingSuggester size[B]:4,675,508
ContextAwareAnalyzingSuggester size[B]:4,837,187
-- prefixes: 6-9, num: 7, onlyMorePopular: false
ContextAwareAnalyzingSuggester queries: 53022, time[ms]: 1277 [+- 14.67],
~kQPS: 42
AnalyzingSuggester queries: 53022, time[ms]: 2269 [+- 152.00], ~kQPS: 23
-- prefixes: 2-4, num: 7, onlyMorePopular: false
ContextAwareAnalyzingSuggester queries: 53022, time[ms]: 2294 [+- 24.02],
~kQPS: 23
AnalyzingSuggester queries: 53022, time[ms]: 4947 [+- 90.36], ~kQPS: 11
-- prefixes: 100-200, num: 7, onlyMorePopular: false
ContextAwareAnalyzingSuggester queries: 53022, time[ms]: 1177 [+- 32.13],
~kQPS: 45
AnalyzingSuggester queries: 53022, time[ms]: 935 [+- 11.53], ~kQPS: 57
{code}
>From the results it seems
ContextAwaresuggester compared to AnalyzingSuggester:
- is 6 times faster for construction
- consumes ~3% more RAM (duplication in context [prefix and in payload]?)
- has ~ 2 times the QPS [for prefixes 6-9 & 2-4]
- has 20% less QPS [for prefix 100-200]
It is to be noted that the dataset only contains terms with one context (hence
the benchmark does not take into account terms with multiple contexts).
This was an interesting benchmark, thoughts?
was (Author: areek):
The Benchmark results (similar format to LookupBenchmark results) were as
follows:
{code}
-- input stats
Input size: 53022, numContexts: 2666, Avg. Input/Context: 20
-- construction time
AnalyzingSuggester input: 53022, time[ms]: 10140 [+- 149.13]
ContextAwareAnalyzingSuggester input: 53022, time[ms]: 1683 [+- 17.54]
-- RAM consumption
AnalyzingSuggester size[B]:4,675,508
ContextAwareAnalyzingSuggester size[B]:4,837,187
-- prefixes: 6-9, num: 7, onlyMorePopular: false
ContextAwareAnalyzingSuggester queries: 53022, time[ms]: 1277 [+- 14.67],
~kQPS: 42
AnalyzingSuggester queries: 53022, time[ms]: 2269 [+- 152.00], ~kQPS: 23
-- prefixes: 2-4, num: 7, onlyMorePopular: false
ContextAwareAnalyzingSuggester queries: 53022, time[ms]: 2294 [+- 24.02],
~kQPS: 23
AnalyzingSuggester queries: 53022, time[ms]: 4947 [+- 90.36], ~kQPS: 11
-- prefixes: 100-200, num: 7, onlyMorePopular: false
ContextAwareAnalyzingSuggester queries: 53022, time[ms]: 1177 [+- 32.13],
~kQPS: 45
AnalyzingSuggester queries: 53022, time[ms]: 935 [+- 11.53], ~kQPS: 57
{code}
>From the results it seems
ContextAwaresuggester compared to AnalyzingSuggester:
- is 6 times faster for construction
- consumes ~3% more RAM
- has ~ 2 times the QPS [for prefixes 6-9 & 2-4]
- has 20% less QPS [for prefix 100-200]
It is to be noted that the dataset only contains terms with one context (hence
the benchmark does not take into account terms with multiple contexts).
This was an interesting benchmark, thoughts?
> Add Context Aware Suggester
> ---
>
> Key: LUCENE-5350
> URL: https://issues.apache.org/jira/browse/LUCENE-5350
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/search
>Reporter: Areek Zillur
> Fix For: 5.0, 4.7
>
> Attachments: LUCENE-5350-benchmark.patch, LUCENE-5350.patch
>
>
> It would be nice to have a Context Aware Suggester (i.e. a suggester that
> could return suggestions depending on some specified context(s)).
> Use-cases:
> - location-based suggestions:
> -- returns suggestions which 'match' the context of a particular area
> --- suggest restaurants names which are in Palo Alto (context ->
> Palo Alto)
> - category-based suggestions:
> -- returns suggestions for items that are only in certain
> categories/genres (contexts)
> --- suggest movies that are of the genre sci-fi and adventure
> (context -> [sci-fi, adventure])
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5350) Add Context Aware Suggester
[
https://issues.apache.org/jira/browse/LUCENE-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842194#comment-13842194
]
Areek Zillur commented on LUCENE-5350:
--
The Benchmark results (similar format to LookupBenchmark results) were as
follows:
{code}
-- input stats
Input size: 53022, numContexts: 2666, Avg. Input/Context: 20
-- construction time
AnalyzingSuggester input: 53022, time[ms]: 10140 [+- 149.13]
ContextAwareAnalyzingSuggester input: 53022, time[ms]: 1683 [+- 17.54]
-- RAM consumption
AnalyzingSuggester size[B]:4,675,508
ContextAwareAnalyzingSuggester size[B]:4,837,187
-- prefixes: 6-9, num: 7, onlyMorePopular: false
ContextAwareAnalyzingSuggester queries: 53022, time[ms]: 1277 [+- 14.67],
~kQPS: 42
AnalyzingSuggester queries: 53022, time[ms]: 2269 [+- 152.00], ~kQPS: 23
-- prefixes: 2-4, num: 7, onlyMorePopular: false
ContextAwareAnalyzingSuggester queries: 53022, time[ms]: 2294 [+- 24.02],
~kQPS: 23
AnalyzingSuggester queries: 53022, time[ms]: 4947 [+- 90.36], ~kQPS: 11
-- prefixes: 100-200, num: 7, onlyMorePopular: false
ContextAwareAnalyzingSuggester queries: 53022, time[ms]: 1177 [+- 32.13],
~kQPS: 45
AnalyzingSuggester queries: 53022, time[ms]: 935 [+- 11.53], ~kQPS: 57
{code}
>From the results it seems
ContextAwaresuggester compared to AnalyzingSuggester:
- is 6 times faster for construction
- consumes ~3% more RAM
- has ~ 2 times the QPS [for prefixes 6-9 & 2-4]
- has 20% less QPS [for prefix 100-200]
It is to be noted that the dataset only contains terms with one context (hence
the benchmark does not take into account terms with multiple contexts).
This was an interesting benchmark, thoughts?
> Add Context Aware Suggester
> ---
>
> Key: LUCENE-5350
> URL: https://issues.apache.org/jira/browse/LUCENE-5350
> Project: Lucene - Core
> Issue Type: New Feature
> Components: core/search
>Reporter: Areek Zillur
> Fix For: 5.0, 4.7
>
> Attachments: LUCENE-5350-benchmark.patch, LUCENE-5350.patch
>
>
> It would be nice to have a Context Aware Suggester (i.e. a suggester that
> could return suggestions depending on some specified context(s)).
> Use-cases:
> - location-based suggestions:
> -- returns suggestions which 'match' the context of a particular area
> --- suggest restaurants names which are in Palo Alto (context ->
> Palo Alto)
> - category-based suggestions:
> -- returns suggestions for items that are only in certain
> categories/genres (contexts)
> --- suggest movies that are of the genre sci-fi and adventure
> (context -> [sci-fi, adventure])
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5350) Add Context Aware Suggester
[ https://issues.apache.org/jira/browse/LUCENE-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13842190#comment-13842190 ] Areek Zillur edited comment on LUCENE-5350 at 12/7/13 11:25 AM: Uploaded benchmark code and data for ContextAware suggester. It compares a single ContextAwareSuggester with N analyzing suggester (each with different context). The original dataset was taken from http://snap.stanford.edu/data/web-Reddit.html. The processed dataset contains only three fields: - title (suggestion) - subreddit (context) - unixtime (weight) was (Author: areek): Uploaded benchmark code and data for ContextAware suggester. It compares a single ContextAwareSuggester with N analyzing suggester (each with different context). The original dataset was taken from http://snap.stanford.edu/data/web-Reddit.html. The processed dataset contains only three fields: - title (suggestion) - context (subreddit) - unixtime (weight) > Add Context Aware Suggester > --- > > Key: LUCENE-5350 > URL: https://issues.apache.org/jira/browse/LUCENE-5350 > Project: Lucene - Core > Issue Type: New Feature > Components: core/search >Reporter: Areek Zillur > Fix For: 5.0, 4.7 > > Attachments: LUCENE-5350-benchmark.patch, LUCENE-5350.patch > > > It would be nice to have a Context Aware Suggester (i.e. a suggester that > could return suggestions depending on some specified context(s)). > Use-cases: > - location-based suggestions: > -- returns suggestions which 'match' the context of a particular area > --- suggest restaurants names which are in Palo Alto (context -> > Palo Alto) > - category-based suggestions: > -- returns suggestions for items that are only in certain > categories/genres (contexts) > --- suggest movies that are of the genre sci-fi and adventure > (context -> [sci-fi, adventure]) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5350) Add Context Aware Suggester
[ https://issues.apache.org/jira/browse/LUCENE-5350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Areek Zillur updated LUCENE-5350: - Attachment: LUCENE-5350-benchmark.patch Uploaded benchmark code and data for ContextAware suggester. It compares a single ContextAwareSuggester with N analyzing suggester (each with different context). The original dataset was taken from http://snap.stanford.edu/data/web-Reddit.html. The processed dataset contains only three fields: - title (suggestion) - context (subreddit) - unixtime (weight) > Add Context Aware Suggester > --- > > Key: LUCENE-5350 > URL: https://issues.apache.org/jira/browse/LUCENE-5350 > Project: Lucene - Core > Issue Type: New Feature > Components: core/search >Reporter: Areek Zillur > Fix For: 5.0, 4.7 > > Attachments: LUCENE-5350-benchmark.patch, LUCENE-5350.patch > > > It would be nice to have a Context Aware Suggester (i.e. a suggester that > could return suggestions depending on some specified context(s)). > Use-cases: > - location-based suggestions: > -- returns suggestions which 'match' the context of a particular area > --- suggest restaurants names which are in Palo Alto (context -> > Palo Alto) > - category-based suggestions: > -- returns suggestions for items that are only in certain > categories/genres (contexts) > --- suggest movies that are of the genre sci-fi and adventure > (context -> [sci-fi, adventure]) -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: svn commit: r1548830 - /lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFSLockFactory.java
Hi Han, I committed an even better fix for this, using the native javadocs linking instead of an HTML link. By that its automatically also correct in branch_4x (where the docs have to go to Java 6 SE javadocs). Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: h...@apache.org [mailto:h...@apache.org] > Sent: Saturday, December 07, 2013 11:34 AM > To: comm...@lucene.apache.org > Subject: svn commit: r1548830 - > /lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleF > SLockFactory.java > > Author: han > Date: Sat Dec 7 10:34:21 2013 > New Revision: 1548830 > > URL: http://svn.apache.org/r1548830 > Log: > broken link police > > Modified: > > lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFS > LockFactory.java > > Modified: > lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFS > LockFactory.java > URL: > http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/core/src/java/org/ > apache/lucene/store/SimpleFSLockFactory.java?rev=1548830&r1=1548829&r > 2=1548830&view=diff > == > > --- > lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFS > LockFactory.java (original) > +++ > lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/SimpleFS > LockFactory.java Sat Dec 7 10:34:21 2013 > @@ -25,7 +25,7 @@ import java.io.IOException; > * File#createNewFile()}. > * > * NOTE: the - * > href="http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#createNew > File()">javadocs > + * > href="http://docs.oracle.com/javase/7/docs/api/java/io/File.html#createNe > wFile()">javadocs > * for File.createNewFile contain a vague > * yet spooky warning about not using the API for file > * locking. This warning was added due to
[jira] [Updated] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd
[ https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Binda updated LUCENE-5365: -- Priority: Minor (was: Trivial) > Typo with QueryNodeOperation.logicalAnd > --- > > Key: LUCENE-5365 > URL: https://issues.apache.org/jira/browse/LUCENE-5365 > Project: Lucene - Core > Issue Type: Bug > Components: core/queryparser >Affects Versions: 4.6, 5.0, 4.7 >Reporter: Olivier Binda >Priority: Minor > Attachments: typo.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd > -> a boolean condition is always false > Which means that A and B fails when A is not an ANDQueryNode and B is -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd
[ https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Binda updated LUCENE-5365: -- Affects Version/s: 4.6 > Typo with QueryNodeOperation.logicalAnd > --- > > Key: LUCENE-5365 > URL: https://issues.apache.org/jira/browse/LUCENE-5365 > Project: Lucene - Core > Issue Type: Bug > Components: core/queryparser >Affects Versions: 4.6, 5.0, 4.7 >Reporter: Olivier Binda >Priority: Trivial > Attachments: typo.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd > -> a boolean condition is always false > Which means that A and B fails when A is not an ANDQueryNode and B is -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd
[ https://issues.apache.org/jira/browse/LUCENE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Binda updated LUCENE-5365: -- Attachment: typo.patch > Typo with QueryNodeOperation.logicalAnd > --- > > Key: LUCENE-5365 > URL: https://issues.apache.org/jira/browse/LUCENE-5365 > Project: Lucene - Core > Issue Type: Bug > Components: core/queryparser >Affects Versions: 5.0, 4.7 >Reporter: Olivier Binda >Priority: Trivial > Attachments: typo.patch > > Original Estimate: 1m > Remaining Estimate: 1m > > Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd > -> a boolean condition is always false > Which means that A and B fails when A is not an ANDQueryNode and B is -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5365) Typo with QueryNodeOperation.logicalAnd
Olivier Binda created LUCENE-5365: - Summary: Typo with QueryNodeOperation.logicalAnd Key: LUCENE-5365 URL: https://issues.apache.org/jira/browse/LUCENE-5365 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 5.0, 4.7 Reporter: Olivier Binda Priority: Trivial Intellij IDEA finds a bug/typo in QueryNodeOperation.logicalAnd -> a boolean condition is always false Which means that A and B fails when A is not an ANDQueryNode and B is -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java7 - Build # 4523 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java7/4523/ All tests passed Build Log: [...truncated 57639 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/build.xml:420: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/build.xml:359: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/extra-targets.xml:87: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-Java7/extra-targets.xml:158: The following files are missing svn:eol-style (or binary svn:mime-type): * ./solr/licenses/cdk-morphlines-avro-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-core-0.9.0-tests.jar.sha1 * ./solr/licenses/cdk-morphlines-core-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-hadoop-sequencefile-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-json-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-saxon-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-tika-core-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-tika-decompress-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-twitter-0.9.0.jar.sha1 Total time: 123 minutes 31 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_45) - Build # 8602 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8602/ Java: 32bit/jdk1.7.0_45 -server -XX:+UseG1GC All tests passed Build Log: [...truncated 50500 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:420: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:359: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:87: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:158: The following files are missing svn:eol-style (or binary svn:mime-type): * ./solr/licenses/cdk-morphlines-avro-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-core-0.9.0-tests.jar.sha1 * ./solr/licenses/cdk-morphlines-core-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-hadoop-sequencefile-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-json-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-saxon-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-tika-core-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-tika-decompress-0.9.0.jar.sha1 * ./solr/licenses/cdk-morphlines-twitter-0.9.0.jar.sha1 Total time: 60 minutes 36 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.7.0_45 -server -XX:+UseG1GC Archiving artifacts Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
