[jira] [Created] (SOLR-4774) Solr support Lucene Facets

[Bill Bell (JIRA)]

Bill Bell created SOLR-4774:
---

 Summary: Solr support Lucene Facets
 Key: SOLR-4774
 URL: https://issues.apache.org/jira/browse/SOLR-4774
 Project: Solr
  Issue Type: Bug
Reporter: Bill Bell


Since facets are now included in Lucene... 

1. Solr schema taxonomy glue
2. Switch query results to use this glue with a new param like 
facet.lucene=true?

Seems like a great enhancement !


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
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_21) - Build # 5399 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5399/
Java: 32bit/jdk1.7.0_21 -server -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 30271 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:378: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:317: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:120: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* solr/example/solr/collection1/conf/velocity/README.txt
* solr/example/solr/collection1/conf/velocity/error.vm
* solr/example/solr/collection1/conf/velocity/hit_plain.vm
* solr/example/solr/collection1/conf/velocity/mime_type_lists.vm
* solr/example/solr/collection1/conf/velocity/pagination_bottom.vm
* solr/example/solr/collection1/conf/velocity/pagination_top.vm
* solr/example/solr/collection1/conf/velocity/query_form.vm
* solr/example/solr/collection1/conf/velocity/results_list.vm

Total time: 42 minutes 10 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.7.0_21 -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

[jira] [Commented] (SOLR-2242) Get distinct count of names for a facet field

