from:"Grant Ingersoll"


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

Grant Ingersoll commented on LUCENE-7354:
-

OK, more detail:

In my standalone server, I have a collection that has a single shard (I created 
it using bin/solr create_collection).  The test has 2 shards, which then 
invokes RealTimeGetComponent.createSubRequests() which then adds an "ids" 
params, which is what then causes the the else clause cited above to get 
invoked.

[~yo...@apache.org] can you provide some insight?  (Most of the code was 
written by you)

> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: LUCENE-7354-mlt-fix
>
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object


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

Grant Ingersoll commented on LUCENE-7354:
-

I think the culprit is in RealTimeGetComponent.java, circa lines 278:
{code}
if (ids ==  null && allIds.length <= 1) {
 // if the doc was not found, then use a value of null.
 rsp.add("doc", docList.size() > 0 ? docList.get(0) : null);
   } else {
 docList.setNumFound(docList.size());
 rsp.addResponse(docList);
   }
{code}

When debugging the test class (CloudMLTQParserTest), we end up in the else 
clause.  When connecting to standalone via curl (e.g. 
http://localhost:8983/solr/mlt/select?indent=on={!mlt%20qf=resourcename}ID=json)),
 we end up in the if clause.

Still debugging what is causing ids and allIds to be set in the former case and 
not in the latter, as the query parameter looks almost identical.


> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>    Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: LUCENE-7354-mlt-fix
>
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object


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

Grant Ingersoll commented on LUCENE-7354:
-

And also still seeing it on master, but the plot thickens:

# When you debug via the test, it is as [~steve_rowe] says above
# When you stand up solr (bin/solr) and issue an MLT query from curl (or the 
like), I see the Field objects




> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>    Reporter: Grant Ingersoll
>    Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: LUCENE-7354-mlt-fix
>
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object


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

Grant Ingersoll commented on LUCENE-7354:
-

I'm certain this is occurring on 5.5.1 at a minimum.

> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>    Reporter: Grant Ingersoll
>    Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: LUCENE-7354-mlt-fix
>
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object

2016-06-29 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll commented on LUCENE-7354:
-

bq. I don't see this - when I run CloudMLTQParserTest without your patch, and I 
look at MoreLikeThis.retrieveTerms() where String.valueOf(fieldValue) is called 
(by pulling the value of that expression out into a variable and breaking there 
in the debugger), I only see the actual field values - no indexed stored et al.

I'll check again, [~steve_rowe].  I was doing the same thing you describe.  
Could be a version issue.  I am on Solr 5.5.1.

> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>    Reporter: Grant Ingersoll
>    Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: LUCENE-7354-mlt-fix
>
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object

2016-06-25 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll edited comment on LUCENE-7354 at 6/25/16 12:45 PM:
---

Mostly complete, but sharing early, as it's been a while since I've last 
patched Lucene/Solr.  Not thrilled about the instanceof in CloudMLTQParser, but 
not much choice.

Still need to wait on the full test suite to pass and to remove no commits and 
TODOs.


was (Author: gsingers):
Not complete, but sharing early, as it's been a while since I've last patched 
Lucene/Solr.  Not thrilled about the instanceof in CloudMLTQParser, but not 
much choice.

Still need to wait on the full test suite to pass and to remove no commits and 
TODOs.

> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>    Reporter: Grant Ingersoll
>    Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: LUCENE-7354-mlt-fix
>
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object

2016-06-25 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll updated LUCENE-7354:

Attachment: LUCENE-7354-mlt-fix

Not complete, but sharing early, as it's been a while since I've last patched 
Lucene/Solr.  Not thrilled about the instanceof in CloudMLTQParser, but not 
much choice.

Still need to wait on the full test suite to pass and to remove no commits and 
TODOs.

> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>    Reporter: Grant Ingersoll
>    Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: LUCENE-7354-mlt-fix
>
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object

2016-06-25 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll commented on LUCENE-7354:
-

This is also a Solr issue.  I'm not a big fan of the API for the like call in 
this particular case: 
{{code}}public Query like(Map<String, Collection> filteredDocument) 
throws IOException {{code}} is just asking for trouble, even if that saves a 
few operations in Solr.  

My proposal:
# Change that signature, which is only used by Solr in CloudMLTQParser, to take 
Map<String, Collection>, thus forcing some type safety
# Fix the retrieveTerms to check the fields line up.  
# Write some tests for the code path in question.

> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object

2016-06-24 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll edited comment on LUCENE-7354 at 6/24/16 11:15 PM:
---

In looking at this code, it seems a bit more broken than I first thought.  
AFAICT, in retrieveTerms (circa line 760) we loop over the MLT configured 
fields, then we loop over the filteredDocument entries, but we don't actually 
check that the values in the filtered document are the ones configured on the 
MLT object.


was (Author: gsingers):
In looking at this code, it seems a bit more broken than I first thought.  
AFAICT, in retrieveTerms (circa line 79) we loop over the MLT configured 
fields, then we loop over the filteredDocument entries, but we don't actually 
check that the values in the filtered document are the ones configured on the 
MLT object.

> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>    Reporter: Grant Ingersoll
>    Assignee: Grant Ingersoll
>Priority: Minor
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object

2016-06-24 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll commented on LUCENE-7354:
-

In looking at this code, it seems a bit more broken than I first thought.  
AFAICT, in retrieveTerms (circa line 79) we loop over the MLT configured 
fields, then we loop over the filteredDocument entries, but we don't actually 
check that the values in the filtered document are the ones configured on the 
MLT object.

> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>    Reporter: Grant Ingersoll
>    Assignee: Grant Ingersoll
>Priority: Minor
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object

2016-06-23 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll reassigned LUCENE-7354:
---

Assignee: Grant Ingersoll

> MoreLikeThis incorrectly does toString on Field object
> --
>
> Key: LUCENE-7354
> URL: https://issues.apache.org/jira/browse/LUCENE-7354
> Project: Lucene - Core
>  Issue Type: Bug
>Affects Versions: 6.0.1, 5.5.1, master (7.0)
>    Reporter: Grant Ingersoll
>    Assignee: Grant Ingersoll
>Priority: Minor
>
> In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
> Field object, we are incorrectly calling toString on the Field object, which 
> puts the Field attributes (indexed, stored, et. al) into the String that is 
> returned.
> I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (LUCENE-7354) MoreLikeThis incorrectly does toString on Field object

2016-06-23 Thread Grant Ingersoll (JIRA)

Grant Ingersoll created LUCENE-7354:
---

 Summary: MoreLikeThis incorrectly does toString on Field object
 Key: LUCENE-7354
 URL: https://issues.apache.org/jira/browse/LUCENE-7354
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 5.5.1, 6.0.1, master (7.0)
Reporter: Grant Ingersoll
Priority: Minor


In MoreLikeThis.java, circa line 763, when calling addTermFrequencies on a 
Field object, we are incorrectly calling toString on the Field object, which 
puts the Field attributes (indexed, stored, et. al) into the String that is 
returned.

I'll put up a patch/fix shortly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-8942) Set "enableRemoteStreaming" to false in default configsets

2016-04-04 Thread Grant Ingersoll (JIRA)

Grant Ingersoll created SOLR-8942:
-

 Summary: Set "enableRemoteStreaming" to false in default configsets
 Key: SOLR-8942
 URL: https://issues.apache.org/jira/browse/SOLR-8942
 Project: Solr
  Issue Type: Bug
Reporter: Grant Ingersoll
Priority: Minor


Since enableRemoteStreaming is a known property that can cause security issues 
(see https://cwiki.apache.org/confluence/display/solr/Content+Streams), we 
should set it to false by default and/or remove it as a default configuration.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7214) JSON Facet API

2015-03-20 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371443#comment-14371443
 ] 

Grant Ingersoll commented on SOLR-7214:
---

I should add, however, I think the hanging of off approach brings some 
interesting things to the table in terms of slicing and dicing things, but I 
admittedly haven't looked deeply at this new stuff.  My main concern here isn't 
the implementation or any one approach, it's the we now have 2 approaches.  
That's not going to make for a good user experience.  I would prefer we resolve 
the user experience before we commit and release this.

 JSON Facet API
 --

 Key: SOLR-7214
 URL: https://issues.apache.org/jira/browse/SOLR-7214
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Attachments: SOLR-7214.patch


 Overview is here: http://yonik.com/json-facet-api/
 The structured nature of nested sub-facets are more naturally expressed in a 
 nested structure like JSON rather than the flat structure that normal query 
 parameters provide.
 Goals:
 - First class JSON support
 - Easier programmatic construction of complex nested facet commands
 - Support a much more canonical response format that is easier for clients to 
 parse
 - First class analytics support
 - Support a cleaner way to do distributed faceting
 - Support better integration with other search features



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7214) JSON Facet API

2015-03-20 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14371421#comment-14371421
 ] 

Grant Ingersoll commented on SOLR-7214:
---

Yeah, I'm not a big fan of local params, so I'm all for a new approach to the 
API.  We should work to consolidate and deprecate, while leveraging what we can 
under the hood.

 JSON Facet API
 --

 Key: SOLR-7214
 URL: https://issues.apache.org/jira/browse/SOLR-7214
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Attachments: SOLR-7214.patch


 Overview is here: http://yonik.com/json-facet-api/
 The structured nature of nested sub-facets are more naturally expressed in a 
 nested structure like JSON rather than the flat structure that normal query 
 parameters provide.
 Goals:
 - First class JSON support
 - Easier programmatic construction of complex nested facet commands
 - Support a much more canonical response format that is easier for clients to 
 parse
 - First class analytics support
 - Support a cleaner way to do distributed faceting
 - Support better integration with other search features



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-7214) JSON Facet API

