[Xapian] Fields in de database

[Verwijderd]

Gezien de, naar mijn idee, zeer matige documentatie (er wordt niet eens vermeld hoe de betreffende functies heten in PHP) wil ik jullie toch om hulp vragen.

Ik heb ondertussen Xapian succesvol geinstalleerd en draaien. De koppeling bestaat met PHP en ik kan met een voorbeeld (uit de CVS repository) nu ook simpele indexering en search's doen op mijn posts.

Het is mogelijk om extra fields toe te voegen, naast de standaard.
Bijvoorbeeld voor de topicstarter of de topictitel. Ik kan echter nergens vinden hoe dit moet gebeuren. Heeft iemand dit werkend, eventueel in een andere programmeertaal?
Of kan iemand mij in de goede richting duwen, want ik ben al bijna de hele week aan het zoeken en kan het echt niet vinden.

Verder zou ik willen vragen hoe T.net te werk gaat met hun Omega/Xapian search.
Hebben jullie een wrapper om Omega heen gelegd? Of werken jullie, net als ik wil gaan doen, met de bindings vanuit PHP. Misschien dat iemand van T.net (ACM?) wat tips voor mij heeft omtrend Omega/Xapian.

Ik twijfelde of dit in P&W thuishoort, maar gezien ik de client zelf schrijven moet leek dit me het beste forum.

[Verwijderd]

(Apologies for replying in English)

Have you looked at the very latest Xapian release (0.8.1)? It was only released 2 days ago, and there's now some PHP documentation and examples. You can browse them on the web here:

http://cvs.xapian.org/*ch...s/php4/docs/bindings.html
http://cvs.xapian.org/*ch...p?content-type=text/plain
http://cvs.xapian.org/*ch...p?content-type=text/plain

If you find this lacking, please report it to the xapian-discuss mailing list and we can fill in any gaps.

Cheers, Olly

[ACM]

Verwijderd schreef op 02 juli 2004 @ 00:28:
Het is mogelijk om extra fields toe te voegen, naast de standaard.
Bijvoorbeeld voor de topicstarter of de topictitel. Ik kan echter nergens vinden hoe dit moet gebeuren. Heeft iemand dit werkend, eventueel in een andere programmeertaal?
Of kan iemand mij in de goede richting duwen, want ik ben al bijna de hele week aan het zoeken en kan het echt niet vinden.

Wat bedoel je hier precies mee? Het is namelijk zowel mogelijk om "fields" op te slaan bij een document, die je later bij de retrieval zou kunnen tonen. Als om te zoeken op "fields".

Beide zijn geloof ik nogal virtuele bedoeningen, waarbij er gebruik wordt gemaakt van enerzijds de get/set_data van documents (in de scriptindex-tool, die bij omega hoort, worden datavelden gecodeerd als $veldnaam=$data\n$veldnaam2=$data2\n oid) en bij de doorzoekbare velden worden ze op een speciale manier gecodeerd, alvorens ze te indexeren. Als je bijvoorbeeld als veld de titel apart wilt indexeren, dan geef je in scriptindex bijv op dat ie geindexeerd moet worden met de prefix XT en later bij het doorzoeken met omega dat "titel" gemapped moet worden op de XT-prefix.
De termen die in de titel staan worden vervolgens zowel als XT:term en evt ook als term geindexeerd.

Verder zou ik willen vragen hoe T.net te werk gaat met hun Omega/Xapian search.
Hebben jullie een wrapper om Omega heen gelegd? Of werken jullie, net als ik wil gaan doen, met de bindings vanuit PHP. Misschien dat iemand van T.net (ACM?) wat tips voor mij heeft omtrend Omega/Xapian.

Wij hebben vooralsnog een onderdeel in react dat elke nacht aangeroepen wordt om de index bij te werken. Dat is een php-applicatie die de data in een voor de scriptindex-batchindextool formateert en vervolgens daar via een pipe (popen) aan doorgeeft. Scriptindex indexeert aan de hand van een paar commandline parameters, een definitiebestand dan die data in een Xapian database. Waar lastige dingen als datavelden en indexvelden al voor ons uitgewerkt zijn en we daar niet zelf over hoeven na te denken.

Vervolgens hebben we op diezelfde machine een licht gepatchte Omega die diezelfde database doorzoekt. We geven op die machine via xinetd (zodat de 4 webservers die ene zoekdoos kunnen benaderen) de zoekcommando's door aan omega in omega's eigen cgi-parameterset die je ook achter elkaar op de cli mag meegeven (ala `omega P=$query B=$boolean1 B=$boolean2` etc).
Door een handig gedefinifeerde output-template voor omega kunnen we vervolgens de zoekresultaten weer via diezelfde verbinding via xinetd uitlezen en de resultaten worden vervolgens deels gebruikt om de topicdata uit de SQL-database te vergaren en deels rechtstreeks aan de react-templates aangeboden.

