[jira] [Commented] (SOLR-6952) Copying data-driven configsets by default is not helpful
[
https://issues.apache.org/jira/browse/SOLR-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14272978#comment-14272978
]
Timothy Potter commented on SOLR-6952:
--
How should the user specify they want to reuse a config that already exists in
ZooKeeper instead of creating a new config in ZK by copying the template? The
default behavior will copy the template and name the config the same name as
the collection in ZK. Maybe something like a -sharedConfig option?
{code}
bin/solr create_collection -n foo -sharedConfig data_driven_schema_configs
{code}
This means to use the data_driven_schema_configs as-is in ZooKeeper and not
copy it to a new config directory. I like making the shared concept explicit
in the param / help for the command but open to other approaches too.
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
Assignee: Timothy Potter
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-6952) Copying data-driven configsets by default is not helpful
[
https://issues.apache.org/jira/browse/SOLR-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14272552#comment-14272552
]
Noble Paul commented on SOLR-6952:
--
Should it be a feature of the scripts or should it be an option in the
Collection create?
Now that we made the configsets mutable , it makes sense to make it a more
accessible feature
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-6952) Copying data-driven configsets by default is not helpful
[
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] [Commented] (SOLR-6952) Copying data-driven configsets by default is not helpful
[
https://issues.apache.org/jira/browse/SOLR-6952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14272560#comment-14272560
]
Noble Paul commented on SOLR-6952:
--
Keeping in mind ease the script by default should create a copy unless
specified otherwise
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
