[jira] [Commented] (SOLR-2708) Allow customizable bean mapping for QueryResponse.getBeans(..)

["Chris Male (JIRA)" <ji...@apache.org>]

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

Chris Male commented on SOLR-2708:
----------------------------------

Hi,

As suggested in SOLR-2446, I think a good first step is to provide an abstraction for DocumentObjectBinder (DOB) so people can provide their own implementations.  We can then look further into how DOB works.

{quote}
And you want to reuse a class from common as a result from a solr search. You should either duplicate the structure or make common depend on solrj. Neither are desirable.
{quote}

I've bumped into this problem many times myself.  Much like with JPA annotations though, the SolrJ annotations convey some metadata about the bean properties (especially if we expand the annotations supported).  So for me ideally it'd be great to be able to have those annotations still in, without needing the full solrj dependency.  Thats probably something we can look into longer term.

{quote}
introduce a pluggable mechanism for bean resolution. Currently it is impossible - it uses private methods and private inner classes. (This will be useful for custom conversions, because the existing one fails in some cases where BeanUtils.copyProperties works.)
{quote}

Would simply making the API extensible by moving some of the logic to template methods, be sufficient?

{quote}
allow externalized (xml) configuration
{quote}

With the simple support for beans we have today, I feel this might be introducing a lot of complexity for little gain.  If we eventually support composite / embedded beans, this may be useful, but then I think it would exist as another implementation of the DOB abstraction.

{quote}
allow detecting all fields, annotated or not (off by default)
{quote}

Seems reasonable.  Perhaps its worth while having an extension point where fields are checked to see if they are properties to use.

> Allow customizable bean mapping for QueryResponse.getBeans(..)
> --------------------------------------------------------------
>
>                 Key: SOLR-2708
>                 URL: https://issues.apache.org/jira/browse/SOLR-2708
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java
>    Affects Versions: 1.4, 3.1
>            Reporter: Bozhidar Bozhanov
>
> The mechanism for getting beans is rather limited - only classes @Field-annotated fields.
> Imaging the following subprojects:
> - common
> - search
> And you want to reuse a class from common as a result from a solr search. You should either duplicate the structure or make common depend on solrj. Neither are desirable.
> So, my suggestion:
> - introduce a pluggable mechanism for bean resolution. Currently it is impossible - it uses private methods and private inner classes. (This will be useful for custom conversions, because the existing one fails in some cases where BeanUtils.copyProperties works.)
> - allow externalized (xml) configuration
> - allow detecting all fields, annotated or not (off by default)

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org