[Bill Bell (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-2242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644287#comment-13644287
 ] 

Bill Bell commented on SOLR-2242:
-

Yeah. This issue has stalled. To get it ready for release we just need to apply 
the patch and run all unit tests. 

Issues tend to stall when we don't have a commiter leading the work to get 
done. If someone will step up I will commit to do the work. the last time I 
made a push for this there was several approaches:

1. Change the facet formats (Yonik)
2. Change the parameter names and hide the fact that we are looping through all 
(limit=-1).
3. Try to get the sharding working. Although I would contend that we can 
release without sharding and add it later. Sharding - we can send the unique 
terms and combine to get exact numbers, or we can separate and send (as it is 
now). The former is much harder to do and could cause perf issues.

Thoughts? Maybe at the Lucene conference this can be discussed?


> Get distinct count of names for a facet field
> -
>
> Key: SOLR-2242
> URL: https://issues.apache.org/jira/browse/SOLR-2242
> Project: Solr
>  Issue Type: New Feature
>  Components: Response Writers
>Affects Versions: 4.0-ALPHA
>Reporter: Bill Bell
>Priority: Minor
> Fix For: 4.3
>
> Attachments: SOLR-2242-3x_5_tests.patch, SOLR-2242-3x.patch, 
> SOLR-2242.patch, SOLR-2242.patch, SOLR-2242.patch, 
> SOLR-2242.shard.withtests.patch, SOLR-2242.solr3.1-fix.patch, 
> SOLR-2242.solr3.1.patch, SOLR.2242.solr3.1.patch, SOLR-2242-solr40-3.patch
>
>
> When returning facet.field= you will get a list of matches for 
> distinct values. This is normal behavior. This patch tells you how many 
> distinct values you have (# of rows). Use with limit=-1 and mincount=1.
> The feature is called "namedistinct". Here is an example:
> Parameters:
> facet.numTerms or f..facet.numTerms = true (default is false) - turn 
> on distinct counting of terms
> facet.field - the field to count the terms
> It creates a new section in the facet section...
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=true&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=false&facet.limit=-1&facet.field=price
> http://localhost:8983/solr/select?shards=localhost:8983/solr,localhost:7574/solr&indent=true&q=*:*&facet=true&facet.mincount=1&facet.numTerms=true&facet.limit=-1&facet.field=price
> This currently only works on facet.field.
> {code}
> 
> 
> ...
> 
> 
> 14
> 
> 
> 14
> 
> 
> 
> 
> 
> OR with no sharding-
> 
> 14
> 
> {code} 
> Several people use this to get the group.field count (the # of groups).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries

[SooMyung Lee (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644282#comment-13644282
 ] 

SooMyung Lee commented on LUCENE-4956:
--

Hi Steve and Christian, What should I do in the present situation, Do I need to 
make a correction to all issues and submit new tarball? Please let me know what 
I have to do to move forward!

> the korean analyzer that has a korean morphological analyzer and dictionaries
> -
>
> Key: LUCENE-4956
> URL: https://issues.apache.org/jira/browse/LUCENE-4956
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.2
>Reporter: SooMyung Lee
>  Labels: newbie
> Attachments: kr.analyzer.4x.tar
>
>
> Korean language has specific characteristic. When developing search service 
> with lucene & solr in korean, there are some problems in searching and 
> indexing. The korean analyer solved the problems with a korean morphological 
> anlyzer. It consists of a korean morphological analyzer, dictionaries, a 
> korean tokenizer and a korean filter. The korean anlyzer is made for lucene 
> and solr. If you develop a search service with lucene in korean, It is the 
> best idea to choose the korean analyzer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-4685) JSON response write modification to support RAW JSON

[Bill Bell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bill Bell reassigned SOLR-4685:
---

Assignee: Erik Hatcher

> JSON response write modification to support RAW JSON
> 
>
> Key: SOLR-4685
> URL: https://issues.apache.org/jira/browse/SOLR-4685
> Project: Solr
>  Issue Type: Improvement
>Reporter: Bill Bell
>Assignee: Erik Hatcher
> Attachments: SOLR-4685.1.patch
>
>
> If the field ends with "_json" allow the field to return raw JSON.
> For example the field,
> office_json -- string
> I already put into the field raw JSON already escaped. I want it to come with 
> no double quotes and not escaped.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4965) Add dynamic numeric range faceting

[Shai Erera (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644279#comment-13644279
 ] 

Shai Erera commented on LUCENE-4965:


bq. Ie overlapping ranges should be allowed?

Ahh, you're right.

bq. it's a little tricky to do that since each Range has its own private min/max

Maybe Range can implement Comparable, and you build the tree using it, like we 
build PQ? In practice though, I wonder how much more efficient a tree would be 
vs simply sorting and iterating until a range is bigger than value? We're 
talking probably very few ranges no?

BTW, I think Range would need to implement Comparable as well as 
compareTo(long) since a value may not fall into the first (sorted order) range 
(e.g. range.accept() returns false), but you'll need to continue looking until 
range.compareTo(long) > 0 (i.e. range.minValue > value).

Also, maybe instead of FRN we should return a RangeFRN which contains the 
range? That way, someone can extract the min/max values of the range without 
parsing the label by casting to the range added? Hmm, but then you'll need to 
make the range impls public, but maybe that's not bad? Instead of 
Range.newLongRange, someone will just do {{new LongRange()}}?

I see you decided not to go with generics? In that case, maybe document that 
you are expected to pass the same Range type? Although, why not make 
RangeFacetRequest generic and prevent this pitfall?

> Add dynamic numeric range faceting
> --
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch, 
> LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things 
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc.  But because time is constantly advancing,
> doing this at index time is a not easy ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.6.0_45) - Build # 5343 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5343/
Java: 64bit/jdk1.6.0_45 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 29798 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:384: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:323: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:120: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* solr/example/solr/collection1/conf/velocity/README.txt
* solr/example/solr/collection1/conf/velocity/error.vm
* solr/example/solr/collection1/conf/velocity/hit_plain.vm
* solr/example/solr/collection1/conf/velocity/mime_type_lists.vm
* solr/example/solr/collection1/conf/velocity/pagination_bottom.vm
* solr/example/solr/collection1/conf/velocity/pagination_top.vm
* solr/example/solr/collection1/conf/velocity/query_form.vm
* solr/example/solr/collection1/conf/velocity/results_list.vm

Total time: 49 minutes 54 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.6.0_45 -XX:+UseCompressedOops 
-XX:+UseConcMarkSweepGC
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 (64bit/jdk1.7.0_21) - Build # 5398 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5398/
Java: 64bit/jdk1.7.0_21 -XX:+UseCompressedOops -XX:+UseSerialGC

All tests passed

Build Log:
[...truncated 33412 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:378: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:317: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:120: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* solr/example/solr/collection1/conf/velocity/README.txt
* solr/example/solr/collection1/conf/velocity/error.vm
* solr/example/solr/collection1/conf/velocity/hit_plain.vm
* solr/example/solr/collection1/conf/velocity/mime_type_lists.vm
* solr/example/solr/collection1/conf/velocity/pagination_bottom.vm
* solr/example/solr/collection1/conf/velocity/pagination_top.vm
* solr/example/solr/collection1/conf/velocity/query_form.vm
* solr/example/solr/collection1/conf/velocity/results_list.vm

Total time: 47 minutes 33 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 64bit/jdk1.7.0_21 -XX:+UseCompressedOops -XX:+UseSerialGC
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-Tests-trunk-java7 - Build # 3940 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-java7/3940/

All tests passed

Build Log:
[...truncated 33618 lines...]
BUILD FAILED
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/build.xml:378:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/build.xml:317:
 The following error occurred while executing this line:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/extra-targets.xml:120:
 The following files are missing svn:eol-style (or binary svn:mime-type):
* solr/example/solr/collection1/conf/velocity/README.txt
* solr/example/solr/collection1/conf/velocity/error.vm
* solr/example/solr/collection1/conf/velocity/hit_plain.vm
* solr/example/solr/collection1/conf/velocity/mime_type_lists.vm
* solr/example/solr/collection1/conf/velocity/pagination_bottom.vm
* solr/example/solr/collection1/conf/velocity/pagination_top.vm
* solr/example/solr/collection1/conf/velocity/query_form.vm
* solr/example/solr/collection1/conf/velocity/results_list.vm

Total time: 69 minutes 15 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-4.x-Linux (32bit/jdk1.7.0_21) - Build # 5340 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5340/
Java: 32bit/jdk1.7.0_21 -server -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 30512 lines...]
BUILD FAILED
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:384: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:323: The following 
error occurred while executing this line:
/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:120: The 
following files are missing svn:eol-style (or binary svn:mime-type):
* solr/example/solr/collection1/conf/velocity/README.txt
* solr/example/solr/collection1/conf/velocity/error.vm
* solr/example/solr/collection1/conf/velocity/hit_plain.vm
* solr/example/solr/collection1/conf/velocity/mime_type_lists.vm
* solr/example/solr/collection1/conf/velocity/pagination_bottom.vm
* solr/example/solr/collection1/conf/velocity/pagination_top.vm
* solr/example/solr/collection1/conf/velocity/query_form.vm
* solr/example/solr/collection1/conf/velocity/results_list.vm

Total time: 48 minutes 46 seconds
Build step 'Invoke Ant' marked build as failure
Description set: Java: 32bit/jdk1.7.0_21 -server -XX:+UseConcMarkSweepGC
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

[jira] [Resolved] (SOLR-4759) Cleanup Velocity Templates

[Erik Hatcher (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erik Hatcher resolved SOLR-4759.


   Resolution: Fixed
Fix Version/s: 4.4
   5.0
 Assignee: Erik Hatcher

Committed to both 4x and trunk.  There were a couple of differences in Mark's 
patch and what I committed with a couple of typo/spelling corrections, updated 
README, and left the JQuery file names as-is rather than rename them to stay 
with the same names that of those 3rd party files.

> Cleanup Velocity Templates
> --
>
> Key: SOLR-4759
> URL: https://issues.apache.org/jira/browse/SOLR-4759
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.2
>Reporter: Mark Bennett
>Assignee: Erik Hatcher
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4759.patch, velocity-SOLR-4759.zip
>
>
> Cleanup to Velocity templates shipped under 
> solr/example/solr/collection1/conf/velocity
> * Add README.txt file with complete file list
> * Add comments to all files
> * Add indenting where feasible, fixed indenting in other places.  I don't 
> believe I've broken anything that required precise indenting.
> * Make file naming consistent.  We had this_that, thisThat and this-that
>   Changed all to this_that, though also considered this-that.
> * Modularize some files
> * Included a hit_plain.vm example, though not active by default.
> * Rewrote city/lon/lat selector to work from a hash, though doesn't change 
> the behavior.
> * CSS changes, primarily to make top "tabs" actually look like Tabs 
> (primitive CSS, but at least conveys the idea)
> As far as I know this doesn't change any behavior of the system, nor does it 
> fix any existing bugs.  Although I might do bug fixing in a later patch, I 
> wanted to keep this as a pure "code readability" patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4759) Cleanup Velocity Templates

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644171#comment-13644171
 ] 

Commit Tag Bot commented on SOLR-4759:
--

[trunk commit] ehatcher
http://svn.apache.org/viewvc?view=revision&revision=1476858

SOLR-4759: Velocity template cleanup

> Cleanup Velocity Templates
> --
>
> Key: SOLR-4759
> URL: https://issues.apache.org/jira/browse/SOLR-4759
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.2
>Reporter: Mark Bennett
> Attachments: SOLR-4759.patch, velocity-SOLR-4759.zip
>
>
> Cleanup to Velocity templates shipped under 
> solr/example/solr/collection1/conf/velocity
> * Add README.txt file with complete file list
> * Add comments to all files
> * Add indenting where feasible, fixed indenting in other places.  I don't 
> believe I've broken anything that required precise indenting.
> * Make file naming consistent.  We had this_that, thisThat and this-that
>   Changed all to this_that, though also considered this-that.
> * Modularize some files
> * Included a hit_plain.vm example, though not active by default.
> * Rewrote city/lon/lat selector to work from a hash, though doesn't change 
> the behavior.
> * CSS changes, primarily to make top "tabs" actually look like Tabs 
> (primitive CSS, but at least conveys the idea)
> As far as I know this doesn't change any behavior of the system, nor does it 
> fix any existing bugs.  Although I might do bug fixing in a later patch, I 
> wanted to keep this as a pure "code readability" patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4759) Cleanup Velocity Templates

[Commit Tag Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644170#comment-13644170
 ] 

Commit Tag Bot commented on SOLR-4759:
--

[branch_4x commit] ehatcher
http://svn.apache.org/viewvc?view=revision&revision=1476857

SOLR-4759: Velocity template cleanup

> Cleanup Velocity Templates
> --
>
> Key: SOLR-4759
> URL: https://issues.apache.org/jira/browse/SOLR-4759
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.2
>Reporter: Mark Bennett
> Attachments: SOLR-4759.patch, velocity-SOLR-4759.zip
>
>
> Cleanup to Velocity templates shipped under 
> solr/example/solr/collection1/conf/velocity
> * Add README.txt file with complete file list
> * Add comments to all files
> * Add indenting where feasible, fixed indenting in other places.  I don't 
> believe I've broken anything that required precise indenting.
> * Make file naming consistent.  We had this_that, thisThat and this-that
>   Changed all to this_that, though also considered this-that.
> * Modularize some files
> * Included a hit_plain.vm example, though not active by default.
> * Rewrote city/lon/lat selector to work from a hash, though doesn't change 
> the behavior.
> * CSS changes, primarily to make top "tabs" actually look like Tabs 
> (primitive CSS, but at least conveys the idea)
> As far as I know this doesn't change any behavior of the system, nor does it 
> fix any existing bugs.  Although I might do bug fixing in a later patch, I 
> wanted to keep this as a pure "code readability" patch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4967) Absorb NRTManager entirely into a separate reopen thread class

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-4967:
---

Attachment: LUCENE-4967.patch

Patch, I think it's ready.

> Absorb NRTManager entirely into a separate reopen thread class
> --
>
> Key: LUCENE-4967
> URL: https://issues.apache.org/jira/browse/LUCENE-4967
> Project: Lucene - Core
>  Issue Type: Improvement
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4967.patch
>
>
> I think NRTManager can be drastically simplified by moving all of its
> logic into a new reopen thread class.  All logic for waiting for a
> specific generation and reopening at different rates would live in
> this class.
> This would fully decouple the "wait for generation X to be visible"
> from which particular ReferenceManager impl you're using, which would
> make it possible to use the controlled consistency approach of
> NRTManager with any managers (e.g. SearcherTaxonomyManager).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4967) Absorb NRTManager entirely into a separate reopen thread class

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-4967:
--

 Summary: Absorb NRTManager entirely into a separate reopen thread 