2015-03-16 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-7214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14364060#comment-14364060
 ] 

Grant Ingersoll commented on SOLR-7214:
---

How does this all fit with the work many have been doing on stats, facets, etc? 
 Is there a way we can merge these features/functionality such that users don't 
have completely separate APIs for this stuff?

e.g. SOLR-6348 and its children?  

 JSON Facet API
 --

 Key: SOLR-7214
 URL: https://issues.apache.org/jira/browse/SOLR-7214
 Project: Solr
  Issue Type: New Feature
Reporter: Yonik Seeley
 Attachments: SOLR-7214.patch


 Overview is here: http://heliosearch.org/json-facet-api/
 The structured nature of nested sub-facets are more naturally expressed in a 
 nested structure like JSON rather than the flat structure that normal query 
 parameters provide.
 Goals:
 - First class JSON support
 - Easier programmatic construction of complex nested facet commands
 - Support a much more canonical response format that is easier for clients to 
 parse
 - First class analytics support
 - Support a cleaner way to do distributed faceting
 - Support better integration with other search features



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Welcome Varun Thacker as Lucene/Solr committer

2015-02-23 Thread Grant Ingersoll

Hi All,

Please join me in welcoming Varun Thacker as the latest committer on Lucene
and Solr.

Varun, tradition is for you to provide a brief bio about yourself.

Welcome aboard!

-Grant

[jira] [Created] (SOLR-6980) Collection deletion, creation and shared configsets

Grant Ingersoll created SOLR-6980:
-

 Summary: Collection deletion, creation and shared configsets
 Key: SOLR-6980
 URL: https://issues.apache.org/jira/browse/SOLR-6980
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll


If a configset is not being shared and a collection is deleted, I think we 
should also delete the configset, or at least the copy of it for that 
collection. 

You can see the ill effects of this by doing:

# create a data-driven schema collection
# index some content to it, thus materializing an actual schema
# delete the collection
# create a new collection w/ the same name
# observe that the new collection has the old materialized schema




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6977) Given a date/time, facet only by time

Grant Ingersoll created SOLR-6977:
-

 Summary: Given a date/time, facet only by time
 Key: SOLR-6977
 URL: https://issues.apache.org/jira/browse/SOLR-6977
 Project: Solr
  Issue Type: Bug
  Components: faceting, SearchComponents - other
Reporter: Grant Ingersoll


Given a field that is indexed as date/time, it would be great if range faceting 
could facet only on date or only on time as an option.  For instance, given a 
months worth of date, I'd like to be able to see what are the hotspots during 
throughout the day.  Now, I could index a separate time field, but that seems 
redundant, as the data is already there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6979) Smarter single-valued multi-valued handling in data-driven schema

Grant Ingersoll created SOLR-6979:
-

 Summary: Smarter single-valued multi-valued handling in 
data-driven schema
 Key: SOLR-6979
 URL: https://issues.apache.org/jira/browse/SOLR-6979
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll


It would be nice if we could be smarter about single valued fields versus 
multi-valued when dealing w/ data-driven mode.  For instance, we probably can 
assume single-valued until proven otherwise.  May be some cases where a field 
is MV, but only ever has one value, too.

I was talking to [~hossman_luc...@fucit.org] about this, too, and I believe he 
had some ideas that hopefully he can add here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6965) Consider passing MIME-type info into field guessing capabilities


[ 
https://issues.apache.org/jira/browse/SOLR-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14277390#comment-14277390
 ] 

Grant Ingersoll commented on SOLR-6965:
---

One of the main use cases for me is that CSV is often only single valued, so 
perhaps we would guess better there.  See also SOLR-6979

 Consider passing MIME-type info into field guessing capabilities
 

 Key: SOLR-6965
 URL: https://issues.apache.org/jira/browse/SOLR-6965
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll

 In digging in on data-driven/field guessing/schemaless a bit more, my gut 
 instinct after staring at lots of different file types is that we should, if 
 possible, pass MIME type info through to the guessing mechanism so that we 
 can potentially make different choices for different types.  For instance, 
 CSV is much more structured and can likely be smarter about data than XML or 
 PDF.  Same goes for JSON.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6937) In schemaless mode, field names with spaces should be converted

2015-01-13 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14275418#comment-14275418
 ] 

Grant Ingersoll commented on SOLR-6937:
---

+1

 In schemaless mode, field names with spaces should be converted
 ---

 Key: SOLR-6937
 URL: https://issues.apache.org/jira/browse/SOLR-6937
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Reporter: Grant Ingersoll
Assignee: Noble Paul
 Fix For: 5.0

 Attachments: SOLR-6937.patch


 Assuming spaces in field names are still bad, we should automatically convert 
 them to not have spaces.  For instance, I indexed Citibike public data set 
 which has: 
 {quote}
 tripduration,starttime,stoptime,start station id,start station 
 name,start station latitude,start station longitude,end station 
 id,end station name,end station latitude,end station 
 longitude,bikeid,usertype,birth year,gender{quote}
 My vote would be to replace spaces w/ underscores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6965) Consider passing MIME-type info into field guessing capabilities

2015-01-12 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14273616#comment-14273616
 ] 

Grant Ingersoll commented on SOLR-6965:
---

Sorry, more structured is the wrong wording here.  I meant to say CSV is a 
bit more straightforward about guessing, I think.  Obviously, with all of this 
stuff, there are exceptions.  Just trying to hit the sweet spot of right most 
of the time for most situations, esp. the OOTB experience.

 Consider passing MIME-type info into field guessing capabilities
 

 Key: SOLR-6965
 URL: https://issues.apache.org/jira/browse/SOLR-6965
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll

 In digging in on data-driven/field guessing/schemaless a bit more, my gut 
 instinct after staring at lots of different file types is that we should, if 
 possible, pass MIME type info through to the guessing mechanism so that we 
 can potentially make different choices for different types.  For instance, 
 CSV is much more structured and can likely be smarter about data than XML or 
 PDF.  Same goes for JSON.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6965) Consider passing MIME-type info into field guessing capabilities

2015-01-12 Thread Grant Ingersoll (JIRA)

Grant Ingersoll created SOLR-6965:
-

 Summary: Consider passing MIME-type info into field guessing 
capabilities
 Key: SOLR-6965
 URL: https://issues.apache.org/jira/browse/SOLR-6965
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll


In digging in on data-driven/field guessing/schemaless a bit more, my gut 
instinct after staring at lots of different file types is that we should, if 
possible, pass MIME type info through to the guessing mechanism so that we can 
potentially make different choices for different types.  For instance, CSV is 
much more structured and can likely be smarter about data than XML or PDF.  
Same goes for JSON.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6966) For Data Driven Schema, consider multi-word text fields to be text, not string field types

2015-01-12 Thread Grant Ingersoll (JIRA)

Grant Ingersoll created SOLR-6966:
-

 Summary: For Data Driven Schema, consider multi-word text fields 
to be text, not string field types
 Key: SOLR-6966
 URL: https://issues.apache.org/jira/browse/SOLR-6966
 Project: Solr
  Issue Type: Improvement
Reporter: Grant Ingersoll


A tricky situation, for sure, but I suspect in data-driven mode, when field 
guessing, we should treat multi-word strings as text by default, not String, so 
that the user's first experience is they can search against that field.

Alternatively, create a second field that is either the String version or the 
Text version.

Even more advanced option: use pseudo-fields (like what we do for some spatial) 
and intelligently use one or the other depending on the context: e.g. faceting 
uses the one form, search uses the other.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6952) Copying data-driven configsets by default is not helpful

2015-01-10 Thread Grant Ingersoll (JIRA)

Grant Ingersoll created SOLR-6952:
-

 Summary: Copying data-driven configsets by default is not helpful
 Key: SOLR-6952
 URL: https://issues.apache.org/jira/browse/SOLR-6952
 Project: Solr
  Issue Type: Bug
Reporter: Grant Ingersoll


When creating collections (I'm using the bin/solr scripts), I don't think we 
should automatically copy configsets, especially when running in getting 
started mode or data driven mode.

I did the following:
{code}
bin/solr create_collection -n foo
bin/post foo some_data.csv
{code}

I then created a second collection with the intention of sending in the same 
data, but this time run through a python script that changed a value from an 
int to a string (since it was an enumerated type) and was surprised to see that 
I got:
{quote}
Caused by: java.lang.NumberFormatException: For input string: NA
at 
java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:441)
{quote}

for my new version of the data that passes in a string instead of an int, as 
this new collection had only seen strings for that field.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6952) Copying data-driven configsets by default is not helpful

2015-01-10 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14272559#comment-14272559
 ] 

Grant Ingersoll commented on SOLR-6952:
---

To work around this, I tried this from a clean install:

# bin/solr -cloud
# bin/solr create_collectioin foo
# bin/solr create_collection foo2

I then indexed the data to foo using the ints and then followed up and indexed 
to foo2 using the Strings and much to my dismay, I got the same error and have 
come to find out that the configset is  being shared.  This is bad, IMO.  At a 
minimum, data-driven configsets should be copied from the default template and 
we should never modify the base template for a specific instance.   Not sure on 
the other ones, but my gut says we should copy, not modify.

 Copying data-driven configsets by default is not helpful
 

 Key: SOLR-6952
 URL: https://issues.apache.org/jira/browse/SOLR-6952
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 5.0
Reporter: Grant Ingersoll
 Fix For: 5.0


 When creating collections (I'm using the bin/solr scripts), I don't think we 
 should automatically copy configsets, especially when running in getting 
 started mode or data driven mode.
 I did the following:
 {code}
 bin/solr create_collection -n foo
 bin/post foo some_data.csv
 {code}
 I then created a second collection with the intention of sending in the same 
 data, but this time run through a python script that changed a value from an 
 int to a string (since it was an enumerated type) and was surprised to see 
 that I got:
 {quote}
 Caused by: java.lang.NumberFormatException: For input string: NA
   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
   at java.lang.Long.parseLong(Long.java:441)
 {quote}
 for my new version of the data that passes in a string instead of an int, as 
 this new collection had only seen strings for that field.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6952) Copying data-driven configsets by default is not helpful

