lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erick Erickson (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (SOLR-328) Proposal: ObjectField for storing and retrieving arbitrary serializable Objects
Date Sat, 16 Feb 2013 16:23:12 GMT

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

Erick Erickson resolved SOLR-328.
---------------------------------

    Resolution: Fixed

Cleaning up old JIRAs, re-open if necessary. Exists binary type now.
                
> 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
>         Attachments: ObjectField.patch
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
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