class
 Key: LUCENE-4967
 URL: https://issues.apache.org/jira/browse/LUCENE-4967
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
 Fix For: 5.0, 4.4


I think NRTManager can be drastically simplified by moving all of its
logic into a new reopen thread class.  All logic for waiting for a
specific generation and reopening at different rates would live in
this class.

This would fully decouple the "wait for generation X to be visible"
from which particular ReferenceManager impl you're using, which would
make it possible to use the controlled consistency approach of
NRTManager with any managers (e.g. SearcherTaxonomyManager).


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries

[Edward J. Yoon (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644162#comment-13644162
 ] 

Edward J. Yoon commented on LUCENE-4956:


I think this would be a valuable addition to the Apache Lucene (P.S., I'm 
Korean as you may know). 

It would be nice if you can remove all the korean comments or strings, and 
author tags in source code to avoid any compiling and installing problems. 
Otherwise, SVN server/client settings and build-script's encoding options etc. 
will be somewhat tricky. For example, 

{code}
if(entry!=null&&!("을".equals(end)&&entry.getFeature(WordEntry.IDX_REGURA)==IrregularUtil.IRR_TYPE_LIUL))
 {

and, 

/**
 * 복합명사의 개별단어에 대한 정보를 담고있는 클래스 
 * @author S.M.Lee
 *
 */
{code}

> the korean analyzer that has a korean morphological analyzer and dictionaries
> -
>
> Key: LUCENE-4956
> URL: https://issues.apache.org/jira/browse/LUCENE-4956
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.2
>Reporter: SooMyung Lee
>  Labels: newbie
> Attachments: kr.analyzer.4x.tar
>
>
> Korean language has specific characteristic. When developing search service 
> with lucene & solr in korean, there are some problems in searching and 
> indexing. The korean analyer solved the problems with a korean morphological 
> anlyzer. It consists of a korean morphological analyzer, dictionaries, a 
> korean tokenizer and a korean filter. The korean anlyzer is made for lucene 
> and solr. If you develop a search service with lucene in korean, It is the 
> best idea to choose the korean analyzer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 - Failure!

[Michael McCandless]

Ahh sneaky ... this has tripped us up before.  I just committed a fix
to RIW to not doRandomForceMerge when NoMergePolicy is in use.

Thanks Martijn!

Mike McCandless

http://blog.mikemccandless.com


On Sun, Apr 28, 2013 at 4:36 PM, Uwe Schindler  wrote:
> Ah,
>
>
>
> we have other tests that also set nomerge policy. So RandomIndexWriter
> checks what happens if you call forceMerge? This should be a noop for this
> merge policy?
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> H.-H.-Meier-Allee 63, D-28213 Bremen
>
> http://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> From: martijn.is.h...@gmail.com [mailto:martijn.is.h...@gmail.com] On Behalf
> Of Martijn v Groningen
> Sent: Sunday, April 28, 2013 8:34 PM
> To: dev@lucene.apache.org
> Subject: Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build #
> 5334 - Failure!
>
>
>
> I looked into a previous failure of this test and committed a fix for that.
> I think that fix caused this failure. In the fix I use of the NoMergePolicy
> and this seems to break the assert in the
> RandomIndexWriter#doRandomForceMerge() method.
>
>
>
> On 28 April 2013 19:17, Michael McCandless 
> wrote:
>
> I think Martijn is looking into it?
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
>
> On Sun, Apr 28, 2013 at 11:34 AM, Uwe Schindler  wrote:
>> This one reproduces with Oracle JDK 6 or 7, 32 or 64 bit. It is not an J9
>> issue, it's a real bug!
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>>> -Original Message-
>>> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
>>> Sent: Sunday, April 28, 2013 5:19 PM
>>> To: dev@lucene.apache.org; u...@thetaphi.de
>>> Subject: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build #
>>> 5334 -
>>> Failure!
>>>
>>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5334/
>>> Java: 32bit/ibm-j9-jdk6
>>>
>>> 1 tests failed.
>>> REGRESSION:
>>> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting
>>>
>>> Error Message:
>>> limit=2 actual=4
>>>
>>> Stack Trace:
>>> java.lang.AssertionError: limit=2 actual=4
>>>   at
>>> __randomizedtesting.SeedInfo.seed([51EE345C29BF7C40:5907D91D6916712E
>>> ]:0)
>>>   at
>>> org.apache.lucene.index.RandomIndexWriter.doRandomForceMerge(Rando
>>> mIndexWriter.java:293)
>>>   at
>>> org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.jav
>>> a:336)
>>>   at
>>>
>>> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting(TestB
>>> lockJoinSorting.java:212)
>>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>>   at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>>> ava:60)
>>>   at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>>> sorImpl.java:37)
>>>   at java.lang.reflect.Method.invoke(Method.java:611)
>>>   at
>>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
>>> dRunner.java:1559)
>>>   at
>>> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Rando
>>> mizedRunner.java:79)
>>>   at
>>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando
>>> mizedRunner.java:737)
>>>   at
>>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando
>>> mizedRunner.java:773)
>>>   at
>>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
>>> mizedRunner.java:787)
>>>   at
>>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
>>> SetupTeardownChained.java:50)
>>>   at
>>>
>>> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa
>>> cheSanity.java:51)
>>>   at
>>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
>>> fterRule.java:46)
>>>   at
>>> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1
>>> .evaluate(SystemPropertiesInvariantRule.java:55)
>>>   at
>>> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
>>> readAndTestName.java:49)
>>>   at
>>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
>>> IgnoreAfterMaxFailures.java:70)
>>>   at
>>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
>>> .java:48)
>>>   at
>>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
>>> ementAdapter.java:36)
>>>   at
>>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
>>> run(ThreadLeakControl.java:358)
>>>   at
>>> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask
>>> (ThreadLeakControl.java:782)
>>>   at
>>> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL
>>> eakControl.java:442)
>>>   at
>>> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran
>>> domizedRunner.java:746)
>>>   at
>>> com.carrotsearch.randomizedtesting.RandomizedRunn

[jira] [Updated] (LUCENE-4965) Add dynamic numeric range faceting

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-4965:
---

Attachment: LUCENE-4965.patch

Patch w/ last round of fixes...

> Add dynamic numeric range faceting
> --
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch, 
> LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things 
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc.  But because time is constantly advancing,
> doing this at index time is a not easy ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4965) Add dynamic numeric range faceting

[Michael McCandless (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644156#comment-13644156
 ] 

Michael McCandless commented on LUCENE-4965:


bq. Range is not really extendable (private ctor) – is that intentional? I 
guess there's not much point extending it ...

I suppose if an app had some custom encoding (into the long value in 
NumericDVField) then it would need a custom impl?  I'll make it protected...

bq. Any reason why not take primitive values and let the user define e.g 
Long.MAX_VALUE as an unlimited upper bound? 

I was trying to mimic NumericRangeQuery, but I agree: let's just take 
primitives.

bq. Accumulate() iterates at the outer loop on matchingDocs, and inner loop on 
ranges. I remember while writing FacetsAccumulator that luceneutil was happier 
with the other way (matchingDocs inner). Maybe test?

Ahhh right I forgot about that :)  I'll just switch it to inner loop on 
matchingDocs... I'm not quite set up to perf test this yet :)

bq. Shouldn't if (ranges.ranges.accept(v)) break if there's a match

I think not?  Ie overlapping ranges should be allowed?  For Jira search I'd 
like to have "Past day", "Past 2 days", etc.

bq. While at it, maybe RangeSet should sort the ranges by their minimum value? 
Not sure if asymptotically this will matter...

I think we need to use an interval tree here (I put a TODO) ... it's a little 
tricky to do that since each Range has its own private min/max ... but I think 
we can do this in a followon issue.

> Add dynamic numeric range faceting
> --
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch, 
> LUCENE-4965.patch, LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things 
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc.  But because time is constantly advancing,
> doing this at index time is a not easy ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4966) Add CachingWrapperFilter.sizeInBytes()

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-4966:
---

Attachment: LUCENE-4966.patch

Patch.