2015-01-10 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll updated SOLR-6952:
--
  Component/s: Schema and Analysis
Affects Version/s: 5.0
Fix Version/s: 5.0

 Copying data-driven configsets by default is not helpful
 

 Key: SOLR-6952
 URL: https://issues.apache.org/jira/browse/SOLR-6952
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Affects Versions: 5.0
Reporter: Grant Ingersoll
 Fix For: 5.0


 When creating collections (I'm using the bin/solr scripts), I don't think we 
 should automatically copy configsets, especially when running in getting 
 started mode or data driven mode.
 I did the following:
 {code}
 bin/solr create_collection -n foo
 bin/post foo some_data.csv
 {code}
 I then created a second collection with the intention of sending in the same 
 data, but this time run through a python script that changed a value from an 
 int to a string (since it was an enumerated type) and was surprised to see 
 that I got:
 {quote}
 Caused by: java.lang.NumberFormatException: For input string: NA
   at 
 java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
   at java.lang.Long.parseLong(Long.java:441)
 {quote}
 for my new version of the data that passes in a string instead of an int, as 
 this new collection had only seen strings for that field.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6913) audit cleanup schema in data_driven_schema_configs


[ 
https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14271487#comment-14271487
 ] 

Grant Ingersoll commented on SOLR-6913:
---

bq. My thinking was that the schemaless example should be minimal. In 
particular, if we don't have a way for field types to be used (via 
(dynamic)field definitions or field guessing), why include them? If the user 
can add fields, they can add field types too.

The main issue is that OOTB, this is the default and it thus leaves us pretty 
underpowered for an OOTB experience.  Those Field Types have been in Solr for a 
long time and I think they hold up reasonably well, so I would vote for putting 
them back in.

I think the big difference is, Solr experts come at the situation from edit 
schema/config first.  New users come at data stores as let me manipulate my 
data first and then harden it later.

 audit  cleanup schema in data_driven_schema_configs
 --

 Key: SOLR-6913
 URL: https://issues.apache.org/jira/browse/SOLR-6913
 Project: Solr
  Issue Type: Task
Reporter: Hoss Man
Assignee: Steve Rowe
Priority: Blocker
 Fix For: 5.0, Trunk

 Attachments: SOLR-6913-trim-schema.patch, 
 SOLR-6913-trim-schema.patch, SOLR-6913.patch


 the data_driven_schema_configs configset has some issues that should be 
 reviewed carefully  cleaned up...
 * currentkly includes a schema.xml file:
 ** this was previously pat of the old example to show the automatic 
 bootstraping of schema.xml - managed-schema, but at this point it's just 
 kind of confusing
 ** we should just rename this to managed-schema in svn - the ref guide 
 explains the bootstraping
 * the effective schema as it currently stands includes a bunch of copyFields 
  dynamicFields that are taken wholesale from the techproducts example
 ** some of these might make sense to keep in a general example (ie: \*_txt) 
 but in general they should all be reviewed.
 ** a bunch of this cruft is actually commented out already, but anything we 
 don't want to keep should be removed to eliminate confusion
 * SOLR-6471 added an explicit _text field as the default and made it a 
 copyField catchall (ie: \*)
 ** the ref guide schema API example responses need to reflect the existence 
 of this field: 
 https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode
 ** we should draw heavy attention to this field+copyField -- both with a /!\ 
 NOTE in the refguide and call it out in solrconfig.xml  managed-schema 
 file comments since people who start with these configs may be suprised and 
 wind up with a very bloated index



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6913) audit cleanup schema in data_driven_schema_configs


[ 
https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14271499#comment-14271499
 ] 

Grant Ingersoll commented on SOLR-6913:
---

IOW, it's not about schemaless, it's about schema-later

 audit  cleanup schema in data_driven_schema_configs
 --

 Key: SOLR-6913
 URL: https://issues.apache.org/jira/browse/SOLR-6913
 Project: Solr
  Issue Type: Task
Reporter: Hoss Man
Assignee: Steve Rowe
Priority: Blocker
 Fix For: 5.0, Trunk

 Attachments: SOLR-6913-trim-schema.patch, 
 SOLR-6913-trim-schema.patch, SOLR-6913.patch


 the data_driven_schema_configs configset has some issues that should be 
 reviewed carefully  cleaned up...
 * currentkly includes a schema.xml file:
 ** this was previously pat of the old example to show the automatic 
 bootstraping of schema.xml - managed-schema, but at this point it's just 
 kind of confusing
 ** we should just rename this to managed-schema in svn - the ref guide 
 explains the bootstraping
 * the effective schema as it currently stands includes a bunch of copyFields 
  dynamicFields that are taken wholesale from the techproducts example
 ** some of these might make sense to keep in a general example (ie: \*_txt) 
 but in general they should all be reviewed.
 ** a bunch of this cruft is actually commented out already, but anything we 
 don't want to keep should be removed to eliminate confusion
 * SOLR-6471 added an explicit _text field as the default and made it a 
 copyField catchall (ie: \*)
 ** the ref guide schema API example responses need to reflect the existence 
 of this field: 
 https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode
 ** we should draw heavy attention to this field+copyField -- both with a /!\ 
 NOTE in the refguide and call it out in solrconfig.xml  managed-schema 
 file comments since people who start with these configs may be suprised and 
 wind up with a very bloated index



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6913) audit cleanup schema in data_driven_schema_configs


[ 
https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14271806#comment-14271806
 ] 

Grant Ingersoll commented on SOLR-6913:
---

Awesome, thanks Steve!

 audit  cleanup schema in data_driven_schema_configs
 --

 Key: SOLR-6913
 URL: https://issues.apache.org/jira/browse/SOLR-6913
 Project: Solr
  Issue Type: Task
Reporter: Hoss Man
Assignee: Steve Rowe
Priority: Blocker
 Fix For: 5.0, Trunk

 Attachments: SOLR-6913-trim-schema.patch, 
 SOLR-6913-trim-schema.patch, SOLR-6913.patch


 the data_driven_schema_configs configset has some issues that should be 
 reviewed carefully  cleaned up...
 * currentkly includes a schema.xml file:
 ** this was previously pat of the old example to show the automatic 
 bootstraping of schema.xml - managed-schema, but at this point it's just 
 kind of confusing
 ** we should just rename this to managed-schema in svn - the ref guide 
 explains the bootstraping
 * the effective schema as it currently stands includes a bunch of copyFields 
  dynamicFields that are taken wholesale from the techproducts example
 ** some of these might make sense to keep in a general example (ie: \*_txt) 
 but in general they should all be reviewed.
 ** a bunch of this cruft is actually commented out already, but anything we 
 don't want to keep should be removed to eliminate confusion
 * SOLR-6471 added an explicit _text field as the default and made it a 
 copyField catchall (ie: \*)
 ** the ref guide schema API example responses need to reflect the existence 
 of this field: 
 https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode
 ** we should draw heavy attention to this field+copyField -- both with a /!\ 
 NOTE in the refguide and call it out in solrconfig.xml  managed-schema 
 file comments since people who start with these configs may be suprised and 
 wind up with a very bloated index



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6940) Query UI in admin should support other facet options

Grant Ingersoll created SOLR-6940:
-

 Summary: Query UI in admin should support other facet options
 Key: SOLR-6940
 URL: https://issues.apache.org/jira/browse/SOLR-6940
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Grant Ingersoll


As of right now in the Admin Query UI, you can only easily provide facet 
options for field, query and prefix.  It would be nice to have easy to use 
options for pivots, ranges, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6913) audit cleanup schema in data_driven_schema_configs


[ 
https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270989#comment-14270989
 ] 

Grant Ingersoll commented on SOLR-6913:
---

I'd vote for returning:

# geo related
# currency
# Language support

Indifferent on the rest.

 audit  cleanup schema in data_driven_schema_configs
 --

 Key: SOLR-6913
 URL: https://issues.apache.org/jira/browse/SOLR-6913
 Project: Solr
  Issue Type: Task
Reporter: Hoss Man
Assignee: Steve Rowe
Priority: Blocker
 Fix For: 5.0, Trunk

 Attachments: SOLR-6913-trim-schema.patch, 
 SOLR-6913-trim-schema.patch, SOLR-6913.patch


 the data_driven_schema_configs configset has some issues that should be 
 reviewed carefully  cleaned up...
 * currentkly includes a schema.xml file:
 ** this was previously pat of the old example to show the automatic 
 bootstraping of schema.xml - managed-schema, but at this point it's just 
 kind of confusing
 ** we should just rename this to managed-schema in svn - the ref guide 
 explains the bootstraping
 * the effective schema as it currently stands includes a bunch of copyFields 
  dynamicFields that are taken wholesale from the techproducts example
 ** some of these might make sense to keep in a general example (ie: \*_txt) 
 but in general they should all be reviewed.
 ** a bunch of this cruft is actually commented out already, but anything we 
 don't want to keep should be removed to eliminate confusion
 * SOLR-6471 added an explicit _text field as the default and made it a 
 copyField catchall (ie: \*)
 ** the ref guide schema API example responses need to reflect the existence 
 of this field: 
 https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode
 ** we should draw heavy attention to this field+copyField -- both with a /!\ 
 NOTE in the refguide and call it out in solrconfig.xml  managed-schema 
 file comments since people who start with these configs may be suprised and 
 wind up with a very bloated index



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6764) Can't index exampledocs/*.xml into collection based on the data_driven_schema_configs configset


