alessandrobenedetti commented on code in PR #1435:
URL: https://github.com/apache/solr/pull/1435#discussion_r1149553669
##########
solr/core/src/java/org/apache/solr/schema/DenseVectorField.java:
##########
@@ -205,53 +257,144 @@ public IndexableField createField(SchemaField field,
Object parsedVector) {
* org.apache.solr.handler.loader.CSVLoader} produces an ArrayList of String
- {@link
* org.apache.solr.handler.loader.JsonLoader} produces an ArrayList of
Double - {@link
* org.apache.solr.handler.loader.JavabinLoader} produces an ArrayList of
Float
- *
- * @param inputValue - An {@link ArrayList} containing the elements of the
vector
- * @return the vector parsed
*/
- float[] parseVector(Object inputValue) {
- if (!(inputValue instanceof List)) {
- throw new SolrException(
- SolrException.ErrorCode.BAD_REQUEST,
- "incorrect vector format."
- + " The expected format is an array :'[f1,f2..f3]' where each
element f is a float");
+ public VectorBuilder getVectorBuilder(Object inputValue) {
+ switch (vectorEncoding) {
+ case FLOAT32:
Review Comment:
Question:
I have seen the polimorphic approach and it's cool.
But at the moment each class implementing the abstract will actually
implement just one method (or the getByteVector or the getFloatVector).
Can't we make the vectorBuilder class depending on a type, and the
getVector, being type parametric?
I'm not sure if this will remove entirely the necessity of abstract +2
implementers (probably not), but at least it will ease this piece of code,
because potentially we have initialised the VectorBuilder in a switch case
already, and we can just ask for the vector.
Happy to have a call to clarify this
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
