Re: Getting dynamicFields using QueryResponse
the getBeans() cannot map dynamic fields to a bean field. this can be an enhancement request On Sat, Apr 25, 2009 at 12:01 PM, Avlesh Singh wrote: > Unless I am missing something, there seems to be no way for mapping my > "dynamicFields" in the index to a solrj bean. > I am using SolrQuery to fetch a QueryResponse object, and use > QueryResponse.getBeans(MyAnnotatedClass.class) to fetch beans mapped to my > index. > > There is no way to map dynamic fields in my index (*_i kind of fields) to > these beans. Seems as if there is no support in the DocumentObjectBinder > class as well to do the same. > Is this a possible enhancement? > > Note: I don't know the name of the dynamic fields upfront. > > Cheers > Avlesh > -- --Noble Paul
[jira] Created: (SOLR-1129) SolrJ cannot bind dynamic fields to beans
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] 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-tabpanel&focusedCommentId=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 Map 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] 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-tabpanel&focusedCommentId=12702676#action_12702676
]
Noble Paul commented on SOLR-1129:
--
I see your point . it can be extended to support this
> 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-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1116: - Attachment: SOLR-1116.patch * added a new field BinaryField * JavabinCodec writes ByteBuffer as byte[] * in text formats the binary data is written down as hex encoded bytes > Add a Binary FieldType > -- > > Key: SOLR-1116 > URL: https://issues.apache.org/jira/browse/SOLR-1116 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1116.patch > > > Lucene supports binary data for field but Solr has no corresponding field > type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1116: - Fix Version/s: 1.4 > Add a Binary FieldType > -- > > Key: SOLR-1116 > URL: https://issues.apache.org/jira/browse/SOLR-1116 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-1116.patch > > > Lucene supports binary data for field but Solr has no corresponding field > type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-773) Incorporate Local Lucene/Solr
[
https://issues.apache.org/jira/browse/SOLR-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702708#action_12702708
]
Yonik Seeley commented on SOLR-773:
---
It seems like quite a lot of work has gone into working around some of Solr's
current limitations... perhaps we should fix them instead? It seems like we
should be able to avoid custom request handlers, query components, or update
processors and simply use generic mechanisms.
>From the user interface point of view, what's needed is:
- A way to filter by a bounding box. This could simply be a custom QParser
fq={!gbox p=101.2,234.5 f=position, d=1.5}
// a bounding box, centered on 101.2,234.5 including everything within 1.5 miles
- A function query that calculates distances
gdist(position,101.2,234.3)
- A way to sort by a function query... this is generic desired functionality
anyway!
- A way to return the value of a function query for documents - also generic
desired functionality. Perhaps use meta as proposed in SOLR-705?
If we had that, then geo becomes very generic - no need for special distributed
search support, and one could do things like boosting the relevancy score by a
function of the distance (not even necessarily a linear boost because of the
flexibility of function query). If/when we get faceting on a function query, it
will also automatically work with distances.
It seems like points should be stored and represented in a single field, that
way there can be multiple points per document (otherwise how would one
correlate which latitude went with which longitude). How it's indexed (multiple
fields, etc) is more of an implementation detail. There is an issue with *how*
to allow a single field to index to multiple fields - another Solr limitation
we should figure out how to fix (an earlier version of TrieRangeQuery needed
this too).
> Incorporate Local Lucene/Solr
> -
>
> Key: SOLR-773
> URL: https://issues.apache.org/jira/browse/SOLR-773
> Project: Solr
> Issue Type: New Feature
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: lucene.tar.gz, SOLR-773-local-lucene.patch,
> SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch,
> SOLR-773-local-lucene.patch, SOLR-773-local-lucene.patch, SOLR-773.patch,
> SOLR-773.patch, spatial-solr.tar.gz
>
>
> Local Lucene has been donated to the Lucene project. It has some Solr
> components, but we should evaluate how best to incorporate it into Solr.
> See http://lucene.markmail.org/message/orzro22sqdj3wows?q=LocalLucene
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702778#action_12702778 ] Marcus Herou commented on SOLR-139: --- It would make sense of adding ParallelReader functionality so a core can read from several index-dirs. Guess it complicates things a little since you would need to have support for adding data as well to more than one index. Suggestion: /update/coreX/index1 - Uses schema1.xml /update/coreX/index2 - Uses schema2.xml /select/coreX - Uses all schemas e.g. A ParallelReader. Seing quite a lot questions on the mailinglist about users that want to be able to update a single field while maintaining the rest of the index intact (not reindex). > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Ryan McKinley >Assignee: Ryan McKinley > Fix For: 1.5 > > Attachments: Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, getStoredFields.patch, getStoredFields.patch, > getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-ModifyInputDocuments.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-XmlUpdater.patch, > SOLR-269+139-ModifiableDocumentUpdateProcessor.patch > > > It would be nice to be able to update some fields on a document without > having to insert the entire document. > Given the way lucene is structured, (for now) one can only modify stored > fields. > While we are at it, we can support incrementing an existing value - I think > this only makes sense for numbers. > for background, see: > http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- 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 Map random;
@Field("supplier_*")
public Map suppliers;
@Field("oem_*")
public Map> 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.