[ 
https://issues.apache.org/jira/browse/SOLR-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270974#comment-14270974
 ] 

Grant Ingersoll commented on SOLR-6764:
---

Path works for me.  Didn't do exhaustive testing, but w/ the data set I had I 
got this every time.  Now I don't.

 Can't index exampledocs/*.xml into collection based on the 
 data_driven_schema_configs configset
 ---

 Key: SOLR-6764
 URL: https://issues.apache.org/jira/browse/SOLR-6764
 Project: Solr
  Issue Type: Bug
Reporter: Timothy Potter
Assignee: Timothy Potter
 Attachments: SOLR-6764.patch


 This is exactly what we don't want ;-) Fire up a collection that uses the 
 data_driven_schema_configs (such as by doing: bin/solr -e cloud -noprompt) 
 and then try to index our example docs using:
 $ java -Durl=http://localhost:8983/solr/gettingstarted/update -jar post.jar 
 *.xml
 Here goes the spew ...
 SimplePostTool version 1.5
 Posting files to base url http://localhost:8983/solr/gettingstarted/update 
 using content-type application/xml..
 POSTing file gb18030-example.xml
 POSTing file hd.xml
 SimplePostTool: WARNING: Solr returned an error #500 (Server Error) for url: 
 http://localhost:8983/solr/gettingstarted/update
 SimplePostTool: WARNING: Response: ?xml version=1.0 encoding=UTF-8?
 response
 lst name=responseHeaderint name=status500/intint 
 name=QTime19/int/lstlst name=errorstr name=msgServer Error
 request: 
 http://192.168.1.2:8983/solr/gettingstarted_shard2_replica2/update?update.chain=add-unknown-fields-to-the-schemaamp;update.distrib=TOLEADERamp;distrib.from=http%3A%2F%2F192.168.1.2%3A8983%2Fsolr%2Fgettingstarted_shard1_replica2%2Famp;wt=javabinamp;version=2/strstr
  name=traceorg.apache.solr.common.SolrException: Server Error
 request: 
 http://192.168.1.2:8983/solr/gettingstarted_shard2_replica2/update?update.chain=add-unknown-fields-to-the-schemaamp;update.distrib=TOLEADERamp;distrib.from=http%3A%2F%2F192.168.1.2%3A8983%2Fsolr%2Fgettingstarted_shard1_replica2%2Famp;wt=javabinamp;version=2
   at 
 org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer$Runner.run(ConcurrentUpdateSolrServer.java:241)
   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
   at java.lang.Thread.run(Thread.java:745)
 /strint name=code500/int/lst
 /response
 SimplePostTool: WARNING: IOException while reading response: 
 java.io.IOException: Server returned HTTP response code: 500 for URL: 
 http://localhost:8983/solr/gettingstarted/update
 POSTing file ipod_other.xml
 SimplePostTool: WARNING: Solr returned an error #400 (Bad Request) for url: 
 http://localhost:8983/solr/gettingstarted/update
 SimplePostTool: WARNING: Response: ?xml version=1.0 encoding=UTF-8?
 response
 lst name=responseHeaderint name=status400/intint 
 name=QTime630/int/lstlst name=errorstr name=msgERROR: 
 [doc=IW-02] Error adding field 'price'='11.50' msg=For input string: 
 11.50/strint name=code400/int/lst
 /response
 SimplePostTool: WARNING: IOException while reading response: 
 java.io.IOException: Server returned HTTP response code: 400 for URL: 
 http://localhost:8983/solr/gettingstarted/update
 POSTing file ipod_video.xml
 SimplePostTool: WARNING: Solr returned an error #400 (Bad Request) for url: 
 http://localhost:8983/solr/gettingstarted/update
 SimplePostTool: WARNING: Response: ?xml version=1.0 encoding=UTF-8?
 response
 lst name=responseHeaderint name=status400/intint 
 name=QTime5/int/lstlst name=errorstr name=msgERROR: 
 [doc=MA147LL/A] Error adding field 'weight'='5.5' msg=For input string: 
 5.5/strint name=code400/int/lst
 /response
 SimplePostTool: WARNING: IOException while reading response: 
 java.io.IOException: Server returned HTTP response code: 400 for URL: 
 http://localhost:8983/solr/gettingstarted/update
 POSTing file manufacturers.xml
 SimplePostTool: WARNING: Solr returned an error #500 (Server Error) for url: 
 http://localhost:8983/solr/gettingstarted/update
 SimplePostTool: WARNING: Response: ?xml version=1.0 encoding=UTF-8?
 response
 lst name=responseHeaderint name=status500/intint 
 name=QTime2/int/lstlst name=errorstr name=msgException writing 
 document id adata to the index; possible analysis error./strstr 
 name=traceorg.apache.solr.common.SolrException: Exception writing document 
 id adata to the index; possible analysis error.
   at 
 org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:168)
   at 
 org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
   at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java

[jira] [Commented] (SOLR-6913) audit cleanup schema in data_driven_schema_configs


[ 
https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270978#comment-14270978
 ] 

Grant Ingersoll commented on SOLR-6913:
---

What's the reasoning behind removing so many of the field types?  

 audit  cleanup schema in data_driven_schema_configs
 --

 Key: SOLR-6913
 URL: https://issues.apache.org/jira/browse/SOLR-6913
 Project: Solr
  Issue Type: Task
Reporter: Hoss Man
Assignee: Steve Rowe
Priority: Blocker
 Fix For: 5.0, Trunk

 Attachments: SOLR-6913-trim-schema.patch, 
 SOLR-6913-trim-schema.patch, SOLR-6913.patch


 the data_driven_schema_configs configset has some issues that should be 
 reviewed carefully  cleaned up...
 * currentkly includes a schema.xml file:
 ** this was previously pat of the old example to show the automatic 
 bootstraping of schema.xml - managed-schema, but at this point it's just 
 kind of confusing
 ** we should just rename this to managed-schema in svn - the ref guide 
 explains the bootstraping
 * the effective schema as it currently stands includes a bunch of copyFields 
  dynamicFields that are taken wholesale from the techproducts example
 ** some of these might make sense to keep in a general example (ie: \*_txt) 
 but in general they should all be reviewed.
 ** a bunch of this cruft is actually commented out already, but anything we 
 don't want to keep should be removed to eliminate confusion
 * SOLR-6471 added an explicit _text field as the default and made it a 
 copyField catchall (ie: \*)
 ** the ref guide schema API example responses need to reflect the existence 
 of this field: 
 https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode
 ** we should draw heavy attention to this field+copyField -- both with a /!\ 
 NOTE in the refguide and call it out in solrconfig.xml  managed-schema 
 file comments since people who start with these configs may be suprised and 
 wind up with a very bloated index



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6913) audit cleanup schema in data_driven_schema_configs


[ 
https://issues.apache.org/jira/browse/SOLR-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270981#comment-14270981
 ] 

Grant Ingersoll commented on SOLR-6913:
---

I think the regular workflow for exploring new datasets is to just start 
throwing it at Solr and then to tweak the data, not tweak the schema.  Data 
first, schema second.  So, for instance, I'm working on this citibike data.  My 
first step is to index it w/ no schema whatsoever.  I then iterate by writing a 
little python to index some of the columns as spatial.  What I don't do is go 
muck w/ the schema, hence the name data-driven.

 audit  cleanup schema in data_driven_schema_configs
 --

 Key: SOLR-6913
 URL: https://issues.apache.org/jira/browse/SOLR-6913
 Project: Solr
  Issue Type: Task
Reporter: Hoss Man
Assignee: Steve Rowe
Priority: Blocker
 Fix For: 5.0, Trunk

 Attachments: SOLR-6913-trim-schema.patch, 
 SOLR-6913-trim-schema.patch, SOLR-6913.patch


 the data_driven_schema_configs configset has some issues that should be 
 reviewed carefully  cleaned up...
 * currentkly includes a schema.xml file:
 ** this was previously pat of the old example to show the automatic 
 bootstraping of schema.xml - managed-schema, but at this point it's just 
 kind of confusing
 ** we should just rename this to managed-schema in svn - the ref guide 
 explains the bootstraping
 * the effective schema as it currently stands includes a bunch of copyFields 
  dynamicFields that are taken wholesale from the techproducts example
 ** some of these might make sense to keep in a general example (ie: \*_txt) 
 but in general they should all be reviewed.
 ** a bunch of this cruft is actually commented out already, but anything we 
 don't want to keep should be removed to eliminate confusion
 * SOLR-6471 added an explicit _text field as the default and made it a 
 copyField catchall (ie: \*)
 ** the ref guide schema API example responses need to reflect the existence 
 of this field: 
 https://cwiki.apache.org/confluence/display/solr/Schemaless+Mode
 ** we should draw heavy attention to this field+copyField -- both with a /!\ 
 NOTE in the refguide and call it out in solrconfig.xml  managed-schema 
 file comments since people who start with these configs may be suprised and 
 wind up with a very bloated index



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Created] (SOLR-6937) In schemaless mode, field names with spaces should be converted

Grant Ingersoll created SOLR-6937:
-

 Summary: In schemaless mode, field names with spaces should be 
converted
 Key: SOLR-6937
 URL: https://issues.apache.org/jira/browse/SOLR-6937
 Project: Solr
  Issue Type: Bug
Reporter: Grant Ingersoll


Assuming spaces in field names are still bad, we should automatically convert 
them to not have spaces.  For instance, I indexed Citibike public data set 
which has: 
{quote}
tripduration,starttime,stoptime,start station id,start station 
name,start station latitude,start station longitude,end station id,end 
station name,end station latitude,end station 
longitude,bikeid,usertype,birth year,gender{quote}

