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] [Updated] (SOLR-2708) Allow customizable bean mapping for QueryResponse.getBeans(..)
Date Sun, 21 Aug 2011 06:15:27 GMT

     [ https://issues.apache.org/jira/browse/SOLR-2708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Chris Male updated SOLR-2708:
-----------------------------

    Attachment: SOLR-2708-beanProperty-valueBinder.patch

New patch with big changes:

- Introduces the idea of ValueBinder, ValueReader, ValueWriter and ValueBinderFactory.  These
decouple the logic of reading and writing values for different property types.
- Moves most of the type parsing logic into DefaultValueBinderFactory which provides an extensible
API if people want to change how certain types are handled.
- Provides implementations for ValueReader and ValueWriter which emulate the current behavior.
- Cleans out DocField so it uses ValueBinder.
- Documentation is improved
- Drops bizarre handling of byte[] and ByteBuffer.  I'll document this change but it isn't
actually documented anywhere that its even supported now.  Its possible to add this back in
through the extension points.

It'd be great if someone could review this.  I'm looking to commit it sometime this coming
week.

> 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
>         Attachments: SOLR-2708-beanProperty-valueBinder.patch, SOLR-2708-beanProperty.patch,
SOLR-2708.patch, SOLR-2708.patch, SOLR-2708.patch
>
>
> 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