> Add CachingWrapperFilter.sizeInBytes()
> --
>
> Key: LUCENE-4966
> URL: https://issues.apache.org/jira/browse/LUCENE-4966
> Project: Lucene - Core
>  Issue Type: Improvement
>Affects Versions: 5.0, 4.4
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Attachments: LUCENE-4966.patch
>
>
> I think it's useful to be able to check how much RAM a given CWF is using ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (LUCENE-4966) Add CachingWrapperFilter.sizeInBytes()

[Michael McCandless (JIRA)]

Michael McCandless created LUCENE-4966:
--

 Summary: Add CachingWrapperFilter.sizeInBytes()
 Key: LUCENE-4966
 URL: https://issues.apache.org/jira/browse/LUCENE-4966
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 5.0, 4.4
Reporter: Michael McCandless
Assignee: Michael McCandless
 Attachments: LUCENE-4966.patch

I think it's useful to be able to check how much RAM a given CWF is using ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4773) New discovery mode needs to insure that instanceDir is correct

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-4773:
-

Summary: New discovery mode needs to insure that instanceDir is correct  
(was: New discovery mode needs to insure that instanceDir is a relative path)

> New discovery mode needs to insure that instanceDir is correct
> --
>
> Key: SOLR-4773
> URL: https://issues.apache.org/jira/browse/SOLR-4773
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.0, 4.4
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4773.patch, SOLR-4773.patch
>
>
> Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example 
> fails because we can't find solrconfig. The construction of the instanceDir 
> in SolrCoreDiscoverer constructs a path with an extra solr (e.g. 
> solr/solr/core).
> I'll attach a patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4773) New discovery mode needs to insure that instanceDir is a relative path

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-4773:
-

Attachment: SOLR-4773.patch

Different approach, putting up for comment before committing. Are there any 
good reasons _not_ to use the absolute path for this (legacy) instanceDir 
stuff? This patch uses absolute path here

> New discovery mode needs to insure that instanceDir is a relative path
> --
>
> Key: SOLR-4773
> URL: https://issues.apache.org/jira/browse/SOLR-4773
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.0, 4.4
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4773.patch, SOLR-4773.patch
>
>
> Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example 
> fails because we can't find solrconfig. The construction of the instanceDir 
> in SolrCoreDiscoverer constructs a path with an extra solr (e.g. 
> solr/solr/core).
> I'll attach a patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 - Failure!

[Uwe Schindler]

Ah,

 

we have other tests that also set nomerge policy. So RandomIndexWriter checks 
what happens if you call forceMerge? This should be a noop for this merge 
policy?

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: martijn.is.h...@gmail.com [mailto:martijn.is.h...@gmail.com] On Behalf Of 
Martijn v Groningen
Sent: Sunday, April 28, 2013 8:34 PM
To: dev@lucene.apache.org
Subject: Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 
- Failure!

 

I looked into a previous failure of this test and committed a fix for that. I 
think that fix caused this failure. In the fix I use of the NoMergePolicy and 
this seems to break the assert in the RandomIndexWriter#doRandomForceMerge() 
method.

 

On 28 April 2013 19:17, Michael McCandless  wrote:

I think Martijn is looking into it?
Mike McCandless

http://blog.mikemccandless.com



On Sun, Apr 28, 2013 at 11:34 AM, Uwe Schindler  wrote:
> This one reproduces with Oracle JDK 6 or 7, 32 or 64 bit. It is not an J9 
> issue, it's a real bug!
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -Original Message-
>> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
>> Sent: Sunday, April 28, 2013 5:19 PM
>> To: dev@lucene.apache.org; u...@thetaphi.de
>> Subject: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 -
>> Failure!
>>
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5334/
>> Java: 32bit/ibm-j9-jdk6
>>
>> 1 tests failed.
>> REGRESSION:
>> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting
>>
>> Error Message:
>> limit=2 actual=4
>>
>> Stack Trace:
>> java.lang.AssertionError: limit=2 actual=4
>>   at
>> __randomizedtesting.SeedInfo.seed([51EE345C29BF7C40:5907D91D6916712E
>> ]:0)
>>   at
>> org.apache.lucene.index.RandomIndexWriter.doRandomForceMerge(Rando
>> mIndexWriter.java:293)
>>   at
>> org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.jav
>> a:336)
>>   at
>> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting(TestB
>> lockJoinSorting.java:212)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>> ava:60)
>>   at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>> sorImpl.java:37)
>>   at java.lang.reflect.Method.invoke(Method.java:611)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
>> dRunner.java:1559)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Rando
>> mizedRunner.java:79)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando
>> mizedRunner.java:737)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando
>> mizedRunner.java:773)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
>> mizedRunner.java:787)
>>   at
>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
>> SetupTeardownChained.java:50)
>>   at
>> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa
>> cheSanity.java:51)
>>   at
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
>> fterRule.java:46)
>>   at
>> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1
>> .evaluate(SystemPropertiesInvariantRule.java:55)
>>   at
>> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
>> readAndTestName.java:49)
>>   at
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
>> IgnoreAfterMaxFailures.java:70)
>>   at
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
>> .java:48)
>>   at
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
>> ementAdapter.java:36)
>>   at
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
>> run(ThreadLeakControl.java:358)
>>   at
>> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask
>> (ThreadLeakControl.java:782)
>>   at
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL
>> eakControl.java:442)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran
>> domizedRunner.java:746)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando
>> mizedRunner.java:648)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando
>> mizedRunner.java:682)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando
>> mizedRunner.java:693)
>>   at
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
>> fterRule.java:46)
>>   at
>> org.apache.lucene.uti

[jira] [Commented] (LUCENE-4965) Add dynamic numeric range faceting

[Shai Erera (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644101#comment-13644101
 ] 

Shai Erera commented on LUCENE-4965:


Comments:

* Range is not really extendable (private ctor) -- is that intentional? I guess 
there's not much point extending it ...

* Any reason why not take primitive values and let the user define e.g 
Long.MAX_VALUE as an unlimited upper bound? I'm not a big fan of auto-boxing, 
and passing null is as good to me as passing MAX_VAL. User has to make a 
decision anyway, so might as well be explicit about it.

* Accumulate() iterates at the outer loop on matchingDocs, and inner loop on 
ranges. I remember while writing FacetsAccumulator that luceneutil was happier 
with the other way (matchingDocs inner). Maybe test?

* Shouldn't {{if (ranges.ranges.accept(v))}} break if there's a match?
** While at it, maybe RangeSet should sort the ranges by their minimum value? 
Not sure if asymptotically this will matter...

* I don't think it matters much, but maybe allocate {{new 
ArrayList()}} with {{ranges.ranges.length}}?

I think this we're almost ready!

> Add dynamic numeric range faceting
> --
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch, 
> LUCENE-4965.patch, LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things 
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc.  But because time is constantly advancing,
> doing this at index time is a not easy ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 - Failure!

[Martijn v Groningen]

I looked into a previous failure of this test and committed a fix for that.
I think that fix caused this failure. In the fix I use of the NoMergePolicy
and this seems to break the assert in the
RandomIndexWriter#doRandomForceMerge() method.


On 28 April 2013 19:17, Michael McCandless wrote:

