[
https://issues.apache.org/jira/browse/SOLR-17974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18046062#comment-18046062
]
Chris M. Hostetter edited comment on SOLR-17974 at 12/18/25 12:42 AM:
----------------------------------------------------------------------
somewhat of a tanget, but...
{quote}Nested vectors -> build nested documents automatically (as this is the
route we've decided in Lucene after many discussions)
...
I'll also open a draft Pull request soon with some ideas, at least for the HNSW
use case (pretty much an alternative syntax to indexing nested vectors)
{quote}
[~abenedetti] - i haven't really been following the lucene level discussions,
so i didn't realize that a final decision had been made that "nested documents"
was the best/final solution for multi-valued HNSW vector fields. I created
SOLR-18034 with some existing plugin code I created a while back to help with
building these nested vector documents (back when i thought it was just going
to be a short term workaround until lucene supported it natively)
was (Author: hossman):
somewhat of a tanget, but...
{quote}Nested vectors -> build nested documents automatically (as this is the
route we've decided in Lucene after many discussions)
{quote}
[~abenedetti] - i haven't really been following the lucene level discussions,
so i didn't realize that a final decision had been made that "nested documents"
was the best/final solution for multi-valued HNSW vector fields. I created
SOLR-18034 with some existing plugin code I created a while back to help with
building these nested vector documents (back when i thought it was just going
to be a short term workaround until lucene supported it natively)
> 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]
