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

Noble Paul commented on SOLR-1357:
----------------------------------

bq.My point is that when a user has already annotated the field as "brand_*", 
appending them to keys of the Map is counter intuitive.

IMHO It would be more clear if the fields are created in the same name as the 
user input. appending it to the wild card part is not so obvious. 

This is how serialization/deserialization works.

When I fetch an instance of MyBean ,it  contains the keys as "brands_Nokia" and 
brands_Samsung" . When I store it back why should I chop off the "brands_" 
part. I should be able to put back in the same Object into Solr w/o modifying it

bq.And why do you think SolrInputDocument should not facilitate this?

I'm not against the idea itself. I just meant that it is beyond the scope of 
this issue. Moreover, SolrInputDocument does not have a problem in achieving 
this requirement .

> SolrInputDocument cannot process dynamic fields
> -----------------------------------------------
>
>                 Key: SOLR-1357
>                 URL: https://issues.apache.org/jira/browse/SOLR-1357
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java
>            Reporter: Avlesh Singh
>
> Adding data via {{SolrInputDocument}} is normally done by calling the 
> {{addField}} method with a field name, field value and an optional boost.  In 
> case of dynamic fields, if field names are known upfront, then caller of this 
> method just passes in the right name and it automatically works.
> This does not go well with users who use {...@interface Field}} annotations 
> for automatic binding. 
> As of SOLR-1129, users can annotate {{Map<String, String> propertyName}} with 
> {...@field ("field_*")}} kind of annotations to bind dynamic field data to. 
> {{SolrInputDocument}} should exhibit the same behavior.  The field {{value}} 
> currently supported are - primitive, array, collection or an instance of 
> Iterable. It can also take {{Map}} as values. If the field, for which 
> {{addField}} method is called, is of dynamicField type (which can be derived 
> from the field name), then the keys of the {{Map}}, passed as value, should 
> be used to "compose" the correct field name.
> This should be supported
> {code:java}
> //This code sample should populate the dynamic fields "brands_Nokia" and 
> "brands_Samsung"
> public class MyBean{
>   @Field("brands_*)
>   Map<String, Integer> brands;
>   
>   ...
> }
> Map<String, String> brands= new HashMap<String, String>();
> brands.put("Nokia", 1000);
> brands.put("Samsung", 100);
> MyBean myBean = new MyBean();
> myBean.setBrands(brands);
> solrServer.addBean(myBean);
> {code}
> We can think of supporting this too ...
> {code:java}
> //This code sample should populate the dynamic fields "brands_Nokia" and 
> "brands_Samsung"
> Map<String, String> brands= new HashMap<String, String>();
> brands.put("Nokia", 1000);
> brands.put("Samsung", 100);
> SolrInputDocument doc = new SolrInputDocument();
> doc.addField("brands_*", brands);
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to