#17 ✓ rejected
Peer Allan

Multiple Rails app using a single solr server

Reported by Peer Allan | September 25th, 2009 @ 09:01 AM | in Feature Requests

This is a feature request for support of using multiple rails applications with conflicting model names being able to operate on the same solr. Here is an example

Blog App:
class Post < ActiveRecord::Base
searchable do

string :title

end end

Stickies App:
class Post < ActiveRecord::Base
searchable do

string :title

end end

In this case both applications are configured to connect to http://search.myserver.com:8990 for production use. The problem is that since the model names are the same they will clobber/merge into each other in the Solr index. This could cause solr search results from the Blog app to appear in the Stickies app. The only way around this right now is to run 2 instances of solr, one for each app (I think). Off the cuff, it looks like the quick solution would be to namespace the indexes in some manner.

I have not delved into the code yet to see how to do this. I wanted to get this ticket in here so there is a record of the idea. Also, your "competition", acts_as_solr, does not support this either

Peer

Comments and changes to this ticket

  • mat

    mat September 25th, 2009 @ 09:40 AM

    It's definitely a good idea - I think the best option would be to add an "app_name" (or something) field to the schema, which would be configured globally within an app (e.g., Sunspot.config.app_name = "myapp") and then, if present, would be saved with every document and used as a filter for every search.

  • benjamin

    benjamin September 25th, 2009 @ 11:10 AM

    solr supports several indices in one index. It's called multicore and it allows you to store the index data for one app in one index, and the data for another app in another index. All you need to attach on your solr requests is a core-parameter to identify, where to store/retrieve the data.

    mat's app_name could be the name of the core..

  • mat

    mat September 25th, 2009 @ 11:13 AM

    I've already accepted a good patch that adds multicore support into Sunspot/Sunspot::Rails, although I don't recall whether it's in the latest stable - Peer, would that be sufficient for your needs?

  • mat

    mat October 19th, 2009 @ 09:52 AM

    • State changed from “new” to “rejected”

    I think the way to do this would be multicore.

  • Tomasz Korzeniowski

    Tomasz Korzeniowski December 1st, 2009 @ 04:29 AM

    • Tag set to multicore

    Hi Mat, where I could find some information how to use Solr multicore with sunspot.
    Is adjust_solr_params (in Query class) method that I should use to pass name of the core that should be used?

  • mat

    mat December 1st, 2009 @ 07:36 AM

    Tomasz,

    I haven't done any multi-core work myself, but my impression (seemingly confirmed by a cursory glance here: http://wiki.apache.org/solr/CoreAdmin) is that cores are specified as part of the Solr URL path - so all you'd need to do is something to the effect of:

    Sunspot.config.solr.url = 'http://localhost:8983/solr/core1'
    

    Let me know if that helps.

  • Tomasz Korzeniowski

    Tomasz Korzeniowski December 1st, 2009 @ 10:20 AM

    • Tag cleared.

    Well... what I would like to achieve is to define three cores in Solr. One for English version of content, one for Swedish version of content and one for all content. I would like different analyzers to be executed for each of the cores. In general there will be three Lucene index-es.
    I would like to index in my Rails app Article model object and based on the value of locale attribute decided where object should be indexed (I mean in which core.)
    Mat, do you have any recommendation or suggestions?

  • Tomasz Korzeniowski

    Tomasz Korzeniowski December 1st, 2009 @ 10:30 AM

    It look like the best option would be to extend Solr and write a custom http://wiki.apache.org/solr/SolrRequestHandler that will decided what core should be used based on the param in the request. Please let me know what do you think.

  • mat

    mat December 1st, 2009 @ 10:35 AM

    Yep - you'll want to use multiple Sunspot::Session objects, one pointing to each core. You can either then manually call session.index() and session.search() depending on the model, or, more cleverly, use a Session Proxy (this would only be possible if all of your indexed models implement an interface to determine their locale):

    class LocaleSessionProxy
      LOCALES = %w(english swedish)
    
      def initialize
        @locale_sessions = {}
        LOCALES.each do |locale|
          session = Sunspot::Session.new
          session.config.solr.url = "http://localhost:8983/solr/#{locale}"
          @locale_sessions[locale] = session
        end
        @global_session = Sunspot::Session.new
        @global_session.config.solr.url = "http://localhost:8983/solr/global"
      end
    
      def session_for_locale(name)
        if name
          @locale_sessions[name.to_s]
        else
          @global_session
        end
      end
    
      def index(*models)
        models.group_by { |model| model.locale }.each_pair do |locale, locale_models|
          session_for_locale(locale).index(locale_models)
        end
        @global_session.index(models)
      end
    
      def search(locale = nil, &block)
        session_for_locale(locale).search(&block)
      end
    
      # etc. - implement all methods of the Sunspot::Session class to delegate to the appropriate session(s)
    end
    

    In an initializer, you'd put Sunspot.session = LocaleSessionProxy.new so that the Sunspot singleton delegates to your proxy.

    You'd then want to override the Sunspot::Rails::Searchable::ClassMethods#search method to take a locale argument, and pass it on to Sunspot.search.

    Let me know if that makes sense!

  • Anders Jacobsson

    Anders Jacobsson March 6th, 2011 @ 03:54 PM

    • Milestone order changed from “0” to “0”

    This is sort of what I would like to do so this was certainly interesting to read. I would like to use multiple cores in Solr, one for each locale, but with localized field names. The model is not locale-specific as suggested above so the index data will be duplicated but that is fine (not so much data).

    The session proxy would be quite easy to implement, just do pretty much as described above. However, I am unsure of how to extend Sunspot::Rails::Searchable, it seems like it is difficult to keep the clean separation of the DSL and the Rails part. Any suggestions?

    I could of course add multiple names (one per language) for each field in the Rails models and use the same index for all of them. But adding a language at a later time would require reindexing but with a separate core, I would only need to index for the new language.

  • Amit Pandey

    Amit Pandey May 17th, 2013 @ 02:21 AM

    Hi Mat,
    I had multiple apps for different platforms and data is served through SOLR, currently SOLR is using same database and data is filtered through key, Now i want to configure the same SOLR project for different databases which contains different data but structure is same for all databases so that there is no further need to paas key in each request and different apps can hit there respective database only. How to index same SOLR project for different databases and use the desired index only for each request ???

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

Awesome Solr interaction for Ruby

People watching this ticket

Pages