indexing to non-dynamic, pre-defined fields
Jason Ronallo
I'm using Sunspot to index Rails resources to Solr. Within my
searchable block is there a way to index to non-dynamic, pre-defined
fields? Is there any other way than setting lots of copyfields in my
Solr schema.xml?
I won't necessarily be using Sunspot for searching this index. I just
like having a simple DSL for indexing that also hooks into the
ActiveRecord lifecycle nicely so I don't have to concern myself with
those pieces.
Jason
Mat Brown
In Sunspot 1.2 you can use the :as option to explicitly specify the field name in Solr that you'd like to use.
Jason Ronallo
I have solr fields title_display and subject_facet I'm trying to index to.
searchable do
string :title_display, :as => :title_display do |resource|
resource.title
end
string :subject_facet, :as => :subject_facet do |r|
r.subjects.map{|s| s.subject}
end
end
This works in the case of a non-multiValued field in the case of
title_display. It fails for subject_facet with the error
"subject_facet is not a multiple-value field, so it cannot index
values". Including the option :multiple => true results in a different
error:
Solr Response: ERRORunknown_field_subject_facetm
Do I have my syntax wrong? If not it seems that in the case where the
:as option is specified it ought to either:
1. Not require the :multiple option to index an array. Someone using
the :as option will have to know their own Solr schema enough to know
whether the field is multiValued or not. So either a single value or
an Array ought to be accepted.
2. Require the :multiple option for indexing arrays, but not append
the "m" to the end of the field name. If :as is specified, then
Sunspot should never change that name based on any options.
Other options for this behavior? Or maybe I'm misunderstanding the
purpose of the :as option?
BTW, I've been unable to find a key for what all the Sunspot dynamic
field name suffixes mean. Where would I look for this?
Jason
> --
> You received this message because you are subscribed to the Google Groups
> "Sunspot" group.
> To post to this group, send email to ruby-s...@googlegroups.com.
> To unsubscribe from this group, send email to
> ruby-sunspot...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/ruby-sunspot?hl=en.
>
Mat Brown
Good catch -- #2 should be the behavior ; it's a bug that it isn't.
Built in schema.xml is as good a guide as any.
Jason Ronallo
I've added a ticket for this and created a branch on my fork of
sunspot with a potential fix. An example was added to the post mock
and spec added to attributes_spec.rb.
Branch:
https://github.com/jronallo/sunspot/tree/as_and_multiple
Commit diff:
https://github.com/jronallo/sunspot/commit/f2521f33723d6ace00a7ee92f9f8c9c81401e85a
Please let me know if there's anything else I can do to help fix this bug.
Jason
Mat Brown
@indexed_name variable, calculated at initialization time, which is
always the fully correct value. Then the #indexed_name method just
becomes an attr_reader . Does that make sense?
Jason Ronallo
getting at, but maybe you can tell me if I'm on the right track with
this:
https://github.com/jronallo/sunspot/tree/as_and_typed_indexed_name
Commits:
https://github.com/jronallo/sunspot/commit/00c0d0692ef6f1ded831499cb2195caa135af0e8
https://github.com/jronallo/sunspot/commit/f393947ac75e8d7c8020f7bc694b5f76cd02f26c
This eliminates the duplication in creating the indexed_name suffixes
that was happening between AttributeField and FulltextField. The
suffixes tested for between those classes varied slightly so maybe
there's a test missing for that difference. Maybe a FulltextField
should never have the multiple suffix even though multiple is always
true? I didn't see an explicit test for that.
This probably only works now because of the order in which the
AttributeField and FulltextField initializers assign to @multiple is
different. Also, since it is currently impossible to explicitly set
the option :multiple for a FulltextField because of the options.empty?
check.
I was still not able to get rid of FulltextField#indexed_name without
failing a lot of tests seemingly because of some interaction there
with boosting. FulltextField#indexed_name has been simplified to only
include a call to super, though.
Hopefully this is more on the right track.
Jason