Xapian discuss - Mar 2005 - creating a database that's compatible with omega

I'm attempting to create a database that's compatible with omega. The
main problem i'm having is getting a URL to appear for my term. I am
using .add_term("U/<uid>") where <uid> is a hex digest. I
can ensure
that it's well under the 240 term length limit. I used
xapian.Database.all_termsbegin() and listed the terms, they are infact
there. When I search in omega however, I don't get a URL at the
bottom, as if I were using omindex or scriptindex. Is there other
fields this depends on? What are some possible reasons. I've gone
through the omindex.cc source and generated url related terms as well
thinking there was a dependancy type situation. I've had no success
with that however. I am using python and .add_term(),I've attached the
source of my indexing script if anyone is interested.
Thank You.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iEmail.py
Type: application/octet-stream
Size: 2770 bytes
Desc: not available
Url :
http://lists.tartarus.org/pipermail/xapian-discuss/attachments/20050309/b6a6838f/iEmail.obj

You also need to add a field to the record.

Terms are what allow a record to be found
Keys are used for maniupations, conditions and sorting during search
Fields are used to retreive per-record text for summaries and things 
like for Omega.

I suggest you look at the scriptindex source code to see what it does.
It makes a good read.

Sam

Sig Lange wrote:
>I'm attempting to create a database that's compatible with omega.
The
>main problem i'm having is getting a URL to appear for my term. I am
>using .add_term("U/<uid>") where <uid> is a hex
digest. I can ensure
>that it's well under the 240 term length limit. I used
>xapian.Database.all_termsbegin() and listed the terms, they are infact
>there. When I search in omega however, I don't get a URL at the
>bottom, as if I were using omindex or scriptindex. Is there other
>fields this depends on? What are some possible reasons. I've gone
>through the omindex.cc source and generated url related terms as well
>thinking there was a dependancy type situation. I've had no success
>with that however. I am using python and .add_term(),I've attached the
>source of my indexing script if anyone is interested.
>Thank You.
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xapian-discuss mailing list
>Xapian-discuss@lists.xapian.org
>http://lists.xapian.org/mailman/listinfo/xapian-discuss
>  
>
>------------------------------------------------------------------------
>
>This message has been 'sanitized'.  This means that potentially
>dangerous content has been rewritten or removed.  The following
>log describes which actions were taken.
>
>Sanitizer (start="1110397131"):
>  Part (pos="2743"):
>    SanitizeFile (filename="unnamed.txt",
mimetype="text/plain"):
>      Match (rule="default"):
>        Enforced policy: accept
>
>  Part (pos="3693"):
>    SanitizeFile (filename="iEmail.py",
mimetype="application/octet-stream"):
>      Match (rule="default"):
>        Enforced policy: accept
>
>    Defanged UNIX shell script(s).
>
>  Part (pos="7625"):
>    SanitizeFile (filename="unnamed.txt",
mimetype="text/plain"):
>      Match (rule="default"):
>        Enforced policy: accept
>
>  Total modifications so far: 1
>
>
>Anomy 0.0.0 : Sanitizer.pm
>$Id: Sanitizer.pm,v 1.54 2002/02/15 16:59:07 bre Exp $
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.tartarus.org/pipermail/xapian-discuss/attachments/20050309/0e4a967e/attachment.htm

One thing I failed to mention - there's no point creating "U"
prefixed
terms in your own indexer "for compatibility".  They're only used
by
omindex for updating documents in an existing database, so if you aren't
using omindex on a database, it doesn't need U terms.

Of course, your indexer may use these terms in a similar way itself, in
which case it's certainly OK to add them (though a "Q" prefix is
really
a better choice for a general "uniqueid").

Cheers,
    Olly