My vote would be to replace spaces w/ underscores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Updated] (SOLR-6937) In schemaless mode, field names with spaces should be converted


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

Grant Ingersoll updated SOLR-6937:
--
  Component/s: Schema and Analysis
Fix Version/s: 5.0

 In schemaless mode, field names with spaces should be converted
 ---

 Key: SOLR-6937
 URL: https://issues.apache.org/jira/browse/SOLR-6937
 Project: Solr
  Issue Type: Bug
  Components: Schema and Analysis
Reporter: Grant Ingersoll
 Fix For: 5.0


 Assuming spaces in field names are still bad, we should automatically convert 
 them to not have spaces.  For instance, I indexed Citibike public data set 
 which has: 
 {quote}
 tripduration,starttime,stoptime,start station id,start station 
 name,start station latitude,start station longitude,end station 
 id,end station name,end station latitude,end station 
 longitude,bikeid,usertype,birth year,gender{quote}
 My vote would be to replace spaces w/ underscores.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6933) bin/solr script should just have a single create action that creates a core or collection depending on the mode solr is running in


[ 
https://issues.apache.org/jira/browse/SOLR-6933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270479#comment-14270479
 ] 

Grant Ingersoll commented on SOLR-6933:
---

bq. and instead adding a new create that delegates to them as needed.

+1

bq.  First, what does the usage (bin/solr create -help) say? Options like 
-shards, -maxShardsPerNode, -replicationFactor don't apply when creating a 
core. 

If we are just delegating, than can we delegate to the underlying help too?

bq. I think the script should error out and tell the user that option is only 
when running in cloud mode.

 +1

bq. So if we think there's real benefit to having a create alias 

+1

 bin/solr script should just have a single create action that creates a core 
 or collection depending on the mode solr is running in
 --

 Key: SOLR-6933
 URL: https://issues.apache.org/jira/browse/SOLR-6933
 Project: Solr
  Issue Type: Improvement
  Components: scripts and tools
Reporter: Timothy Potter
Assignee: Timothy Potter

 instead of create_core and create_collection, just have create that creates a 
 core or a collection based on which mode Solr is running in.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


[ 
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14269740#comment-14269740
 ] 

Grant Ingersoll commented on SOLR-3619:
---

My pref would be:

bin/solr create name and we handle the cloud logic under the scenes.

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

 Key: SOLR-3619
 URL: https://issues.apache.org/jira/browse/SOLR-3619
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Timothy Potter
 Fix For: 5.0, Trunk

 Attachments: SOLR-3619.patch, SOLR-3619.patch, SOLR-3619.patch, 
 managed-schema, server-name-layout.png, solrconfig.xml






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory


[ 
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14269733#comment-14269733
 ] 

Grant Ingersoll commented on SOLR-3619:
---

First off, love the new stuff!

Coming a little late to the party, but just now finally checking this out.  So, 
I built the distro, copied it to a new directory and unpacked it.

I then went to the README which is the first thing I do for any new software 
(as I suspect most devs do) and here's what I see:

{quote}
This will launch a Solr server in the background of your shell, bound
to port 8983. After starting Solr, you can create a new core for indexing
your data by doing:

  bin/solr create_core -n name
{quote}

and then a few lines later:

{quote}
After starting Solr in cloud mode, you can create a new collection for indexing
your data by doing:

  bin/solr create_collection -n name
{quote}

You've already lost me (well, not me, literally, but noobs, I'm sure).  What 
the heck is the diff between a collection and a core and why should I care so 
early on?  Why should I have to know that distinction at this stage of the 
game?  I get that it relates to the Collections API and cloud mode, but I'm a 
new user and that distinction, in my estimation, is at least a day or two away 
(and hopefully is resolved at some point and becomes a non-issue) at which time 
it can be explained via the Docs in the ref guide.

Just my 2 cents.  

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

 Key: SOLR-3619
 URL: https://issues.apache.org/jira/browse/SOLR-3619
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Timothy Potter
 Fix For: 5.0, Trunk

 Attachments: SOLR-3619.patch, SOLR-3619.patch, SOLR-3619.patch, 
 managed-schema, server-name-layout.png, solrconfig.xml






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6764) Can't index exampledocs/*.xml into collection based on the data_driven_schema_configs configset


[ 
https://issues.apache.org/jira/browse/SOLR-6764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270035#comment-14270035
 ] 

Grant Ingersoll commented on SOLR-6764:
---

I'm seeing similar when I try to index the Citibike data out of the box: 
http://www.citibikenyc.com/system-data

I did:

{code}
bin/solr start -cloud
bin/solr create_collection -n citi
bin/post citi ~/projects/content/citi-bike/2013-07-CitiBiketripdata.csv 
{code}

Seeing: 

{quote}
ERROR - 2015-01-08 20:47:00.973; org.apache.solr.common.SolrException; 
org.apache.solr.common.SolrException: Exception writing document id 
662e0607-6fd2-4ecc-91f1-40384cf232e3 to the index; possible analysis error.
at 
org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:171)
at 
org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:69)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.AddSchemaFieldsUpdateProcessorFactory$AddSchemaFieldsUpdateProcessor.processAdd(AddSchemaFieldsUpdateProcessorFactory.java:328)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.FieldMutatingUpdateProcessor.processAdd(FieldMutatingUpdateProcessor.java:117)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalAdd(DistributedUpdateProcessor.java:931)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.versionAdd(DistributedUpdateProcessor.java:1085)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:697)
at 
org.apache.solr.update.processor.LogUpdateProcessor.processAdd(LogUpdateProcessorFactory.java:104)
at 
org.apache.solr.update.processor.UpdateRequestProcessor.processAdd(UpdateRequestProcessor.java:51)
at 
org.apache.solr.update.processor.AbstractDefaultValueUpdateProcessorFactory$DefaultValueUpdateProcessor.processAdd(AbstractDefaultValueUpdateProcessorFactory.java:94)
at 
org.apache.solr.handler.loader.CSVLoaderBase.doAdd(CSVLoaderBase.java:395)
at 
org.apache.solr.handler.loader.SingleThreadedCSVLoader.addDoc(CSVLoader.java:44)
at 
org.apache.solr.handler.loader.CSVLoaderBase.load(CSVLoaderBase.java:364)
at org.apache.solr.handler.loader.CSVLoader.load(CSVLoader.java:31)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:103)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:144)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2005)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:779)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:414)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:201)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope

[jira] [Comment Edited] (SOLR-6900) bin/post improvements needed


[ 
https://issues.apache.org/jira/browse/SOLR-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270021#comment-14270021
 ] 

Grant Ingersoll edited comment on SOLR-6900 at 1/8/15 8:45 PM:
---

I tried:
{code}
bin/post citi /foo/projects/content/citi-bike/2013-07 - Citi Bike trip 
data.csv
bin/post citi /foo/projects/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ 
bin/post citi /foo/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ data.csv
{code}

All failed w/ errors in parsing spaces.


was (Author: gsingers):
I tried:
{code}
bin/post citi /foo/projects/content/citi-bike/2013-07 - Citi Bike trip 
data.csv
bin/post citi /foo/projects/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ 
bin/post citi /foo/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ data.csv
{code}

 bin/post improvements needed
 

 Key: SOLR-6900
 URL: https://issues.apache.org/jira/browse/SOLR-6900
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0, Trunk
Reporter: Erik Hatcher
Assignee: Erik Hatcher
 Fix For: 5.0, Trunk


 * Fix glob patterns.  They don't work as expected: bin/post collection1 
 \*.xml expands \*.xml such that the script gets all the file names as 
 parameters not just literally \*.xml
 * Add error handling to check that the collection exists
 * Create Windows version



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6900) bin/post improvements needed


[ 
https://issues.apache.org/jira/browse/SOLR-6900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14270021#comment-14270021
 ] 

Grant Ingersoll commented on SOLR-6900:
---

I tried:
{code}
bin/post citi /foo/projects/content/citi-bike/2013-07 - Citi Bike trip 
data.csv
bin/post citi /foo/projects/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ 
bin/post citi /foo/content/citi-bike/2013-07\ -\ Citi\ Bike\ trip\ data.csv
{code}

 bin/post improvements needed
 

 Key: SOLR-6900
 URL: https://issues.apache.org/jira/browse/SOLR-6900
 Project: Solr
  Issue Type: Bug
Affects Versions: 5.0, Trunk
Reporter: Erik Hatcher
Assignee: Erik Hatcher
 Fix For: 5.0, Trunk


 * Fix glob patterns.  They don't work as expected: bin/post collection1 
 \*.xml expands \*.xml such that the script gets all the file names as 
 parameters not just literally \*.xml
 * Add error handling to check that the collection exists
 * Create Windows version



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website

2014-11-08 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14203423#comment-14203423
 ] 

Grant Ingersoll commented on SOLR-6058:
---

Getting really close.   I think the main thing left is the tutorial and 
proof-reading.  As I've said earlier, I'd like to finish up and go live on 
tomorrow or Monday.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website

2014-11-06 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14200071#comment-14200071
 ] 

Grant Ingersoll commented on SOLR-6058:
---

[~sbower] Thanks!

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198153#comment-14198153
 ] 

Grant Ingersoll commented on SOLR-6058:
---

For those watching this issue, we've noticed some weird behavior with certain 
browsers and I was wondering if others could report if they see it to.

On the main page (solr-index.html), under the Learn More About Solr section, 
the links to learn more about Features, Resources, etc. don't always work 
when you hover over the box.  For instance, on Chrome when I look at 
http://lucene.lukesh.com/solr/, I can't click on any of those items.  Strangely 
enough, if I open the Chrome Developer Tools or view the page source, I can.  
Additionally, when I look at my own local copy, I don't have any trouble.  
Links also seem to work in Firefox, but don't always work in Safari.  I know 
[~steve_rowe] has said he has had similar failures as well.

