[jira] Commented: (SOLR-1541) lowering ranking of certain documents while search
[ https://issues.apache.org/jira/browse/SOLR-1541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773386#action_12773386 ] Avlesh Singh commented on SOLR-1541: Why is a ticket created in the very first place? Ask this question on the user mailing list. There are multiple ways you can do this. Issues are created for bugs/features/enhancements and NOT queries. lowering ranking of certain documents while search -- Key: SOLR-1541 URL: https://issues.apache.org/jira/browse/SOLR-1541 Project: Solr Issue Type: Wish Components: search Reporter: arvind The requirement is as below: Suppose, there are some documents already stored in Solr. These documents/records belong to various sources like, source1, source2 etc (stored in 'Source' Solr field). Now, when user searches for documents (simple text search) then, is there any possibilities in Solr so that results of certain sources always come with lower rank? (ie, such sources always come in trailing pages). I believe, there should be some way for this in functional query but not sure! Any help on this is greately appreciated. Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1494) Bind highlighting info using SolrJ's DocumentObjectBinder
Bind highlighting info using SolrJ's DocumentObjectBinder
-
Key: SOLR-1494
URL: https://issues.apache.org/jira/browse/SOLR-1494
Project: Solr
Issue Type: New Feature
Components: clients - java
Reporter: Avlesh Singh
Priority: Minor
Fix For: 1.5
The DocumentObjectBinder class should bind highlighting info in
QueryResponse, if specified by a end user. This can be achieved using an
annotated interface {...@highlight}} as underneath -
{code:java}
class MyBean{
@Field
@Highlight
String name;
@Field (solr_category_field_name)
ListString categories;
@Highlight (solr_category_field_name)
ListString highlightedCategories
@Field
float score;
...
}
{code}
With this bean definition, if someone tries to fetch the response as
{{QueryResponse#getBeans(MyBean.class)}}, the beans will have highlighting data
populated into its corresponding fields.
Original mail thread here -
http://www.lucidimagination.com/search/document/897f5a26e35bd27e/highlighting_bean_properties_using_documentobjectbinder_new_feature
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1408) Classes in ${solr.home}/lib are not able to extend classes loaded by solr war - ClassCastException
[
https://issues.apache.org/jira/browse/SOLR-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12751684#action_12751684
]
Avlesh Singh commented on SOLR-1408:
bq. I am starting the jetty server from within a unit test for integration
testing purposes.
Does it fail in unit testing?
I too suspect that there is a problem. I too have similar extensions of DIH and
UpdateProcessors, which lie in the lib. I have never faced any such issue on
any of the platforms.
Classes in ${solr.home}/lib are not able to extend classes loaded by solr war
- ClassCastException
--
Key: SOLR-1408
URL: https://issues.apache.org/jira/browse/SOLR-1408
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 1.3
Reporter: Luke Forehand
When extending org.apache.solr.handler.dataimport.DataSource, I would like to
package my extended class in ${solr.home}/lib to that I can keep the vanilla
copy of my solr.war intact. The problem is I encounter a ClassCastException
when Solr tries to create a newInstance of my extended class.
Although the parent classloader of ${solr.home}/lib classloader loads
DataSource, I am still getting a ClassCastException when a class in
${solr.home}/lib extends DataSource.
The solr instance is being deployed to a jetty plus server that is running
inside a unit test.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12747968#action_12747968
]
Avlesh Singh commented on SOLR-1129:
There is already as issue for the above Anders. SOLR-1357 is waiting for a
patch.
SolrJ cannot bind dynamic fields to beans
-
Key: SOLR-1129
URL: https://issues.apache.org/jira/browse/SOLR-1129
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 1.4
Attachments: SOLR-1129.patch, SOLR-1129.patch, SOLR-1129.patch,
SOLR-1129.patch, SOLR-1129.patch, SOLR-1129.patch
SolrJ does not support binding of dynamic fields to bean fields
The field declaration could be as follows
{code:java}
@Field(*_s)
public String anyString;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1387) Add more search options for filtering facets.
[
https://issues.apache.org/jira/browse/SOLR-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12748061#action_12748061
]
Avlesh Singh commented on SOLR-1387:
{quote}
facet.iPrefix : this would act like case-insensitive search. (or ---
facet.prefix=afacet.caseinsense=on)
{quote}
I don't see a reason as to why the case filter be there. you can always apply a
lower case filter to you field while indexing and searching.
{quote}
facet.regex : this is pure regular expression search (which obviously would be
expensive if issued).
{quote}
You mean wildcards. Right?
{quote}
Moreover, allowing multiple filtering for same field would be great like
facet.prefix=a OR facet.prefix=A ... sth like this.
{quote}
This has been recently discussed on the dev mailing list here -
http://www.lucidimagination.com/search/document/f954dbb323746ed1/multiple_facet_prefix
The syntax that was agreed upon was local params in this manner -
facet.field={!prefix=foo prefix=bar}myfield
Add more search options for filtering facets.
-
Key: SOLR-1387
URL: https://issues.apache.org/jira/browse/SOLR-1387
Project: Solr
Issue Type: New Feature
Components: search
Affects Versions: 1.4
Reporter: Anil Khadka
Currently for filtering the facets, we have to use prefix (which use
String.startsWith() in java).
We can add some parameters like
* facet.iPrefix : this would act like case-insensitive search. (or ---
facet.prefix=afacet.caseinsense=on)
* facet.regex : this is pure regular expression search (which obviously would
be expensive if issued).
Moreover, allowing multiple filtering for same field would be great like
facet.prefix=a OR facet.prefix=A ... sth like this.
All above concepts could be equally applicable to TermsComponent.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1357) SolrInputDocument cannot process dynamic fields
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 {{MapString, 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_*)
MapString, Integer brands;
...
}
MapString, String brands= new HashMapString, 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
MapString, String brands= new HashMapString, 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.
[jira] Commented: (SOLR-1357) SolrInputDocument cannot process dynamic fields
[
https://issues.apache.org/jira/browse/SOLR-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741910#action_12741910
]
Avlesh Singh commented on SOLR-1357:
Well, I don't see a reason behind the proposed behavior (brand_nokia versus
nokia), Noble. And why do you think {{SolrInputDocument}} should not facilitate
this?
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 {{MapString, 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_*)
MapString, Integer brands;
...
}
MapString, String brands= new HashMapString, 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
MapString, String brands= new HashMapString, 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.
[jira] Commented: (SOLR-1357) SolrInputDocument cannot process dynamic fields
[
https://issues.apache.org/jira/browse/SOLR-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741915#action_12741915
]
Avlesh Singh commented on SOLR-1357:
My point is that when a user has already annotated the field as brand_*,
appending them to keys of the Map is counter intuitive. This also goes against
the behavior in SOLR-1129.
As far as supporting the behavior in {{SolrInputDocument}} goes, unless there
is some low level API restriction, I would say we should support it.
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 {{MapString, 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_*)
MapString, Integer brands;
...
}
MapString, String brands= new HashMapString, 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
MapString, String brands= new HashMapString, 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.
[jira] Commented: (SOLR-1352) DIH: MultiThreaded
[
https://issues.apache.org/jira/browse/SOLR-1352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741047#action_12741047
]
Avlesh Singh commented on SOLR-1352:
Thanks, once again :), for creating the ticket, Noble.
Here's the last discussion on the topic, Support for batch processing of
commands using parallel threads in DIH -
http://www.lucidimagination.com/search/document/a9b26ade46466ee/queries_regarding_a_paralleldataimporthandler
DIH: MultiThreaded
--
Key: SOLR-1352
URL: https://issues.apache.org/jira/browse/SOLR-1352
Project: Solr
Issue Type: Improvement
Components: contrib - DataImportHandler
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 1.5
It has been a long pending request to make DIH multithreaded. Now that we
have implemented most of the features , the next best thing we can aim for is
performance. DIH should be able to take advantage of multiple cores in a box
.I expect the configuration to be as follows
{code:xml}
entity name=foo numThreads=4
!--more stuff goes here--
/entity
{code}
at the entity where the numThreads is specified it should fork into multiple
threads. If the numThreads2 it executes w/o forking. In debug mode it
automatically becomes singlethreaded.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1348) JdbcDataSource does not import Blob values correctly by default
[ https://issues.apache.org/jira/browse/SOLR-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12741050#action_12741050 ] Avlesh Singh commented on SOLR-1348: I have used cast() function in MySQL to convert my blob columns in the result set to strings. JdbcDataSource does not import Blob values correctly by default --- Key: SOLR-1348 URL: https://issues.apache.org/jira/browse/SOLR-1348 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Jay Clelland Assignee: Noble Paul Priority: Minor When blob values are returned through a java ResultSet Object they have the type byte[]. As byte[] doesn't have a useful toString method we end up with a reference type value added to the solr document (i.e. [...@1f23c5). The problem is easy to remedy by adding the attribute 'convertType=true' to the dataSource tag within data-config.xml. However this attribute does not appear to be documented anywhere and I was only able to find it after a few hours digging through the source code. A simple fix for this would be to change the default value of convertType to true within the JdbcDataSource class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-247) Allow facet.field=* to facet on all fields (without knowing what they are)
[ https://issues.apache.org/jira/browse/SOLR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12740397#action_12740397 ] Avlesh Singh commented on SOLR-247: --- I haven't tested this patch yet. But my belief is that the primary objective should be to support dynamic fields than pure wildcard field names. Dynamic fields offer wide range of capabilities with w.r.t key-value(s) kind of data. Most of the times people use such fields because the keys are not known upfront. If nothing more, this patch should at least cater to that audience. Allow facet.field=* to facet on all fields (without knowing what they are) -- Key: SOLR-247 URL: https://issues.apache.org/jira/browse/SOLR-247 Project: Solr Issue Type: Improvement Reporter: Ryan McKinley Priority: Minor Attachments: SOLR-247-FacetAllFields.patch, SOLR-247.patch, SOLR-247.patch, SOLR-247.patch I don't know if this is a good idea to include -- it is potentially a bad idea to use it, but that can be ok. This came out of trying to use faceting for the LukeRequestHandler top term collecting. http://www.nabble.com/Luke-request-handler-issue-tf3762155.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12727919#action_12727919
]
Avlesh Singh commented on SOLR-1129:
Good to go, Noble. I have tried and tested the patch, it looks good.
SolrJ cannot bind dynamic fields to beans
-
Key: SOLR-1129
URL: https://issues.apache.org/jira/browse/SOLR-1129
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 1.4
Attachments: SOLR-1129.patch, SOLR-1129.patch, SOLR-1129.patch,
SOLR-1129.patch, SOLR-1129.patch
SolrJ does not support binding of dynamic fields to bean fields
The field declaration could be as follows
{code:java}
@Field(*_s)
public String anyString;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Avlesh Singh updated SOLR-1129:
---
Attachment: SOLR-1129.patch
Just realized that the usage of {{field.matches(^fieldName$)}} has not been
changed to use the cached pattern. Made the necessary change. Please use the
latest patch.
SolrJ cannot bind dynamic fields to beans
-
Key: SOLR-1129
URL: https://issues.apache.org/jira/browse/SOLR-1129
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 1.4
Attachments: SOLR-1129.patch, SOLR-1129.patch, SOLR-1129.patch
SolrJ does not support binding of dynamic fields to bean fields
The field declaration could be as follows
{code:java}
@Field(*_s)
public String anyString;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Avlesh Singh updated SOLR-1129:
---
Attachment: SOLR-1129.patch
All the changes as discussed earlier, have been implemented.
SolrJ can now be used to bind dynamic fields using any one of these
{code:java}
@Field(*_random)
public MapString, Integer random;
@Field(categories_*)
public MapString, String[] categories;
@Field(oem_*)
public MapString, ListString oem;
@Field(supplier_*)
public ListString allSuppliers;
@Field(supplier_*)
public String supplier;
@Field(supplier_*)
public void setSuppliers(String[] allSuppliers){}
{code}
The attached patch also contains a test case for the above mentioned usages.
Cheers
Avlesh
SolrJ cannot bind dynamic fields to beans
-
Key: SOLR-1129
URL: https://issues.apache.org/jira/browse/SOLR-1129
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Noble Paul
Fix For: 1.4
Attachments: SOLR-1129.patch, SOLR-1129.patch
SolrJ does not support binding of dynamic fields to bean fields
The field declaration could be as follows
{code:java}
@Field(*_s)
public String anyString;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12709373#action_12709373
]
Avlesh Singh commented on SOLR-1129:
Sorry for the delay. Will submit a patch latest by tomorrow.
SolrJ cannot bind dynamic fields to beans
-
Key: SOLR-1129
URL: https://issues.apache.org/jira/browse/SOLR-1129
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
Fix For: 1.4
Attachments: SOLR-1129.patch
SolrJ does not support binding of dynamic fields to bean fields
The field declaration could be as follows
{code:java}
@Field(*_s)
public String anyString;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12702987#action_12702987
]
Avlesh Singh commented on SOLR-1129:
All you points are taken, Noble.
I'll make the modifications in trunk and get back asap.
SolrJ cannot bind dynamic fields to beans
-
Key: SOLR-1129
URL: https://issues.apache.org/jira/browse/SOLR-1129
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
Attachments: SOLR-1129.patch
SolrJ does not support binding of dynamic fields to bean fields
The field declaration could be as follows
{code:java}
@Field(*_s)
public String anyString;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12702675#action_12702675
]
Avlesh Singh commented on SOLR-1129:
Thanks for creating this ticket, Noble.
I have an issue with the approach you have mentioned. IMO, the client should
specify the field to which the value belongs to.
I would rather prefer a format like this -
{code:java}
@Field(*_s)
public MapString, Object foo;
{code}
where the keys are {{dynamicField}} name's. For {{multivalued}} fields, a user
might specify an {{Object[]}} as value.
SolrJ cannot bind dynamic fields to beans
-
Key: SOLR-1129
URL: https://issues.apache.org/jira/browse/SOLR-1129
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
SolrJ does not support binding of dynamic fields to bean fields
The field declaration could be as follows
{code:java}
@Field(*_s)
public String anyString;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
[
https://issues.apache.org/jira/browse/SOLR-1129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Avlesh Singh updated SOLR-1129:
---
Attachment: SOLR-1129.patch
Adding a patch for this enhancement.
Existing test cases pass. I'll add new test cases in
{{TestDocumentObjectBinder}} shortly.
This is the approach I took.
# Dynamic fields can be annotated in the following manner
{code:java}
@Field(*_random)
public MapString, Integer random;
@Field(supplier_*)
public MapString, String[] suppliers;
@Field(oem_*)
public MapString, ListString oem;
{code}
# Based on the {{value type}} of this {{Map}}, I populate all matching fields
in the response with their corresponding value(s).
# I added one more clause to the {{DocField}}'s {{storeType}} method to take
care of fields of type {{Map}}. Using {{getActualTypeArguments}} for this
{{ParameterizedType}} value, I populate the existing properties in the
{{DocField}} viz {{name, field, type, isArray, isList}} etc.
# I added a private method, {{getFieldValueByFieldName(SolrDocument sdoc,
String fieldName)}} in the {{DocField}} class, which is now being called by
the {{inject}} method for all fields. For regular index fields, the method
behavior has not changed. However, for a dynamic field (as annotated by the
client), this method prepares a {{Map}} of matching fieldNames and their
corresponding value(s). This in turn is used by the {{inject}} method to call
the client bean's corresponding setter method.
Please note that this fix is for version 1.3.
Cheers
Avlesh
SolrJ cannot bind dynamic fields to beans
-
Key: SOLR-1129
URL: https://issues.apache.org/jira/browse/SOLR-1129
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
Attachments: SOLR-1129.patch
SolrJ does not support binding of dynamic fields to bean fields
The field declaration could be as follows
{code:java}
@Field(*_s)
public String anyString;
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
