[
https://issues.apache.org/jira/browse/SOLR-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518819
]
Yonik Seeley commented on SOLR-328:
-----------------------------------
> but I soon got lost in a sea of Solr Strings.
Yes, some of the Strings are unfortunate... this was done before Lucene
supported byte[] for stored fields.
Hopefully some day Lucene will support byte[] for indexed values as well, and
then we'll really need a bit of a change :-)
But it seems like a generic BinaryFieldType would be more broadly usable., and
users could store whatever they want in it. Solr could optionally even support
indexing of a binary field even before lucene supports that (if stored-only,
use lucene binary field, otherwise transform to string)
FieldType now has toObject, which could efficiently return a byte[] for
embedded use.
> Proposal: ObjectField for storing and retrieving arbitrary serializable
> Objects
> -------------------------------------------------------------------------------
>
> Key: SOLR-328
> URL: https://issues.apache.org/jira/browse/SOLR-328
> Project: Solr
> Issue Type: New Feature
> Components: search
> Affects Versions: 1.3
> Reporter: Jonathan Woods
> Priority: Minor
>
> A while back I developed a means of storing and retrieving arbitrary Objects
> in a Lucene Document [Field], and I thought that something similar might be
> useful for Solr. Clearly, it will have more use in embedded Solr
> implementations, but there's no reason why remote clients couldn't share
> Object implementations and benefit too.
> I wanted to attach a draft implementation of ObjectField, a subclass of
> org.apache.solr.schema.FieldType, but I soon got lost in a sea of Solr
> Strings. Instead, I've ended this message with code for getting and setting
> Object values in Lucene Fields. Someone who's closer to Solr could easily
> include this in an implementation of ObjectField.
> The approach uses Java serialisation, which is often seen as fragile in the
> sense that changes in class implementation can easily break the serialisation
> format. However, imo that doesn't matter at all here: if a class's
> implementation changes all you'd need to do is re-index; and in any case
> object structure changes are nowhere near as common as object content
> changes, which are bread and butter to Solr.
> Comments welcomed. Oh, and since this is my first communication with Solr -
> thanks to all concerned for a great piece of software.
> Jon
> ========================================================
> public static Object getObject(final Document document, final String
> fieldName) {
> final byte[] serialisation = document.getBinaryValue(fieldName);
> try {
> return new ObjectInputStream(new
> ByteArrayInputStream(serialisation)).readObject();
> }
> catch (final Exception e) {
> throw new SearchRuntimeException("While trying to deserialise
> object from Field", e);
> }
> }
> public static void indexObject(final Document document, final String
> fieldName, final Serializable object, final boolean compress) throws
> IndexingException {
> final ByteArrayOutputStream boas = new ByteArrayOutputStream();
> try {
> ObjectOutputStream oos = new ObjectOutputStream(boas);
> oos.writeObject(object);
> oos.close();
> }
> catch (IOException e) {
> throw new IndexingException("On trying to serialise object", e);
> }
> document.add(new Field(fieldName, boas.toByteArray(), compress ?
> Store.COMPRESS : Store.YES));
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
