On 10/28/2019 9:30 AM, rhys J wrote:
Will I break Solr if i change this to default to not multi-valued?
If you are only indexing one value in those fields, then setting
multiValued to false will not break anything.
If an indexing request ever comes in that has more than one value for a
I forgot to include the fields created through the API:
Thanks,
Rhys
On Mon, Oct 28, 2019 at 11:30 AM rhys J wrote:
>
>
>> Did you reload the core/collection or restart Solr so the new schema
>> would take effect? If it's SolrCloud, did you upload the
> Did you reload the core/collection or restart Solr so the new schema
> would take effect? If it's SolrCloud, did you upload the changes to
> zookeeper and then reload the collection? SolrCloud does not use config
> files on disk.
>
So I have not done this part yet, but I noticed some things in
On 10/25/2019 2:30 PM, rhys J wrote:
So I went back to one of the fields that is multi-valued, which I
explicitly did not choose when I created the field, and I re-created it.
It still made the field multi-valued as true.
Why is this?
Did you reload the core/collection or restart Solr so the
>
>
> > "dl2":["Great Plains"],
> > "do_not_call":false,
>
> There are no hashes inside the document. If there were, they would be
> surrounded by {} characters. The whole document is a hash, which is why
> it has {} characters. Referring to the snippet that I included above,
On 10/25/2019 1:48 PM, rhys J wrote:
Is there some reason that text_general fields are returned as arrays, and
other fields are returned as hashes in the json response from a curl query?
Here's the response:
"dl2":["Great Plains"],
"do_not_call":false,
There are no
Is there some reason that text_general fields are returned as arrays, and
other fields are returned as hashes in the json response from a curl query?
Here's my curl query:
curl "http://10.40.10.14:8983/solr/dbtr/select?indent=on=debtor_id:393291;
Here's the response:
