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

Jason Gerlowski commented on SOLR-17974:
----------------------------------------

It's not the cleanest approach, but could we "solve" this problem by adding new 
vector-specific methods to SolrDocument/SolrInputDocument that explicitly don't 
have the List-flattening semantics?  Say: "addVectorField" and "setVectorField"?

I kindof hate that as it risks introducing special casing throughout our code, 
similar to what we have today (albeit in a different part of the code) with 
PointFields.  But it might be workable?

> Tech-Debt repayment: SolrDocument/SolrInputDocument will merge multiple 
> "list" values
> -------------------------------------------------------------------------------------
>
>                 Key: SOLR-17974
>                 URL: https://issues.apache.org/jira/browse/SOLR-17974
>             Project: Solr
>          Issue Type: Task
>            Reporter: Chris M. Hostetter
>            Priority: Major
>         Attachments: SOLR-17974.tests.patch
>
>
> A long standing bit of "convenience" logic in SolrDocument (that was later 
> copied/inherited in SolrInputDocument) is that if you "add" a 
> {{java.util.Collection}} of "values" for a field name it will either use that 
> {{java.util.Collection}} as is; or -- if the document already has some values 
> in it for that field name -- it unwraps the (new) {{java.util.Collection}} 
> and adds each of the items in it to whatever existing 
> {{java.util.Collection}} of values it already has for that field name.
> Once upon a time this kind of made life easier for folks - you could call one 
> method on either a single value, or a list of values and Solr would "do what 
> you mean".
> But as we get into a world where "multi-valued vector fields" start being a 
> thing we have to consider, we need to rethink our APIs to ensure that (at a 
> conceptual level, if not in terms of specific {{java.util.Collections}} class 
> names) it's possible to have a "list of floats" as a single "field value" in 
> a "multi-valued" field -- w/o a user getting confused why adding additional 
> "field values" breaks their existing data.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to