lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Male (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2708) Allow customizable bean mapping for QueryResponse.getBeans(..)
Date Fri, 12 Aug 2011 03:30:27 GMT

    [ 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


Mime
View raw message