Can people report back here whether they are seeing it or whether it is perhaps 
some sort of caching bug, perhaps?

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198181#comment-14198181
 ] 

Grant Ingersoll commented on SOLR-6058:
---

The really odd thing, is the Getting Started section further below is more or 
less the same and it works fine. 

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198230#comment-14198230
 ] 

Grant Ingersoll commented on SOLR-6058:
---

More oddities:  If you zoom in (to like 125%) using Chrome on these links 
(apple-+ on Mac), then they work just fine.  

I've also notice that if you go slowly from the bottom of the element, you can 
get it to highlight.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198232#comment-14198232
 ] 

Grant Ingersoll commented on SOLR-6058:
---

More fun: if you zoom out w/ Dev Tools on, than you can incur the same bad 
behavior.  Seems like there has to be an open tag or something.  I did a 
validation of the page and it seems fine.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198248#comment-14198248
 ] 

Grant Ingersoll commented on SOLR-6058:
---

Hmm: 
http://stackoverflow.com/questions/6393827/can-i-nest-a-button-element-inside-an-a-using-html5
 may be the cause?

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198290#comment-14198290
 ] 

Grant Ingersoll commented on SOLR-6058:
---

Starting to think the issue is the interaction with the div and the a tag on 
those links.  It seems there is some oddities in how it is handling the nested 
div in the a tag.  Hard to explain, but if you hover the mouse in the correct 
place, you'll see the a tag can be selected to the left of the main box area.  
You can see this further by putting some junk text in the a tag, but outside of 
the nested div, as in:
{code}
a href=/solr/features.htmldiv class=boxFoo
div class=imgimg 
src=/solr/assets/images/icon-features.svg//div
div class=title
  h3Features/h3
/div
pHundreds of features make Solr incredibly versatile./p
span class=btn1Learn More/span
  /div/a
{code}

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198475#comment-14198475
 ] 

Grant Ingersoll commented on SOLR-6058:
---

OK, talked w/ [~steve_rowe] and he figured out that this issue is tied to the 
offset class that is on the section here.  It causes the hover view part of it 
to be clipped at the bottom.  This is most exacerbated when you zoom out 
(50%-75% or original)  This happens across Chrome, Safari and FF.

[~FranLukesh]   

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198548#comment-14198548
 ] 

Grant Ingersoll commented on SOLR-6058:
---

[~sbower] any luck on the logo permission?  We'd like to go live by this 
weekend.  At some level, the fact that Bloomberg is a Solr user is a factual 
statement and doesn't require permission since it is public knowledge based off 
presentations, etc., but I do understand the use of a logo may not be the 
equivalent to that, so I'd rather make sure Bloomberg is OK with it.  I can 
remove it if we can't get permission in time or we can switch to a factual 
statement.

FWIW, I'd love to put highlight Bloomberg as a Solr case study somewhere on the 
Solr site if you are willing to do so.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14198588#comment-14198588
 ] 

Grant Ingersoll commented on SOLR-6058:
---

OK, this is getting really close to done.  I think we just have some issues 
left on the Detailed Features section and the tutorial for content.  After 
that, a full read through, grammar, spelling, etc. and we are good to go.  We 
also still need to figure out the links thing due to offsets on the main page 
(and other places, I presume)

Pending those things completing, I intend to merge this to trunk and push this 
live over the weekend, as this has been baking for some time now and is very 
close to ready to go.  We can always improve later.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 SOLR-6058.offset-fix.patch, Solr_Icons.pdf, Solr_Logo_on_black.pdf, 
 Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, 
 Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Assigned] (SOLR-6081) Hook in Videos, Books, Reference work

2014-11-04 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll reassigned SOLR-6081:
-

Assignee: Grant Ingersoll

 Hook in Videos, Books, Reference work
 -

 Key: SOLR-6081
 URL: https://issues.apache.org/jira/browse/SOLR-6081
 Project: Solr
  Issue Type: Sub-task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll

 There is a ton of great content available on Solr in the interwebs, let's 
 make it easy to highlight this content so users know their is a large 
 community ready to assist.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Resolved] (SOLR-6081) Hook in Videos, Books, Reference work

2014-11-04 Thread Grant Ingersoll (JIRA)


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

Grant Ingersoll resolved SOLR-6081.
---
Resolution: Fixed

 Hook in Videos, Books, Reference work
 -

 Key: SOLR-6081
 URL: https://issues.apache.org/jira/browse/SOLR-6081
 Project: Solr
  Issue Type: Sub-task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll

 There is a ton of great content available on Solr in the interwebs, let's 
 make it easy to highlight this content so users know their is a large 
 community ready to assist.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14193091#comment-14193091
 ] 

Grant Ingersoll commented on SOLR-6058:
---

bq.  For Bloomberg, and I suspect other companies as well, will need to have 
the use of our logo approved from a trademark usage perspective. We're happy to 
do this we just need go through the process.

Steven, that would be great if you could see that through!

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, 
 Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, 
 Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14193097#comment-14193097
 ] 

Grant Ingersoll commented on SOLR-6058:
---

Made some progress on the resources page.  I'm going to drop the screenshots 
section, as it will likely be out of date and annoying to maintain.

I would love if someone knew how to bring in a few key videos, presentations, 
etc. and rotate between them so that we can have some clickable content there.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, 
 Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, 
 Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14193115#comment-14193115
 ] 

Grant Ingersoll commented on SOLR-6058:
---

Not quite sure what to do w/ the Documentation section on the Resources page.  
Currently, we link to the docs that ship with the latest release 
(http://lucene.apache.org/solr/4_10_1/index.html) which is kind of clunky, 
albeit accurate.  I like what Fran did for organizing it, but it will suffer 
from a versioning problem.  Personally, I'd prefer to just link the Ref Guide 
and forget linking anything else.

For now, I'm just going to maintain what we have (link to latest release)

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, 
 Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, 
 Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14193239#comment-14193239
 ] 

Grant Ingersoll commented on SOLR-6058:
---

Made a bunch of progress this AM:

# Features page first draft is complete.  TODO: add some more spice to the 
detailed features section with images
# Fixed the download buttons
# Cleaned up some of the resources
# Fixed a bunch of links
# Added Google Analytics to the footer
# Cleaned up the footer with proper links
# Other things I forgot to mention

I'm really hoping we can push this live by the end of the next week (a week 
from today) as most of the core content is in place now with the exception of 
the tutorials.  Naturally, we also need to do a run through of links, spelling 
errors, grammar and more.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, SOLR-6058.location-fix.patchfile, 
 Solr_Icons.pdf, Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, 
 Solr_Logo_on_orange.pdf, Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, 
 Solr_Logo_on_white.png, Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website

2014-10-25 Thread Grant Ingersoll (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14184057#comment-14184057
]

Grant Ingersoll commented on SOLR-6058:
---

bq. From the Solr front page (solr/index.html), under the book cover images,
the Learn More button links to solr/books.html, which is currently empty.
The solr/resources.html page has a books section - should the button in
question link there instead? Should there also be a separate books page sharing
the same content?

I think we should just put it on the resources page and link appropriately.
Would be nice to have the book covers on those pages.

bq. There's a missing logo file: solr/assets/images/logo-eharmony.png, linked
from templates/solr-index.html.

I missed that one. Will add.

bq. On the solr/resources.html page, the links along the top (Tutorial,
Release, Documentation, Books, Links, Screenshots) are supposed to go to
sections on the same page, e.g. Tutorial-#tutorial, but instead when you click
on one of them, the URL is appended with a hash mark, slash, then the fragment
id, e.g. #/tutorial, and then the browser doesn't go where it's supposed to. I
don't see anything in the generated HTML that would cause this - the fragment
URLs in the links on the generated HTML don't include the slash. I've seen this
on lukesh.com, as well as a locally built version of the site, and both via
Safari on OS X and Firefox on Windows 7.

I can look

Solr needs a new website

Key: SOLR-6058
URL: https://issues.apache.org/jira/browse/SOLR-6058
Project: Solr
Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf,
Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf,
Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png,
Solr_Styleguide.pdf

Solr needs a new website: better organization of content, less verbose, more
pleasing graphics, etc.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178261#comment-14178261
 ] 

Grant Ingersoll commented on SOLR-6058:
---

OK, I've committed Fran's original patch on the branch.  [~FranLukesh] any 
chance you can script your original server to automatically apply updates on 
from that branch so others can see the changes we make?  Otherwise, I can do 
the same.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, 
 Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, 
 Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, 
 Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178346#comment-14178346
 ] 

Grant Ingersoll commented on SOLR-6058:
---

[~FranLukesh] One of the things I'd like to figure out, is how to properly link 
back to the Lucene sites, as the nav is a bit weird.  If a user is on 
lucene.a.o and nav's to solr, all of the tabs disappear, which is probably 
somewhat counter-intuitive to the user.  I don't think the tabs fit with the 
new design, but at the same time, it would be good to somehow make it clear how 
to get back.

Also, I uploaded some logos from the Solr Public Servers page.  I could use 
some help making them look right.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, 
 Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, 
 Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, 
 Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178348#comment-14178348
 ] 

Grant Ingersoll commented on SOLR-6058:
---

[~elyograg] Good catch, I will update.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, 
 Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, 
 Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, 
 Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178392#comment-14178392
 ] 

Grant Ingersoll commented on SOLR-6058:
---

My progress for today:
# Added some powered by icons on the front page (still need to be styled)
# Templatized the version annotation at the top of the landing so we can change 
the latest version number in just one place
# Worked a bunch on the features page (features.mdtext).  Left off at the 
Detailed Features section.  [~FranLukesh], note, I put in some TODO 
placeholders on some of the icons in the second section as they are repetitive 
with the first section.