> I think Martijn is looking into it?
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Sun, Apr 28, 2013 at 11:34 AM, Uwe Schindler  wrote:
> > This one reproduces with Oracle JDK 6 or 7, 32 or 64 bit. It is not an
> J9 issue, it's a real bug!
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> >> -Original Message-
> >> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> >> Sent: Sunday, April 28, 2013 5:19 PM
> >> To: dev@lucene.apache.org; u...@thetaphi.de
> >> Subject: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build #
> 5334 -
> >> Failure!
> >>
> >> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5334/
> >> Java: 32bit/ibm-j9-jdk6
> >>
> >> 1 tests failed.
> >> REGRESSION:
> >> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting
> >>
> >> Error Message:
> >> limit=2 actual=4
> >>
> >> Stack Trace:
> >> java.lang.AssertionError: limit=2 actual=4
> >>   at
> >> __randomizedtesting.SeedInfo.seed([51EE345C29BF7C40:5907D91D6916712E
> >> ]:0)
> >>   at
> >> org.apache.lucene.index.RandomIndexWriter.doRandomForceMerge(Rando
> >> mIndexWriter.java:293)
> >>   at
> >> org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.jav
> >> a:336)
> >>   at
> >>
> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting(TestB
> >> lockJoinSorting.java:212)
> >>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>   at
> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> >> ava:60)
> >>   at
> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> >> sorImpl.java:37)
> >>   at java.lang.reflect.Method.invoke(Method.java:611)
> >>   at
> >> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
> >> dRunner.java:1559)
> >>   at
> >> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Rando
> >> mizedRunner.java:79)
> >>   at
> >> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando
> >> mizedRunner.java:737)
> >>   at
> >> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando
> >> mizedRunner.java:773)
> >>   at
> >> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
> >> mizedRunner.java:787)
> >>   at
> >> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
> >> SetupTeardownChained.java:50)
> >>   at
> >>
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa
> >> cheSanity.java:51)
> >>   at
> >>
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
> >> fterRule.java:46)
> >>   at
> >> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1
> >> .evaluate(SystemPropertiesInvariantRule.java:55)
> >>   at
> >> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
> >> readAndTestName.java:49)
> >>   at
> >>
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
> >> IgnoreAfterMaxFailures.java:70)
> >>   at
> >>
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
> >> .java:48)
> >>   at
> >> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
> >> ementAdapter.java:36)
> >>   at
> >> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
> >> run(ThreadLeakControl.java:358)
> >>   at
> >> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask
> >> (ThreadLeakControl.java:782)
> >>   at
> >> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL
> >> eakControl.java:442)
> >>   at
> >> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran
> >> domizedRunner.java:746)
> >>   at
> >> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando
> >> mizedRunner.java:648)
> >>   at
> >> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando
> >> mizedRunner.java:682)
> >>   at
> >> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando
> >> mizedRunner.java:693)
> >>   at
> >>
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
> >> fterRule.java:46)
> >>   at
> >> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCl
> >> assName.java:42)
> >>   at
> >> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1
> >> .evaluate(SystemPropertiesInvariantRule.java:55)
> >>   at
> >> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet
> >> hodsRule$1.evaluate(NoS

Re: Implicit collection name is no longer supported - bug or feature change??

[Erick Erickson]

Yonik:

See SOLR-4773.

On Sun, Apr 28, 2013 at 5:04 AM, Yonik Seeley  wrote:
> On Sun, Apr 28, 2013 at 7:03 AM, Jack Krupansky  
> wrote:
>> I just noticed that Solr no longer supports implicit collection name, at
>> least for /update and /select. Is this an intentional feature deprecation,
>> or just an outright bug? I hope it’s the latter, but with some of the
>> drawn-out discussions related to core discovery and solr.xml in recent
>> weeks, I’m just not sure.
>
> Yeah, this must have (hopefully) been unintentional  with the switch
> to the new-style XML.
>
> I was going to try it out myself, but I seem to be hitting some other
> issue even just starting up the example:
>
> 3047 [coreLoadExecutor-3-thread-1] ERROR
> org.apache.solr.core.CoreContainer  – Failed to load file
> /opt/code/lusolr_clean6/solr/example/solr/solr/collection1/solrconfig.xml
> 3049 [coreLoadExecutor-3-thread-1] ERROR
> org.apache.solr.core.CoreContainer  – Unable to create core:
> collection1
> Caused by: java.io.IOException: Can't find resource 'solrconfig.xml'
> in classpath or 'solr/solr/collection1/conf/',
> cwd=/opt/code/lusolr_clean6/solr/example
>
> -Yonik
> http://lucidworks.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries

[Jack Krupansky (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644076#comment-13644076
 ] 

Jack Krupansky commented on LUCENE-4956:


Looking at the actual tar file, I notice that it has the factory classes placed 
in "solr" directories rather than in the lucene directories as factories are 
normally organized.

By all means proceed with producing a normal patch that shows the final 
organization of this new analysis package.

Some other issues:

1. Complete absence of Java doc for the tokenizer factory and token filter 
factory classes - it is not "Solr user-ready" at present. There should be an 
XML example of a token filter with the parameters, as is the usual practice in 
Lucene/Solr.

2. No Apache license headers in the "Solr" code. I thought this stuff was 
already supposed to be ASL 2.0?

3. No Solr schema.xml change to add the text_ko field type.

4. At least the KoreanAnalyzer.java and KoreanTokenizer.java source code have 
tab characters - odd format. Need to be normalized for Lucene project 
conventions.

5. There is a hardwired stop word list in KoreanAnalyzer that appears to be 
nearly identical or close to StopAnalyzer.ENGLISH_STOP_WORDS_SET. Why doesn't 
that static code copy the StopAnalyzer list and then add the few extra terms 
that are needed? If there is a reason, place it in a comment.

But as I said, by all means proceed to a normal patch file now that the tar 
contribution is "legal".


> the korean analyzer that has a korean morphological analyzer and dictionaries
> -
>
> Key: LUCENE-4956
> URL: https://issues.apache.org/jira/browse/LUCENE-4956
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.2
>Reporter: SooMyung Lee
>  Labels: newbie
> Attachments: kr.analyzer.4x.tar
>
>
> Korean language has specific characteristic. When developing search service 
> with lucene & solr in korean, there are some problems in searching and 
> indexing. The korean analyer solved the problems with a korean morphological 
> anlyzer. It consists of a korean morphological analyzer, dictionaries, a 
> korean tokenizer and a korean filter. The korean anlyzer is made for lucene 
> and solr. If you develop a search service with lucene in korean, It is the 
> best idea to choose the korean analyzer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4965) Add dynamic numeric range faceting

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-4965:
---

Attachment: LUCENE-4965.patch

New patch, breaking out separate .newLong/Float/DoubleRange.

> Add dynamic numeric range faceting
> --
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch, 
> LUCENE-4965.patch, LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things 
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc.  But because time is constantly advancing,
> doing this at index time is a not easy ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries

[Steve Rowe (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644065#comment-13644065
 ] 

Steve Rowe commented on LUCENE-4956:


bq. As for where the analyzer code itself lives, I think it's fine to put it in 
{{lucene/analysis/arirang}}.

+1

bq. I'm all for improving our scheme, but perhaps we can open up a separate 
JIRA for this and keep this one focused on Korean?

+1

> the korean analyzer that has a korean morphological analyzer and dictionaries
> -
>
> Key: LUCENE-4956
> URL: https://issues.apache.org/jira/browse/LUCENE-4956
> Project: Lucene - Core
>  Issue Type: New Feature
>  Components: modules/analysis
>Affects Versions: 4.2
>Reporter: SooMyung Lee
>  Labels: newbie
> Attachments: kr.analyzer.4x.tar
>
>
> Korean language has specific characteristic. When developing search service 
> with lucene & solr in korean, there are some problems in searching and 
> indexing. The korean analyer solved the problems with a korean morphological 
> anlyzer. It consists of a korean morphological analyzer, dictionaries, a 
> korean tokenizer and a korean filter. The korean anlyzer is made for lucene 
> and solr. If you develop a search service with lucene in korean, It is the 
> best idea to choose the korean analyzer.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 - Failure!

[Michael McCandless]

I think Martijn is looking into it?
Mike McCandless

http://blog.mikemccandless.com


On Sun, Apr 28, 2013 at 11:34 AM, Uwe Schindler  wrote:
> This one reproduces with Oracle JDK 6 or 7, 32 or 64 bit. It is not an J9 
> issue, it's a real bug!
>
> Uwe
>
> -
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -Original Message-
>> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
>> Sent: Sunday, April 28, 2013 5:19 PM
>> To: dev@lucene.apache.org; u...@thetaphi.de
>> Subject: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 -
>> Failure!
>>
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5334/
>> Java: 32bit/ibm-j9-jdk6
>>
>> 1 tests failed.
>> REGRESSION:
>> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting
>>
>> Error Message:
>> limit=2 actual=4
>>
>> Stack Trace:
>> java.lang.AssertionError: limit=2 actual=4
>>   at
>> __randomizedtesting.SeedInfo.seed([51EE345C29BF7C40:5907D91D6916712E
>> ]:0)
>>   at
>> org.apache.lucene.index.RandomIndexWriter.doRandomForceMerge(Rando
>> mIndexWriter.java:293)
>>   at
>> org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.jav
>> a:336)
>>   at
>> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting(TestB
>> lockJoinSorting.java:212)
>>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>   at
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
>> ava:60)
>>   at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
>> sorImpl.java:37)
>>   at java.lang.reflect.Method.invoke(Method.java:611)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
>> dRunner.java:1559)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Rando
>> mizedRunner.java:79)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando
>> mizedRunner.java:737)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando
>> mizedRunner.java:773)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
>> mizedRunner.java:787)
>>   at
>> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
>> SetupTeardownChained.java:50)
>>   at
>> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa
>> cheSanity.java:51)
>>   at
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
>> fterRule.java:46)
>>   at
>> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1
>> .evaluate(SystemPropertiesInvariantRule.java:55)
>>   at
>> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
>> readAndTestName.java:49)
>>   at
>> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
>> IgnoreAfterMaxFailures.java:70)
>>   at
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
>> .java:48)
>>   at
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
>> ementAdapter.java:36)
>>   at
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
>> run(ThreadLeakControl.java:358)
>>   at
>> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask
>> (ThreadLeakControl.java:782)
>>   at
>> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL
>> eakControl.java:442)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran
>> domizedRunner.java:746)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando
>> mizedRunner.java:648)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando
>> mizedRunner.java:682)
>>   at
>> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando
>> mizedRunner.java:693)
>>   at
>> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
>> fterRule.java:46)
>>   at
>> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCl
>> assName.java:42)
>>   at
>> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1
>> .evaluate(SystemPropertiesInvariantRule.java:55)
>>   at
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet
>> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>>   at
>> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet
>> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>>   at
>> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
>> ementAdapter.java:36)
>>   at
>> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAss
>> ertionsRequired.java:43)
>>   at
>> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
>> .java:48)
>>   at
>> org.apache.lucene.uti

[jira] [Commented] (SOLR-4773) New discovery mode needs to insure that instanceDir is a relative path

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644046#comment-13644046
 ] 

Erick Erickson commented on SOLR-4773:
--

I take it back, the new test in the patch does _NOT_ fail without the code 
changes, probably because it's an absolute rather than relative path... But my 
plane is descending so I'll be chopped off pretty soon, I'll be looking later.

> New discovery mode needs to insure that instanceDir is a relative path
> --
>
> Key: SOLR-4773
> URL: https://issues.apache.org/jira/browse/SOLR-4773
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.0, 4.4
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4773.patch
>
>
> Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example 
> fails because we can't find solrconfig. The construction of the instanceDir 
> in SolrCoreDiscoverer constructs a path with an extra solr (e.g. 
> solr/solr/core).
> I'll attach a patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4773) New discovery mode needs to insure that instanceDir is a relative path

[Erick Erickson (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644043#comment-13644043
 ] 

Erick Erickson commented on SOLR-4773:
--

[~thetaphi] Don't think this affects 4.3, or if it does only people using the 
core discovery process. At least I switched to the example solr.xml file that 
uses core discovery from 4.x to 4.3, compiled and it was OK.

[~jkrupan] blew up for me when I built 4x.



> New discovery mode needs to insure that instanceDir is a relative path
> --
>
> Key: SOLR-4773
> URL: https://issues.apache.org/jira/browse/SOLR-4773
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.0, 4.4
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4773.patch
>
>
> Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example 
> fails because we can't find solrconfig. The construction of the instanceDir 
> in SolrCoreDiscoverer constructs a path with an extra solr (e.g. 
> solr/solr/core).
> I'll attach a patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4773) New discovery mode needs to insure that instanceDir is a relative path

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson updated SOLR-4773:
-

Attachment: SOLR-4773.patch

Here's a preliminary patch that I really don't like much, but it illustrates 
the problem and has a test case. There's _got_ to be a better way of removing 
the ancestor paths.

> New discovery mode needs to insure that instanceDir is a relative path
> --
>
> Key: SOLR-4773
> URL: https://issues.apache.org/jira/browse/SOLR-4773
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.0, 4.4
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4773.patch
>
>
> Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example 
> fails because we can't find solrconfig. The construction of the instanceDir 
> in SolrCoreDiscoverer constructs a path with an extra solr (e.g. 
> solr/solr/core).
> I'll attach a patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4773) New discovery mode needs to insure that instanceDir is a relative path

[Jack Krupansky (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644041#comment-13644041
 ] 

Jack Krupansky commented on SOLR-4773:
--

4.3 RC3 example runs fine for me.

branch_4x ant run-example also works fine (although it has the problem with no 
longer supporting implicit collection name.)

But ant package for branch_4x, unzip the release, run the example from the 
release gives me the reported problem.


> New discovery mode needs to insure that instanceDir is a relative path
> --
>
> Key: SOLR-4773
> URL: https://issues.apache.org/jira/browse/SOLR-4773
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.0, 4.4
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 5.0, 4.4
>
> Attachments: SOLR-4773.patch
>
>
> Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example 
> fails because we can't find solrconfig. The construction of the instanceDir 
> in SolrCoreDiscoverer constructs a path with an extra solr (e.g. 
> solr/solr/core).
> I'll attach a patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

RE: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 - Failure!

[Uwe Schindler]

This one reproduces with Oracle JDK 6 or 7, 32 or 64 bit. It is not an J9 
issue, it's a real bug!

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de

> -Original Message-
> From: Policeman Jenkins Server [mailto:jenk...@thetaphi.de]
> Sent: Sunday, April 28, 2013 5:19 PM
> To: dev@lucene.apache.org; u...@thetaphi.de
> Subject: [JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 -
> Failure!
> 
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5334/
> Java: 32bit/ibm-j9-jdk6
> 
> 1 tests failed.
> REGRESSION:
> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting
> 
> Error Message:
> limit=2 actual=4
> 
> Stack Trace:
> java.lang.AssertionError: limit=2 actual=4
>   at
> __randomizedtesting.SeedInfo.seed([51EE345C29BF7C40:5907D91D6916712E
> ]:0)
>   at
> org.apache.lucene.index.RandomIndexWriter.doRandomForceMerge(Rando
> mIndexWriter.java:293)
>   at
> org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.jav
> a:336)
>   at
> org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting(TestB
> lockJoinSorting.java:212)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:60)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:37)
>   at java.lang.reflect.Method.invoke(Method.java:611)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(Randomize
> dRunner.java:1559)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(Rando
> mizedRunner.java:79)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Rando
> mizedRunner.java:737)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Rando
> mizedRunner.java:773)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Rando
> mizedRunner.java:787)
>   at
> org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRule
> SetupTeardownChained.java:50)
>   at
> org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCa
> cheSanity.java:51)
>   at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
> fterRule.java:46)
>   at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1
> .evaluate(SystemPropertiesInvariantRule.java:55)
>   at
> org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleTh
> readAndTestName.java:49)
>   at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
> IgnoreAfterMaxFailures.java:70)
>   at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
> .java:48)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
> ementAdapter.java:36)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.
> run(ThreadLeakControl.java:358)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask
> (ThreadLeakControl.java:782)
>   at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadL
> eakControl.java:442)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Ran
> domizedRunner.java:746)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Rando
> mizedRunner.java:648)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Rando
> mizedRunner.java:682)
>   at
> com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Rando
> mizedRunner.java:693)
>   at
> org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeA
> fterRule.java:46)
>   at
> org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreCl
> assName.java:42)
>   at
> com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1
> .evaluate(SystemPropertiesInvariantRule.java:55)
>   at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet
> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMet
> hodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
> ementAdapter.java:36)
>   at
> org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAss
> ertionsRequired.java:43)
>   at
> org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure
> .java:48)
>   at
> org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRule
> IgnoreAfterMaxFailures.java:70)
>   at
> org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnore
> TestSuites.java:55)
>   at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(Stat
>

[JENKINS] Lucene-Solr-4.x-Linux (32bit/ibm-j9-jdk6) - Build # 5334 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5334/
Java: 32bit/ibm-j9-jdk6 

1 tests failed.
REGRESSION:  
org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting

Error Message:
limit=2 actual=4

Stack Trace:
java.lang.AssertionError: limit=2 actual=4
at 
__randomizedtesting.SeedInfo.seed([51EE345C29BF7C40:5907D91D6916712E]:0)
at 
org.apache.lucene.index.RandomIndexWriter.doRandomForceMerge(RandomIndexWriter.java:293)
at 
org.apache.lucene.index.RandomIndexWriter.close(RandomIndexWriter.java:336)
at 
org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting(TestBlockJoinSorting.java:212)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:611)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:738)




