<DIV>&nbsp;</DIV>

<DIV>&nbsp;Thanks for your guys enthusiasm replys, realy helpful!</DIV>

<DIV>&nbsp;</DIV>

<DIV>Cheers,</DIV>

<DIV>Ming</DIV>

<DIV>&nbsp;</DIV>

<DIV>&nbsp;</DIV>

<DIV>&nbsp;</DIV>

<DIV></DIV><BR><PRE>在2008-09-17，"Olly Betts" &lt;olly@survex.com&gt; 写道：

&gt;On Wed, Sep 17, 2008 at 06:13:40AM +0000, Dave Spencer wrote:

&gt;&gt; It would be nice if there was some page on "concepts" that covered this

&gt;

&gt;http://xapian.org/docs/glossary

&gt;

&gt;&gt; I've wondered what the intent of get_data and set_data was, esp why have

&gt;&gt; the indexed values (the index being the first arg to get/add value) whereas

&gt;&gt; with data it's just a single value -- why not have multiple "data" values,

&gt;&gt; or why not get rid of "data" and just let the get/add value calls cover it?

&gt;

&gt;Use values if you need fast access during the match process itself (e.g.

&gt;for sorting, collapsing, etc).  Then Xapian knows to store the data such

&gt;that this can be done efficiently.  If you're sorting by date, Xapian

&gt;only needs date information and doesn't want to have to fetch extraneous

&gt;data to get it - this is why there are multiple value slots (the current

&gt;implementation doesn't make best use of this but I'm working on that at

&gt;the moment as it happens!)

&gt;

&gt;Optimising the storage scheme for this use case will hurt other access

&gt;patterns, so we advise against storing arbitrary "data fields" in value

&gt;slots.  If you need to store other data which isn't needed in this way

&gt;(e.g. you want it for displaying results), serialise it into the

&gt;document data instead.

&gt;

&gt;There are already plenty of existing ways to serialise structured data

&gt;into a single string, so when we were originally building Xapian we just

&gt;chose a simple approach which allows you to pick an existing solution

&gt;you like (some examples: XML, Python's pickle, JSON, Omega's

&gt;"name=value" scheme) and allowed us to get on with the rest of the job.

&gt;

&gt;At some point I think we probably will add support for some sort of

&gt;document fields.  Verbosity is more of an issue here than in most

&gt;situations, so it's not just a case of reinventing the wheel, and

&gt;we may be able to reuse an existing solution anyway.

&gt;

&gt;A numerically subscripted array of strings doesn't add much generality

&gt;though - if you want to store any other sort of structure or any

&gt;non-string data, you're still going to have to serialise it to one or

&gt;more strings.  I think we probably should aim higher.

&gt;

&gt;There's a ticket tracking this issue:

&gt;

&gt;http://trac.xapian.org/ticket/53

&gt;

&gt;&gt; I'm guessing the intent of 'data' is to store some key piece of info

&gt;&gt; about a document such as the URL of a doc that represents a web page.

&gt;

&gt;One *or more* pieces of information, but otherwise yes.

&gt;

&gt;Cheers,

&gt;    Olly

&gt;

&gt;_______________________________________________

&gt;Xapian-devel mailing list

&gt;Xapian-devel@lists.xapian.org

&gt;http://lists.xapian.org/mailman/listinfo/xapian-devel

</PRE>