Dear Gert, We are looking at a use case for GSearch that requires a remote solr installation. For the most part GSearch has worked very well for us. To more easily enable this use case in the future, though, I'd like to recommend two relatively small changes:
1. don't require a local index if you're not going to use it. Adam already mentioned this, and you're right, you can just create a fake, empty lucene index to point to, but I'm pleased to see you're considering removing that requirement from future releases. 2. don't require a field name of "PID" in solr. It's reasonable to require some unique id field to store the fedora PID in, but a requirement that the field name be a hardcoded value prevents easy integration with existing solr indexes (ours, for example, calls that field "id"). We were able to work around this by making some minor changes to the code and re-compiling, but again it would be great for future users not to have to do that, and I'd certainly prefer not to be using a locally modified version of the source code, which is bound to cause problems one day down the road when we upgrade and forget to make that change again. Would you be interested in a code patch that addressed either of these issues? These are such minor changes I'm not sure the patch is worth it, but I thought I'd offer anyway. Thanks for such a great piece of software that has solved a major problem for us. Bess On Jun 18, 2009, at 5:41 AM, Gert Schmeltz Pedersen wrote: >> the dependency on a mock local index > > can be avoided by a few code changes in a future release, but it > works as it is. > >> host their Solr instance(s) remotely from their GSearch instance to >> still benefit from GSearch's search functionality > > Well, GSearch's search functionality for the Solr plugin depends on > local file access to the lucene index directory, this can hardly be > done for a remote solr instance. What gsearch could do is receiving > a gfindObjects operation from you and passing it on to solr by > sending a solr http request with the query. This is the extra web > service call that I mentioned yesterday, because you might just as > well send your http request directly to solr instead of through > gsearch. > > -Gert > >> -----Original Message----- >> From: ajs6f [mailto:[email protected]] >> Sent: Wednesday, June 17, 2009 3:56 PM >> To: [email protected] >> Subject: Re: [Fedora-commons-users] GSearch with remote SOLR >> instance? >> >> It would avoid the dependency on a mock local index, and it would >> permit those who wish to host their Solr instance(s) remotely from >> their GSearch instance to still benefit from GSearch's search >> functionality. It's not clear to me how that could happen with the >> current code. >> >> --- >> A. Soroka >> Digital Research and Scholarship R & D >> the University of Virginia Library >> >> >> >> >> >> On Jun 17, 2009, at 9:43 AM, Gert Schmeltz Pedersen wrote: >> >>> >>>> Are there plans to rewrite the FgsSolr module to use the Solr Web >>>> interface for searching in future? >>> >>> No. It seems to me that nothing is gained by doing that, and it >>> would cost an extra web service call for each search. If you or >>> others see some benefit of it, please tell me. >>> >>> -Gert >>> >>>> -----Original Message----- >>>> From: ajs6f [mailto:[email protected]] >>>> Sent: Wednesday, June 17, 2009 2:26 PM >>>> To: [email protected] >>>> Subject: Re: [Fedora-commons-users] GSearch with remote SOLR >>>> instance? >>>> >>>> Indeed, that worked very well. We've gone beyond that now to a >>>> local >>>> build of GSearch's Solr module that ignores the local index. This >>>> effectively disables GSearch's ability to search. We don't mind >> this, >>>> because we are querying Solr by other means (Blacklight). >>>> >>>> Thanks very much! >>>> >>>> Are there plans to rewrite the FgsSolr module to use the Solr Web >>>> interface for searching in future? >>>> >>>> --- >>>> A. Soroka >>>> Digital Research and Scholarship R & D >>>> the University of Virginia Library >>>> >>> >> >> >> ----------------------------------------------------------------------- >> ------- >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables unlimited >> royalty-free distribution of the report engine for externally facing >> server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> Fedora-commons-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/fedora-commons-users > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Fedora-commons-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/fedora-commons-users ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Fedora-commons-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fedora-commons-users