Build Log:
[...truncated 6696 lines...]
[junit4:junit4] Suite: org.apache.lucene.search.join.TestBlockJoinSorting
[junit4:junit4]   2> NOTE: reproduce with: ant test  
-Dtestcase=TestBlockJoinSorting -Dtests.method=testNestedSorting 
-Dtests.seed=51EE345C29BF7C40 -Dtests.multiplier=3 -Dtests.slow=true 
-Dtests.locale=mk_MK -Dtests.timezone=Europe/Belfast -Dtests.file.encoding=UTF-8
[junit4:junit4] FAILURE 0.50s J0 | TestBlockJoinSorting.testNestedSorting <

[jira] [Updated] (LUCENE-4965) Add dynamic numeric range faceting

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-4965:
---

Attachment: LUCENE-4965.patch

Patch, just moving things under oal.facet.range.

I'm ... not sure how to do the generics to support float/double/int/long, 
without just making separate Accumulator (eg 
Int/Float/Double/LongRangeAccumulator), since I need to use native types for 
each case.  

Also, I think ideally (maybe not on the first commit), we should use an 
interval tree to find overlapping ranges for each value ... so somehow we'd 
need to build this from all of the provided ranges up front.

> Add dynamic numeric range faceting
> --
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch, 
> LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things 
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc.  But because time is constantly advancing,
> doing this at index time is a not easy ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4965) Add dynamic numeric range faceting

[Shai Erera (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644032#comment-13644032
 ] 

Shai Erera commented on LUCENE-4965:


Thanks Mike. Looks good! Few more comments:

* The nocommit on default aggregator -- I think you can override and throw 
Unsupported?

* +1 to move to o.a.l.facet.dynamic, or oal.facet.range.

* DynamicRange:
** thanks for introducing accept(), but I don't think the way it's implemented 
can support other impls, such as float/double.
** Perhapd instead DynamicRange should be abstract, with impls for LongRange, 
IntRange, FloatRange and DoubleRange, which can then implement accept properly.
*** It won't have min/max, but can keep label.
** Also, that will allow you to add type-safety to DynamicRangeFacetRequest. 
I.e. now someone can pass int and float ranges in the same request, which makes 
no sense. But if you make it 'typed', one would need to specify the type at 
construction, and cannot make mistakes.
*** DRFR would then be defined with {{}} and its ctor 
would take {{T...}}.

* I think it's ok if the request is called DynamicRange without numerics 
because someone can write a DynamicRange impl not on numeric fields. He'll then 
need to also write an accumulator though, but as for the request, it's still 
about DynamicRange implementations ... in short, I'm +0 if it stays like that 
or renamed :).

> Add dynamic numeric range faceting
> --
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things 
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc.  But because time is constantly advancing,
> doing this at index time is a not easy ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4773) New discovery mode needs to insure that instanceDir is a relative path

