“there over 1000 of them[fields]” This is often a red flag in my experience. Solr will handle that many fields, I’ve seen many more. But this is often a result of “database thinking”, i.e. your mental model of how all this data is from a DB perspective rather than a search perspective.
It’s unwieldy to have that many fields. Obviously I don’t know the particulars of your app, and maybe that’s the best design. Particularly if many of the fields are sparsely populated, i.e. only a small percentage of the documents in your corpus have any value for that field then taking a step back and looking at the design might save you some grief down the line. For instance, I’ve seen designs where instead of field1:some_value field2:other_value…. you use a single field with _tokens_ like: field:field1_some_value field:field2_other_value that drops the complexity and increases performance. Anyway, just a thought you might want to consider. Best, Erick > On Sep 16, 2020, at 9:31 PM, Steven White <swhite4...@gmail.com> wrote: > > Hi everyone, > > I figured it out. It is as simple as creating a List<String> and using > that as the value part for SolrInputDocument.addField() API. > > Thanks, > > Steven > > > On Wed, Sep 16, 2020 at 9:13 PM Steven White <swhite4...@gmail.com> wrote: > >> Hi everyone, >> >> I want to avoid creating a <copyField dest="CatchAll" >> source="OneFieldOfMany"/> in my schema (there will be over 1000 of them and >> maybe more so managing it will be a pain). Instead, I want to use SolrJ >> API to do what <copyField/> does. Any example of how I can do this? If >> there is an example online, that would be great. >> >> Thanks in advance. >> >> Steven >>