All in all, I'm really liking the look and feel.  I'd hope we can get this live 
in the next two weeks or so.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, 
 Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, 
 Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, 
 Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website

2014-10-20 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14177177#comment-14177177
 ] 

Grant Ingersoll commented on SOLR-6058:
---

I've started a branch for this: 
https://svn.apache.org/repos/asf/lucene/cms/branches/solr_6058 since there will 
be a lot of content to work on and patches will quickly get clumsy.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, 
 Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, 
 Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, 
 Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website

2014-10-17 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14175383#comment-14175383
 ] 

Grant Ingersoll commented on SOLR-6058:
---

Looks great, Fran!  I should be able to find some time to help on content.  
Hopefully others can pitch in, too.  

I have the CMS running locally (finally) and can help others if needed.  
https://github.com/waylan/Python-Markdown/issues/357 may help for anyone that 
runs into trouble w/ the Python Markdown process.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar, SOLR-6058, Solr_Icons.pdf, 
 Solr_Logo_on_black.pdf, Solr_Logo_on_black.png, Solr_Logo_on_orange.pdf, 
 Solr_Logo_on_orange.png, Solr_Logo_on_white.pdf, Solr_Logo_on_white.png, 
 Solr_Styleguide.pdf


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

Re: [VOTE] Move trunk to Java 8

2014-09-21 Thread Grant Ingersoll


On Sep 19, 2014, at 10:23 AM, Yonik Seeley yo...@heliosearch.com wrote:

 On Fri, Sep 19, 2014 at 7:14 AM, Grant Ingersoll gsing...@apache.org wrote:
 People will upgrade when
 the new features they want in the latest release outweigh the mythical pain
 of upgrading a JDK.
 
 Perhaps the technical pain of upgrade is largely mythical, but it's
 real pain for real users who have no say over what version of Java
 they can run (or at a minimum have to jump  through a lot of hoops to
 change the java version).

Fully well aware of this, but trunk is not, by definition released, so there is 
nothing for them to upgrade to.

 
 There is no right answer... it's a judgement call where we should
 weigh all the factors each time we require a new Java version.  People
 may weigh factors differently, but no factor should be dismissed out
 of hand.

Of course not, just saying I personally think trunk should move forward as fast 
as the regular contributors and committers want, which means, we decide/vote 
and then move on based on the outcome and that the branches (4x or 5x or 
whatever) should be slower to make any changes.  People who take years to 
upgrade their JDK also likely take years to upgrade Lucene or Solr or whatever. 
 I'm all for keeping and maintaining older branches for those who don't want to 
upgrade as long as the community is willing to support them.

As for Doug's comments, I think they reflect a time when we only maintained one 
branch and it was more of a forced decision for users.  It isn't as cut and 
dried anymore with multiple branches, services like Solr and ES, etc.  I do 
agree, wholeheartedly however, that we should all be thoughtful and considerate 
of other's opinions in the process.

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

Re: [VOTE] Release 4.9.1 RC1

2014-09-19 Thread Grant Ingersoll

+1

On Sep 18, 2014, at 4:53 AM, Michael McCandless luc...@mikemccandless.com 
wrote:

 Artifacts here:
 http://people.apache.org/~mikemccand/staging_area/lucene-solr-4.9.1-RC1-rev1625909
 
 Smoke tester: python3 -u dev-tools/scripts/smokeTestRelease.py
 http://people.apache.org/~mikemccand/staging_area/lucene-solr-4.9.1-RC1-rev1625909
 1625909 4.9.1 /tmp/smoke491 True
 
 SUCCESS! [0:23:57.460556]
 
 Here's my +1
 
 Mike McCandless
 
 http://blog.mikemccandless.com
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


Grant Ingersoll | @gsingers
http://www.lucidworks.com

Re: [VOTE] Move trunk to Java 8

2014-09-19 Thread Grant Ingersoll

A little late to the game, but +1 on Java 8 on trunk.  This bikeshed has gone 
on for countless years (go google moving to Java 5 like 8 years ago for Lucene) 
and you will never make everyone happy.  People will upgrade when the new 
features they want in the latest release outweigh the mythical pain of 
upgrading a JDK.


On Sep 15, 2014, at 12:44 AM, Shalin Shekhar Mangar shalinman...@gmail.com 
wrote:

 +1
 
 If we asked our users we would still be using Java 5. Let's move trunk to 
 Java 8. We'd need to backport stuff to Java 7 based branches for a while 
 because users... but that's okay.
 
 On Fri, Sep 12, 2014 at 9:11 PM, Ryan Ernst r...@iernst.net wrote:
 It has been 6 months since Java 8 was released.  It has proven to be
 both stable (no issues like with the initial release of java 7) and
 faster.  And there are a ton of features that would make our lives as
 developers easier (and that can improve the quality of Lucene 5 when
 it is eventually released).
 
 We should stay ahead of the curve, and move trunk to Java 8.
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
 
 -- 
 Regards,
 Shalin Shekhar Mangar.


Grant Ingersoll | @gsingers
http://www.lucidworks.com

[jira] [Comment Edited] (SOLR-6478) need docs / tests of the rules as far as collection names go

2014-09-04 Thread Grant Ingersoll (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121305#comment-14121305
]

Grant Ingersoll edited comment on SOLR-6478 at 9/4/14 12:44 PM:

I suspect some of the URLs, etc. get a little wonky when you allow things like
spaces, etc. in the names. Not sure if we should allow them or not.

was (Author: gsingers):
I suspect ome of the URLs, etc. get a little wonky when you allow things like
spaces, etc. in the names. Not sure if we should allow them or not.

need docs / tests of the rules as far as collection names go
--

Key: SOLR-6478
URL: https://issues.apache.org/jira/browse/SOLR-6478
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man

historically, the rules for core names have been vague but implicitly
defined based on the rule that it had to be a valid directory path name - but
i don't know that we've ever documented anywhere what the rules are for a
collection name when dealing with the Collections API.
I haven't had a chance to try this, but i suspect that using the Collections
API you can create any collection name you want, and the zk/clusterstate.json
data will all be fine, and you'll then be able to request anything you want
from that collection as long as you properly URL escape it in your request
URLs ... but we should have a test that tries to do this, and document any
actual limitations that pop up and/or fix those limitations so we really can
have arbitrary collection names.

--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-6478) need docs / tests of the rules as far as collection names go

2014-09-04 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14121305#comment-14121305
 ] 

Grant Ingersoll commented on SOLR-6478:
---

I suspect ome of the URLs, etc. get a little wonky when you allow things like 
spaces, etc. in the names.  Not sure if we should allow them or not.

 need docs / tests of the rules as far as collection names go
 --

 Key: SOLR-6478
 URL: https://issues.apache.org/jira/browse/SOLR-6478
 Project: Solr
  Issue Type: Improvement
Reporter: Hoss Man

 historically, the rules for core names have been vague but implicitly 
 defined based on the rule that it had to be a valid directory path name - but 
 i don't know that we've ever documented anywhere what the rules are for a 
 collection name when dealing with the Collections API.
 I haven't had a chance to try this, but i suspect that using the Collections 
 API you can create any collection name you want, and the zk/clusterstate.json 
 data will all be fine, and you'll then be able to request anything you want 
 from that collection as long as you properly URL escape it in your request 
 URLs ... but we should have a test that tries to do this, and document any 
 actual limitations that pop up and/or fix those limitations so we really can 
 have arbitrary collection names.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

2014-08-10 Thread Grant Ingersoll (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14092073#comment-14092073
]

Grant Ingersoll commented on SOLR-3619:
---

bq. I can see the value of a schemaless mode for a brand-new user or when
initially developing a schema, but when it comes to production, the chances of
an incorrect guess are just too high,

There are actually some use cases for it in production, as Yonik mentioned, but
in reality, I don't think anyone here is proposing that the majority of users
go into production in data-driven schema mode.

bq. and fixing things after an incorrect guess is likely to require a reindex.
On the IRC channel, users are not shy about letting you know just how much they
hate reindexing ... especially if they were not previously aware of what
reindexing actually means. That doesn't really go away when the schema is
explicit, but it would not be as likely.

We aren't talking about re-indexing production. We are talking about rapid
iteration of data modeling. Those who truly need data-driven (and there are
those people out there) will already know the caveats and those who don't
should be guided away from it as they progress by documentation. I like to
break this whole process down into what I consistently see as the selection
process most devs go through when selecting technology (search or otherwise):
# Boss or you or someone else says: hey we need to solve this problem. I think
X and possibly Y will work.
# Boss: You've got one (maybe two) week(s) to make a recommendation
# You then spend that time doing the following for X and Y:
## 5 minute to 1 hour test/tutorial (anything that doesn't pass that gets
tossed)
## 1 day test (can I get my data in and ask the questions I need of it?)
## Spend the rest of the time scaling it up and exploring and peeling back the
layers of the onion (how do I scale? how would I do this in production? what
bumps are in my way?)
# Make a recommendation
# Go for it -- This step is when they start to lock things down.

The thing is, Solr is incredibly awesome at the end stages of this game (i.e.
getting to production). It is way more solid and way more tested, as can be
seen time and time again, but if we don't solve the ease of use stuff, than it
doesn't matter, b/c it isn't being selected to be used in the first place. If
you think about it, easy to get started, easy to get finished is a killer
combination. Solr is easy to get finished already, but it still has a fairly
steep learning curve for people who aren't search experts (which is what has
changed the most recently: more people are looking at Solr as a NoSQL store and
less at it as a search engine).

bq. I'd like to see an extensive admin UI interface for uploading, changing,
cloning, and deleting config sets.

