solr_query.rb

  def find_associate_common user_ids

    # search types
    @selected_types = []
    @selected_types << 'User'.constantize

    # default fields to search
    @default_assoc_search_fields = ['last_name_text', 'first_name_text', 'middle_name_text', 'email_text', 'city_region_text', 'country_text']

    @search_all_profile = params[:search_all_profile] ||= false

    # selected content search type
    @selected_search_type = params[:stype].present? ? params[:stype] : 'anyword'

    @selected_specialty_search_type = params[:sptype].present? ? params[:sptype] : 'anyspec'

    # include professional bio fields
    @include_professional_bio = params[:cpbio].present? ? params[:cpbio] : 'false'

    # include personal bio fields
    @include_personal_bio = params[:cpbio].present? ? params[:cpbio] : 'false'

    # set up pagination
    cur_page = params[:page] ||= 1
    per_page = params[:per_page] ||= 10

    # setup the search type and value...
    @q = params[:assoc_keywords] ||= nil
    qry_empty = @q.nil? || @q.blank? || @q.empty?

    # 02-JUL-2012 - downcase the search string.  For some reason lucene won't find "Finn" as part of a "standard" query
    #               but does find "finn".
    qry = @q.downcase

    qry = qry + "*" if qry.size < 5

    if !qry.nil?
      qry.strip!
      logger.debug "qry(1): #{qry}"
      case @selected_search_type
        when 'allwords'
          qry = "(#{qry.gsub(' ', ' AND ')})"
        when 'exact'
          qry = "\"#{qry}\""
        else
          # defaults to any words...
      end
    end
    logger.debug "qry(2): #{qry}"
    qry = "( #{qry} ) AND " if !qry.blank?
    qry += ' !agent_categories_text:"Alternate Contact" '

    # check for specialties
    aspec_qry = ""
    aspec_op = @selected_specialty_search_type == 'anyspec' ? " OR " : " AND "
    qt_param = "standard"
    if params[:search_for_specialties] == '1' && params[:agent_specialties].present? && params[:agent_specialties][:specialty_id].present?
      params[:agent_specialties][:specialty_id].each do |spec_id|
        aspec_qry += "specialty_tags_text:\"#{AgentSpecialtyList[spec_id.to_i].name}\" #{aspec_op} "
        # still trying to figure out when / how to use dismax
        # it seems that when we're searching against the main "text" (e.g., keywords)
        # and are also searching specific fields for content (e.g., specialties) then
        # dismax is the way to go. otherwise, leave the qt_param empty so solr / lucene
        # use the "standard" search parser
        qt_param = "standard" if qt_param == "" && !qry_empty
        qry_empty = false
      end
      aspec_qry.chomp!("#{aspec_op} ").strip!
      aspec_qry = " ( #{aspec_qry} )" unless aspec_qry == ""
    end

    qry += " AND " if qry != "" && aspec_qry != ""
    qry += aspec_qry
    logger.debug "qry: #{qry}"

    logger.debug "qry: #{qry}"

    # check for market longitude / latitutde

    # run the search with paginated results
    @results = Sunspot.search(@selected_types) do

      # setup a full text query
      fulltext qry

      # adjust the solr parameters as needed
      adjust_solr_params do |param|
        # use the qt param vs the deftype param - not sure why but solr's dismax parser works better with the :qt option
        param[:defType] = ''
        param[:qt] = qt_param if qt_param != ""
        param[:sort] = 'score desc, last_name_text asc'
        #param[:qt] = 'dismax'
        #param[:qt] = 'standard'
        #param[:qf] << " content_text"
      end

      # setup pagination
      paginate :page => cur_page, :per_page => per_page

    end unless qry_empty

  end

You can enable solr debugging output in the sunspot results like this:

@results = Sunspot.search do
  fulltext qry

  adjust_solr_params do |param|
    param['debugQuery'] = 'on'
    # ...
  end
end

And you can access it in the result with a hack like this: @results.try(:instance_variable_get, :@solr_result).try(:[], 'debug')

That will yield a hash with keys like querystring, timing, and explain (I personally love explain as it makes it really helpful to determine why results came back the way they did, which can be a common client/user question.)

You can also see the XML in the results, I believe -- not sure the debug key to use.