Ik twijfelde of dit in P&W thuishoort, maar gezien ik de client zelf schrijven moet leek dit me het beste forum.

Ik denk dat er niet echt een beter forum is nee

[Verwijderd]

ACM schreef op 02 juli 2004 @ 18:12:
[...]

Wat bedoel je hier precies mee? Het is namelijk zowel mogelijk om "fields" op te slaan bij een document, die je later bij de retrieval zou kunnen tonen. Als om te zoeken op "fields".

Beide zijn geloof ik nogal virtuele bedoeningen, waarbij er gebruik wordt gemaakt van enerzijds de get/set_data van documents (in de scriptindex-tool, die bij omega hoort, worden datavelden gecodeerd als $veldnaam=$data\n$veldnaam2=$data2\n oid)
[...]
De termen die in de titel staan worden vervolgens zowel als XT:term en evt ook als term geindexeerd.

Dat is inderdaad wat ik bedoelde.

ACM schreef op 02 juli 2004 @ 18:12:
Wij hebben vooralsnog een onderdeel in react dat elke nacht aangeroepen wordt om de index bij te werken. Dat is een php-applicatie die de data in een voor de scriptindex-batchindextool formateert en vervolgens daar via een pipe (popen) aan doorgeeft. Scriptindex indexeert aan de hand van een paar commandline parameters, een definitiebestand dan die data in een Xapian database. Waar lastige dingen als datavelden en indexvelden al voor ons uitgewerkt zijn en we daar niet zelf over hoeven na te denken.

Dank je wel voor de info, ga ik daar eens verder naar op zoek....

ACM schreef op 02 juli 2004 @ 18:12:Vervolgens hebben we op diezelfde machine een licht gepatchte Omega die diezelfde database doorzoekt. We geven op die machine via xinetd (zodat de 4 webservers die ene zoekdoos kunnen benaderen) de zoekcommando's door aan omega in omega's eigen cgi-parameterset die je ook achter elkaar op de cli mag meegeven (ala `omega P=$query B=$boolean1 B=$boolean2` etc).

Oke, zo had ik er nog niet naar gekeken...
Op die manier hoef je zelf een stuk minder te schrijven om dezelfde functionaliteit te krijgen..

Ik zit er sterk aan te denken om mijn bevindingen op papier te gaan zetten als ik alles werkend heb. Mocht ik hier voortgang in hebben dan zal ik het hier ook wel posten (iig de link).

Tot nu toe bedankt voor de info, ik ga verder op onderzoek uit in de mailinglist en documentatie

[Verwijderd]

Ik heb nog een kleine vraag

De scriptindex config ziet er bij mij zo uit:

code:

url   : field=url boolean=Q unique=Q
title : field=title weight=3 index=XT
start : field=start weight=2 index=XS
body  : field=text index
users : field=users indexnopos=XU
forum : field=forum boolean=XF

De dynamische data pipe ik naar scriptindex, zoals ACM voorstelde.
De format van de data moet er in het geval van de scriptindex zo uitzien:

code:

url=1
title=check eerst: http://www.sugababes.nl/faq
start=Tekst dat in de startpost staat
body=Dit zijn replies naast de eerst
users=1 2 54 12
forum=4

Het punt waar ik nu nog mee zit is:

Ik kan niet zoeken op fora en users.
Komt dit doordat het getallen zijn?
Ik heb in Omega de prefix's gemapt (dus bijv. user naar XU).
Ik zou dan moeten kunnen zoeken naar user:1, maar ik krijg geen topics terug die matchen (terwijl 1 meerdere malen voorkomt.)

ACM, bij de Parse/Omega combo, slaan jullie daar userid's op of nicknames? En hoe gaan jullie om met furom-id's..
Is mijn scriptindex-config file niet juist op dit punt? Of ligt het aan iets anders

[chem]

Hoe voer je je query uit? user:1 doen wij met B=XU{uid} bijvoorbeeld.

onze index.script

code:

topicid             :   boolean=Q unique=Q field=topicid
forumid             :   boolean=XF
topictitle          :   unhtml index=XC weight=3 index field=caption
topicstart          :   unhtml index=XA weight=2 index truncate=200 field=sample
messages            :   unhtml index
topictype           :   boolean=XT
topicstarter        :   boolean=XS
messageposter       :   boolean=XM
topicday            :   boolean=D
topicmonth          :   boolean=M
topicyear           :   boolean=Y
topicdate           :   value=1
topicdateinverse    :   value=2
lastmodifydate      :   value=3
lastmodifydateinverse : value=4

[ Voor 80% gewijzigd door chem op 06-07-2004 17:27 ]

[Verwijderd]

ah, dat deed ik dus verkeerd...

thnx voor het indexscript trouwens

[ACM]

Verwijderd schreef op 06 juli 2004 @ 17:06:
Ik heb nog een kleine vraag

De scriptindex config ziet er bij mij zo uit:

code:

title : field=title weight=3 index=XT
start : field=start weight=2 index=XS
users : field=users indexnopos=XU

Hier wil ik even op twee dingen wijzen. Bij de eerste twee kan je de title/start-inhoud niet "gewoon" doorzoeken door je index-prefix. Als je "index index=XT" gebruikt kan dat wel (is wat omslachtig/dubbelop)
't Andere is dat je die users ook als boolean kan indexeren (zie verderop in deze post)

Ik heb in Omega de prefix's gemapt (dus bijv. user naar XU).
Ik zou dan moeten kunnen zoeken naar user:1, maar ik krijg geen topics terug die matchen (terwijl 1 meerdere malen voorkomt.)

Hoe had je die gemapped?
Helemaal voor aan de omega-template?

Wat chem vergeet te melden is dat wij userids als boolean's indexeren (je kan meerdere waarden voor eenzelfde boolean opgeven door meerdere keren die boolean te specificeren bij het indexeren). En dan moet je inderdaad B=XU{uid} doen, in jouw geval zou user:{uid} goed moeten zijn.

ACM, bij de Parse/Omega combo, slaan jullie daar userid's op of nicknames? En hoe gaan jullie om met furom-id's..

Userids, het zoeken naar usernames wordt van te voren teruggemapped via de sql-db. En forumids worden net als userids als booleans opgeslagen zoals je kan zien.

[ Voor 5% gewijzigd door ACM op 06-07-2004 23:22 ]

[Verwijderd]

ACM schreef op 06 juli 2004 @ 23:21:
[...]
Hier wil ik even op twee dingen wijzen. Bij de eerste twee kan je de title/start-inhoud niet "gewoon" doorzoeken door je index-prefix. Als je "index index=XT" gebruikt kan dat wel (is wat omslachtig/dubbelop)
't Andere is dat je die users ook als boolean kan indexeren (zie verderop in deze post)

Ik vond het al vreemd dat topics met 'keyword' in de title niet naar voren kwamen bij een normale search.

ACM schreef op 06 juli 2004 @ 23:21:Hoe had je die gemapped?
Helemaal voor aan de omega-template?

Wat chem vergeet te melden is dat wij userids als boolean's indexeren (je kan meerdere waarden voor eenzelfde boolean opgeven door meerdere keren die boolean te specificeren bij het indexeren). En dan moet je inderdaad B=XU{uid} doen, in jouw geval zou user:{uid} goed moeten zijn.

Ik had ze idd helemaal voorin de omega template gedefinieerd, title: werkte ook, alleen user: niet. Ik heb het nu omgezet naar boolean indexering en nu werkt het wel.
Zou het kunnen zijn dat hij vanwege de terms getallen ook aanpast? En daarom mijn lijst met userid's niet goed doorzoekbaar was

ACM schreef op 06 juli 2004 @ 23:21:Userids, het zoeken naar usernames wordt van te voren teruggemapped via de sql-db. En forumids worden net als userids als booleans opgeslagen zoals je kan zien.

Lijkt mij ook het handigst ivm username changes...

Ik begin nu eindelijk het geheel te snappen en een beetje overzicht te krijgen.
Bedankt Chem en ACM!

Op het moment dat ik alles werkend heb zal ik eens een tutorial schrijven voor mensen die na mij met Omega aan de slag willen.

[Verwijderd]

Verwijderd schreef op 02 juli 2004 @ 00:28:
Ik heb ondertussen Xapian succesvol geinstalleerd en draaien. De koppeling bestaat met PHP en ik kan met een voorbeeld (uit de CVS repository) nu ook simpele indexering en search's doen op mijn posts.

Kun je mij alsjeblieft vertellen hoe je dit in godsnaam voorelkaar hebt gekregen. Ik ben al heel de dag bezig om die xapian bindings voor php gecompileerd te krijgen onder linux maareh hij wil geen xapian.so uitspugen.