Perhaps for experts, but again, I doubt most users should need to do these
things. Not saying I'm against it, but I think we should minimize any mention
of this stuff until later.

bq. zookeeper config modifying functionality must be disabled by default, with
some way of enabling it that requires administrative access to the operating
system.

I believe there are other APIs that are being worked on that will make editing
the config something one does programmatically, which means it can also be
secured. IMO, the current XML config files, etc., should be an implementation
detail, not an API, as they are now.

bq. I just had an interesting idea. In order for config editing to turn on, we
could require a two-part procedure. First you go to a specific section of the
admin UI where you enter an edit mode expiration time. When that is submitted,
it gives you a filename, most likely containing a hash, like
edit-5fb65b8bfe33f603b7a427284cc6e48a. Until the expire time for that hash is
reached, the presence of that file in the solr home will allow config editing.
We could put a limit on the expiry time of 1-4 hours.

Again, perhaps this is an expert thing and labeled accordingly, but I don't
think new users should have to do this. If we can't make this stuff simpler,
then we shouldn't do it at all.

Rename 'example' dir to 'server' and pull examples into an 'examples'
directory
---

Key: SOLR-3619
URL: https://issues.apache.org/jira/browse/SOLR-3619
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Timothy Potter
Fix For: 4.9, 5.0

Attachments: SOLR-3619.patch, SOLR-3619.patch, managed-schema,
server-name-layout.png, solrconfig.xml

--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

2014-08-07 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14089943#comment-14089943
 ] 

Grant Ingersoll commented on SOLR-3619:
---

bq. Can we agree to start with 2 configsets (based on Hoss' plan above) and 
then work on converting the other examples iteratively

I don't think getting started should require any knowledge of configsets, etc.  
You've already lost me as a new dev (I've seen this so many times in the past 2 
years).  Getting started is all about my data and my queries.  I should only 
have to know enough to start indexing.  Than, as I peel back the layer, I can 
dig in deeper.

# bin/start
# create new collection (Managed schema, field guessing)
# Throw my JSON, CSV, PDFs, etc. at it and it does a reasonable first pass at 
it such that I can start iterating on how this all works.

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

 Key: SOLR-3619
 URL: https://issues.apache.org/jira/browse/SOLR-3619
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Timothy Potter
 Fix For: 4.9, 5.0

 Attachments: SOLR-3619.patch, SOLR-3619.patch, managed-schema, 
 server-name-layout.png, solrconfig.xml






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array

2014-07-30 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14079792#comment-14079792
 ] 

Grant Ingersoll commented on SOLR-6294:
---

I really don't like having separate APIs for one doc vs. multiple docs.  How 
about deprecating the existing approach in favor a new one that properly 
captures commands, single docs, and multiple docs and is clean for users?  

The whole point of stuff like this is to make it easier for people first coming 
to Solr to not have to think about all the gotchas and just get their data in.  
Ease of use has to be all about the user's data and their questions for it, not 
about idiosyncrasies in API design to workaround previous approaches.

 The JsonLoader should accept a single doc without wrapping in an array
 --

 Key: SOLR-6294
 URL: https://issues.apache.org/jira/browse/SOLR-6294
 Project: Solr
  Issue Type: Bug
  Components: update
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor

 This is the multi document input command
 {noformat}
 curl http://localhost:8983/solr/update/json -H 
 'Content-type:application/json' -d '
 [
  {id : TestDoc1, title : test1},
 ]'
 {noformat}
 The following also should be a valid update command for a single doc
 {noformat}
 curl http://localhost:8983/solr/update/json -H 
 'Content-type:application/json' -d '
  {id : TestDoc1, title : test1},
 '
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6294) The JsonLoader should accept a single doc without wrapping in an array

2014-07-29 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-6294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14078154#comment-14078154
 ] 

Grant Ingersoll commented on SOLR-6294:
---

bq. Is that really easier than putting the doc in an array?

If you're data already is written out in JSON and you just want to get started 
by throwing it into Solr in your first few minutes of trying it out, it could 
be.  Just one more thing to have to deal with, I guess, but obviously not a 
show stopper by any stretch.

 The JsonLoader should accept a single doc without wrapping in an array
 --

 Key: SOLR-6294
 URL: https://issues.apache.org/jira/browse/SOLR-6294
 Project: Solr
  Issue Type: Bug
  Components: update
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor

 This is the multi document input command
 {noformat}
 curl http://localhost:8983/solr/update/json -H 
 'Content-type:application/json' -d '
 [
  {id : TestDoc1, title : test1},
 ]'
 {noformat}
 The following also should be a valid update command for a single doc
 {noformat}
 curl http://localhost:8983/solr/update/json -H 
 'Content-type:application/json' -d '
  {id : TestDoc1, title : test1},
 '
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-3619) Rename 'example' dir to 'server' and pull examples into an 'examples' directory

2014-07-21 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14068403#comment-14068403
 ] 

Grant Ingersoll commented on SOLR-3619:
---

bq. Yeah, it feels like one should still be able to start the server and then 
index a document (as they can do now) without any other mandatory steps.

+1

Agree, single core dies, collection1 dies.  Everything should just work out of 
the box!  The first 5 minute experience should be all about the user and their 
data and very little to do about solr configs, schemas, etc.  Same for pretty 
much the whole first day.  By the end of the first week, a new user should have 
a thorough understanding of what they need to do to get to production.  Easy 
to start, easy to finish.  

 Rename 'example' dir to 'server' and pull examples into an 'examples' 
 directory
 ---

 Key: SOLR-3619
 URL: https://issues.apache.org/jira/browse/SOLR-3619
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
 Fix For: 4.9, 5.0

 Attachments: SOLR-3619.patch, server-name-layout.png






--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (LUCENE-5688) NumericDocValues fields with sparse data can be compressed better

2014-05-20 Thread Grant Ingersoll (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-5688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14003231#comment-14003231
 ] 

Grant Ingersoll commented on LUCENE-5688:
-

bq. Varun, i dont think we should make a long[] of size maxDoc in ram here just 
to save some space on disk.

In a large index, this can be quite significant, FWIW.  Agreed on the long[] in 
RAM, but would be good to have a better way of controlling the on-disk behavior.

 NumericDocValues fields with sparse data can be compressed better 
 --

 Key: LUCENE-5688
 URL: https://issues.apache.org/jira/browse/LUCENE-5688
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Varun Thacker
Priority: Minor
 Attachments: LUCENE-5688.patch


 I ran into this problem where I had a dynamic field in Solr and indexed data 
 into lots of fields. For each field only a few documents had actual values 
 and the remaining documents the default value ( 0 ) got indexed. Now when I 
 merge segments, the index size jumps up.
 For example I have 10 segments - Each with 1 DV field. When I merge segments 
 into 1 that segment will contain all 10 DV fields with lots if 0s. 
 This was the motivation behind trying to come up with a compression for a use 
 case like this.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Commented] (SOLR-6058) Solr needs a new website


[ 
https://issues.apache.org/jira/browse/SOLR-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998709#comment-13998709
 ] 

Grant Ingersoll commented on SOLR-6058:
---

[~L_Nino] Thanks for uploading.  Next step would be to generate a patch for the 
current site using the instructions here: 
http://lucene.apache.org/site-instructions.html 

Let me know if you need help.  

I'm going to spin out some sub tasks that will handle overhauling the content.

 Solr needs a new website
 

 Key: SOLR-6058
 URL: https://issues.apache.org/jira/browse/SOLR-6058
 Project: Solr
  Issue Type: Task
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
 Attachments: HTML.rar


 Solr needs a new website:  better organization of content, less verbose, more 
 pleasing graphics, etc.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-6081) Hook in Videos, Books, Reference work

Grant Ingersoll created SOLR-6081:
-

 Summary: Hook in Videos, Books, Reference work
 Key: SOLR-6081
 URL: https://issues.apache.org/jira/browse/SOLR-6081
 Project: Solr
  Issue Type: Sub-task
Reporter: Grant Ingersoll


There is a ton of great content available on Solr in the interwebs, let's make 
it easy to highlight this content so users know their is a large community 
ready to assist.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-6079) First week Docs

Grant Ingersoll created SOLR-6079:
-

 Summary: First week Docs
 Key: SOLR-6079
 URL: https://issues.apache.org/jira/browse/SOLR-6079
 Project: Solr
  Issue Type: Sub-task
Reporter: Grant Ingersoll


Over the course of the week, we want to highlight the things users need to 
think about as the go from novice to production.  The goal here is to provide 
just enough info along the way about the underpinnings of Solr while staying 
focused on the user's data and queries.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-6080) Getting Finished Docs

Grant Ingersoll created SOLR-6080:
-

 Summary: Getting Finished Docs
 Key: SOLR-6080
 URL: https://issues.apache.org/jira/browse/SOLR-6080
 Project: Solr
  Issue Type: Sub-task
Reporter: Grant Ingersoll


It's one thing to be easy to start, it's a whole other level to get finished, 
and getting to production and being stable is one of Solr's strongest suits, 
thanks to it's maturity and testing.  This section of the website should 
highlight what user's need to know about getting to production and maintaining 
a happy cluster.  This can dovetail with the Ref Guide's Well configured Solr 
section



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-6077) Create 5 minute tutorial

Grant Ingersoll created SOLR-6077:
-

 Summary: Create 5 minute tutorial
 Key: SOLR-6077
 URL: https://issues.apache.org/jira/browse/SOLR-6077
 Project: Solr
  Issue Type: Sub-task
Reporter: Grant Ingersoll


Per the new site design for Solr, we'd like to have a 5 minutes to Solr 
tutorial that covers users getting their data in and querying it.  



--
This message was sent by Atlassian JIRA
(v6.2#6252)

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

[jira] [Created] (SOLR-6078) Create First Day Documentation