From: Dave F. <dav...@gm...> - 2011-05-26 14:42:33
|
Actually Dan, from what I've seen, I can't get it to work via xmldb:store, so you and I have opposite problems (i.e. using xmldb:store does NOT work in my case). I'm in the process of writing up a more detailed email on what I'm doing and how I'm testing this. I have not tried the copy() function at all yet. On Thu, May 26, 2011 at 9:34 AM, Dan McCreary <dan...@gm...>wrote: > I believe I have found a workaround for my Lucene installers. Wolfgang's > hint about using store() not copy provided me with the hint I needed. > > I found that if I use xmldb:copy() to install the collection.xconf into > /db/system/config that the reindex() does NOT work. > > But if I just open the collection.xconf file in the /db/system area with > doc() and then xmldb:store() the file that the reindex suddenly works! No > need to bring it into oXygen and save. So xmldb:store() must do the same > thing as a open/change/save with oXygen. > > I think the key is that there must be something slighlty different between > xmldb:copy() and xmldb:store() that is used in the reindex() function. > > I think that Dave and I must be using installers that use some variation > non-store to save and the unit tests all use xmldb:store. > > I will send you my samples if you would like but the code is the following: > > let $file := 'collection.xconf' > let $full-path := xs:anyURI(concat($sys-collection, '/', $file)) > > (: Just add these two lines before running reindex() :) > let $doc := doc($full-path) > let $store := xmldb:store($sys-collection, $file, $doc) > > let $reindex := xmldb:reindex($data-collection) > > I also checked that the mime-type is the same. > > let $mime-type := xmldb:get-mime-type($full-path) > > Thanks for the hints. This has been bugging me for months! > > - Dan > > On Wed, May 25, 2011 at 2:02 PM, Dave Finton <dav...@gm...>wrote: > >> I'm attempting to automate the process of adding a collection of data to >> the lucene indexer via XQuery by taking a template collection.xconf file and >> using "xmldb:store" to save the file under the /db/system/config collection >> in eXist. Afterwards, I use some "update replace" trickery to make sure >> lucene is pointing at the correct XML tags in my collection. I then tell >> lucene to re-index the collection I want it to do (which appears to run >> without a hitch). The problem is that the lucene module refuses to index my >> data, resulting in search returning null results, unless I do the following >> to my automatically generated collection.xconf file: >> >> 1) Open the collection.xconf file in Oxygen >> 2) Add a space character somewhere in the file >> 3) Delete that one space from the file >> 4) Save it and re-import it back to eXist >> 5) Instruct lucene to re-index. >> 6) Perform the search again, and now it works >> >> I've done a diff on both the original xconf file and the one I saved after >> editing it, and the two version are identical in every respect, including >> user/group ownerships and permissions. >> >> After several hours of troubleshooting this morning, I've reached the >> conclusion that Oxygen does some sort of magic that neither "xmldb:store" >> nor "update replace" are doing to collection.xconf when storing it in the >> proper collection. I've looked at file content (no changes were made except >> for what I mentioned above) and permissions/ownership (neither of these >> attributes change after saving it via Oxygen, refreshing, and viewing the >> properties within Oxygen). >> >> One of my colleagues suggested that Oxygen somehow flags the file as >> "dirty" in some respect, forcing lucene to recognize the xconf file before >> it indexes my data. If that's the case, is there way I can get xquery to do >> the same when it stores the document to the /db/system/config/etcetera >> collection? Right now the only two operations I perform on the file is >> "xmldb:store" to create the file and "update replace" to modify it. After >> that, the only way I can force lucene to see that it's there is to open the >> file in Oxygen and re-save it. >> >> I'd send debug output, but so far I haven't been able to generate any >> errors related to what I'm trying to do. The only symptom I've been able to >> identify is that the search operations return 0 results until I implement my >> workaround. >> >> I'm running eXist 1.5.0 rev 14379 with Java 1.6.0 on CentOS 5.6 64-bit. >> >> -- >> David Finton >> >> >> ------------------------------------------------------------------------------ >> vRanger cuts backup time in half-while increasing security. >> With the market-leading solution for virtual backup and recovery, >> you get blazing-fast, flexible, and affordable data protection. >> Download your free trial now. >> http://p.sf.net/sfu/quest-d2dcopy1 >> _______________________________________________ >> Exist-open mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-open >> >> > > > -- > Dan McCreary > Semantic Solutions Architect > office: (952) 931-9198 > cell: (612) 986-1552 > -- David Finton |