[Uwe Schindler (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644031#comment-13644031
 ] 

Uwe Schindler commented on SOLR-4773:
-

Yeah the nightly smoker already failed! I hope this does not affect 4.3?

> New discovery mode needs to insure that instanceDir is a relative path
> --
>
> Key: SOLR-4773
> URL: https://issues.apache.org/jira/browse/SOLR-4773
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.0, 4.4
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 5.0, 4.4
>
>
> Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example 
> fails because we can't find solrconfig. The construction of the instanceDir 
> in SolrCoreDiscoverer constructs a path with an extra solr (e.g. 
> solr/solr/core).
> I'll attach a patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-4773) New discovery mode needs to insure that instanceDir is a relative path

[Erick Erickson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Erick Erickson reassigned SOLR-4773:


Assignee: Erick Erickson

> New discovery mode needs to insure that instanceDir is a relative path
> --
>
> Key: SOLR-4773
> URL: https://issues.apache.org/jira/browse/SOLR-4773
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis
>Affects Versions: 5.0, 4.4
>Reporter: Erick Erickson
>Assignee: Erick Erickson
> Fix For: 5.0, 4.4
>
>
> Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example 
> fails because we can't find solrconfig. The construction of the instanceDir 
> in SolrCoreDiscoverer constructs a path with an extra solr (e.g. 
> solr/solr/core).
> I'll attach a patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-4773) New discovery mode needs to insure that instanceDir is a relative path

[Erick Erickson (JIRA)]

Erick Erickson created SOLR-4773:


 Summary: New discovery mode needs to insure that instanceDir is a 
relative path
 Key: SOLR-4773
 URL: https://issues.apache.org/jira/browse/SOLR-4773
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 5.0, 4.4
Reporter: Erick Erickson
 Fix For: 5.0, 4.4


Doing a fresh checkout of 4.x (trunk to to I think) and firing up the example 
fails because we can't find solrconfig. The construction of the instanceDir in 
SolrCoreDiscoverer constructs a path with an extra solr (e.g. solr/solr/core).

I'll attach a patch shortly.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4965) Add dynamic numeric range faceting

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-4965:
---

Attachment: LUCENE-4965.patch

Woops, trying again ...

> Add dynamic numeric range faceting
> --
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch, LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things 
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc.  But because time is constantly advancing,
> doing this at index time is a not easy ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4965) Add dynamic numeric range faceting

[Michael McCandless (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LUCENE-4965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael McCandless updated LUCENE-4965:
---

Attachment: LUCENE-4965.patch

New patch incorporating Shai's feedback ...

> Add dynamic numeric range faceting
> --
>
> Key: LUCENE-4965
> URL: https://issues.apache.org/jira/browse/LUCENE-4965
> Project: Lucene - Core
>  Issue Type: Improvement
>  Components: modules/facet
>Reporter: Michael McCandless
>Assignee: Michael McCandless
> Fix For: 5.0, 4.4
>
> Attachments: LUCENE-4965.patch, LUCENE-4965.patch
>
>
> The facet module today requires the app to compute the hierarchy
> at index time, eg a timestamp field might use a year/month/day
> hierarchy.
> While this gives great performance, since it minimizes the search-time
> computation, sometimes it's unfortunately useful/necessary to do things 
> entirely at
> search time, like Solr does.
> E.g. I'm playing with a prototype Lucene search for Jira issues
> and I'd like to add a drill down+sideways for "Updated in past day,
> 2 days, week, month" etc.  But because time is constantly advancing,
> doing this at index time is a not easy ...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Implicit collection name is no longer supported - bug or feature change??

[Yonik Seeley]

On Sun, Apr 28, 2013 at 7:03 AM, Jack Krupansky  wrote:
> I just noticed that Solr no longer supports implicit collection name, at
> least for /update and /select. Is this an intentional feature deprecation,
> or just an outright bug? I hope it’s the latter, but with some of the
> drawn-out discussions related to core discovery and solr.xml in recent
> weeks, I’m just not sure.

Yeah, this must have (hopefully) been unintentional  with the switch
to the new-style XML.

I was going to try it out myself, but I seem to be hitting some other
issue even just starting up the example:

3047 [coreLoadExecutor-3-thread-1] ERROR
org.apache.solr.core.CoreContainer  – Failed to load file
/opt/code/lusolr_clean6/solr/example/solr/solr/collection1/solrconfig.xml
3049 [coreLoadExecutor-3-thread-1] ERROR
org.apache.solr.core.CoreContainer  – Unable to create core:
collection1
Caused by: java.io.IOException: Can't find resource 'solrconfig.xml'
in classpath or 'solr/solr/collection1/conf/',
cwd=/opt/code/lusolr_clean6/solr/example

-Yonik
http://lucidworks.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Implicit collection name is no longer supported - bug or feature change??

[Jack Krupansky]

I just noticed that Solr no longer supports implicit collection name, at least 
for /update and /select. Is this an intentional feature deprecation, or just an 
outright bug? I hope it’s the latter, but with some of the drawn-out 
discussions related to core discovery and solr.xml in recent weeks, I’m just 
not sure.

For example, using the standard Solr example (ant run-example), I used to be 
able to say (still can in 4.3):

curl “http://localhost:8983/solr/select/?q=*:*&indent=true”

But with trunk and branch_4x this gives a 404 and I have to add the explicit 
collection name:

curl “http://localhost:8983/solr/collection1/select/?q=*:*&indent=true”

Ditto for /update. In 4.3 I can say:

curl 'localhost:8983/solr/update?commit=true' -H 
'Content-type:application/json' -d '
[{"id":"7cb8a43c","title":"My original Title", "content": "Initial content"}]'

But with trunk and branch_4x this gives a 404 and I have to say:

curl 'localhost:8983/solr/collection1/update?commit=true' -H 
'Content-type:application/json' -d '
[{"id":"7cb8a43c","title":"My original Title", "content": "Initial content"}]'

What’s going on?

-- Jack Krupansky

[jira] [Commented] (SOLR-4772) DateRoundingUpdateProcessorFactory

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13643943#comment-13643943
 ] 

Upayavira commented on SOLR-4772:
-

Thinking about it, I should convert this to a generic RoundingUpdateProcessor, 
that can do numbers too. Would allow folks to use the same technique across 
anything you might do range faceting on.

> DateRoundingUpdateProcessorFactory
> --
>
> Key: SOLR-4772
> URL: https://issues.apache.org/jira/browse/SOLR-4772
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Reporter: Upayavira
>Priority: Minor
> Attachments: DateRoundingUpdateProcessorFactory.zip, 
> DateRoundingUpdateProcessorFactory.zip
>
>
> A simple UpdateProcessor that rounds dates using the DateMathParser.
> At present it is not possible to combine pivot faceting with range queries. 
> This simple UpdateProcessor allows us to round our dates on their way into 
> Solr, giving us date fields that can be used in pivot facets.
> This can be extremely useful when using facets to plot graphs based upon log 
> files indexed into Solr.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4772) DateRoundingUpdateProcessorFactory

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-4772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira updated SOLR-4772:


Attachment: DateRoundingUpdateProcessorFactory.zip

Updated patch that answers these points - particularly throwing an exception if 
rounding not configured correctly. 

At present, if it can't parse a date, it passes the value through logging a 
warning. Should it throw an exception instead?


> DateRoundingUpdateProcessorFactory
> --
>
> Key: SOLR-4772
> URL: https://issues.apache.org/jira/browse/SOLR-4772
> Project: Solr
>  Issue Type: Improvement
>  Components: update
>Reporter: Upayavira
>Priority: Minor
> Attachments: DateRoundingUpdateProcessorFactory.zip, 
> DateRoundingUpdateProcessorFactory.zip
>
>
> A simple UpdateProcessor that rounds dates using the DateMathParser.
> At present it is not possible to combine pivot faceting with range queries. 
> This simple UpdateProcessor allows us to round our dates on their way into 
> Solr, giving us date fields that can be used in pivot facets.
> This can be extremely useful when using facets to plot graphs based upon log 
> files indexed into Solr.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-SmokeRelease-trunk - Build # 77 - Failure

[Apache Jenkins Server]

Build: https://builds.apache.org/job/Lucene-Solr-SmokeRelease-trunk/77/

No tests ran.

Build Log:
[...truncated 33054 lines...]
prepare-release-no-sign:
[mkdir] Created dir: 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease
 [copy] Copying 401 files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/lucene
 [copy] Copying 194 files to 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/solr
 [exec] JAVA7_HOME is /home/hudson/tools/java/latest1.7
 [exec] NOTE: output encoding is US-ASCII
 [exec] 
 [exec] Load release URL 
"file:/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeRelease/"...
 [exec] 
 [exec] Test Lucene...
 [exec]   test basics...
 [exec]   get KEYS
 [exec] 0.1 MB in 0.01 sec (17.3 MB/sec)
 [exec]   check changes HTML...
 [exec]   download lucene-5.0.0-src.tgz...
 [exec] 26.5 MB in 0.04 sec (667.0 MB/sec)
 [exec] verify md5/sha1 digests
 [exec]   download lucene-5.0.0.tgz...
 [exec] 48.3 MB in 0.07 sec (664.9 MB/sec)
 [exec] verify md5/sha1 digests
 [exec]   download lucene-5.0.0.zip...
 [exec] 57.6 MB in 0.07 sec (862.0 MB/sec)
 [exec] verify md5/sha1 digests
 [exec]   unpack lucene-5.0.0.tgz...
 [exec] verify JAR/WAR metadata...
 [exec] test demo with 1.7...
 [exec]   got 5440 hits for query "lucene"
 [exec] check Lucene's javadoc JAR
 [exec]   unpack lucene-5.0.0.zip...
 [exec] verify JAR/WAR metadata...
 [exec] test demo with 1.7...
 [exec]   got 5440 hits for query "lucene"
 [exec] check Lucene's javadoc JAR
 [exec]   unpack lucene-5.0.0-src.tgz...
 [exec] make sure no JARs/WARs in src dist...
 [exec] run "ant validate"
 [exec] run tests w/ Java 7...
 [exec] test demo with 1.7...
 [exec]   got 210 hits for query "lucene"
 [exec] generate javadocs w/ Java 7...
 [exec] 
 [exec] Crawl/parse...
 [exec] 
 [exec] Verify...
 [exec] 
 [exec] Test Solr...
 [exec]   test basics...
 [exec]   get KEYS
 [exec] 0.1 MB in 0.01 sec (13.6 MB/sec)
 [exec]   check changes HTML...
 [exec]   download solr-5.0.0-src.tgz...
 [exec] 30.2 MB in 0.10 sec (310.3 MB/sec)
 [exec] verify md5/sha1 digests
 [exec]   download solr-5.0.0.tgz...
 [exec] 112.0 MB in 0.59 sec (189.0 MB/sec)
 [exec] verify md5/sha1 digests
 [exec]   download solr-5.0.0.zip...
 [exec] 116.4 MB in 0.35 sec (332.5 MB/sec)
 [exec] verify md5/sha1 digests
 [exec]   unpack solr-5.0.0.tgz...
 [exec] verify JAR/WAR metadata...
 [exec]   **WARNING**: skipping check of 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeReleaseTmp/unpack/solr-5.0.0/contrib/dataimporthandler/lib/mail-1.4.1.jar:
 it has javax.* classes
 [exec]   **WARNING**: skipping check of 
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeReleaseTmp/unpack/solr-5.0.0/contrib/dataimporthandler/lib/activation-1.1.jar:
 it has javax.* classes
 [exec] make sure WAR file has no javax.* or java.* classes...
 [exec] copying unpacked distribution for Java 7 ...
 [exec] test solr example w/ Java 7...
 [exec]   start Solr instance 
(log=/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/lucene/build/fakeReleaseTmp/unpack/solr-5.0.0-java7/solr-example.log)...
 [exec]   startup done
 [exec]   test utf8...
 [exec] 
 [exec] command "sh ./exampledocs/test_utf8.sh" failed:
 [exec] ERROR: Could not curl to Solr - is curl installed? Is Solr not 
running?
 [exec] 
 [exec] 
 [exec]   stop server (SIGINT)...
 [exec] Traceback (most recent call last):
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1378, in 
 [exec] main()
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1322, in main
 [exec] smokeTest(baseURL, svnRevision, version, tmpDir, isSigned)
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 1366, in smokeTest
 [exec] unpackAndVerify('solr', tmpDir, artifact, svnRevision, version)
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-SmokeRelease-trunk/dev-tools/scripts/smokeTestRelease.py",
 line 590, in unpackAndVerify
 [exec] verifyUnpacked(project, artifact, unpackPath, svnRevision, 
version, tmpDir)
 [exec]   File 
"/usr/home/hudson/hudson-slave/workspace/Lucene-