[Xapian-tickets] [Xapian] #198: Add support for multiple values in each value slot in a Document.

[Xapian]

#198: Add support for multiple values in each value slot in a Document.
---------------------------+------------------------------------------------
 Reporter:  richard        |        Owner:  richard  
     Type:  defect         |       Status:  assigned 
 Priority:  high           |    Milestone:  1.1.4    
Component:  Backend-Chert  |      Version:  SVN trunk
 Severity:  normal         |   Resolution:           
 Keywords:                 |    Blockedby:           
 Platform:  All            |     Blocking:  199      
---------------------------+------------------------------------------------

Comment(by richard):

 I've been thinking about this over the last few days, and I'm coming to
 think that this is a feature that we shouldn't actually support.  Instead,
 we should provide convenient classes to allow serialising multiple values
 into a string, Sorter (or "!KeyMaker") subclasses to use the first of
 these serialised values for sorting, and posting sources to read the first
 item.

 Two reasons for this:

  1) A generic "multiple values in a slot" encoding is going to entail some
 overhead over a custom encoding in some cases.  For example, if we're
 encoding multiple numeric values, we can use the encode_length() encoding
 to store self-terminating representations, but if we're storing arbitrary
 data, we need to store a length part explicitly before the data.

  2) Though the flint backend could currently store multiple values without
 a change to the way the values are stored, the chert backend uses separate
 value streams for each value, and I think we'd want to store only the
 first value in the stream, and then store the subsequent values in a
 secondary lookup.  Either this, or encode multiple values into the stream.
 Either of these approaches seems awkward, and likely to involve quite a
 bit of code and several corner cases.  Moving the problem to be handled by
 external processors seems like a much safer solution.

-- 
Ticket URL: <http://trac.xapian.org/ticket/198#comment:15>
Xapian <http://xapian.org/>
Xapian