Hi, 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.
In Sunspot 1.2 you can use the :as option to explicitly specify the field name in Solr that you'd like to use. On Nov 10, 2010 2:18 PM, "Jason Ronallo" <jrona...@gmail.com> wrote:
Upgrading to sunspot_rails 1.2 pre some of this worked.
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?
On Wed, Nov 10, 2010 at 2:36 PM, Mat Brown <m...@patch.com> wrote: > In Sunspot 1.2 you can use the :as option to explicitly specify the field > name in Solr that you'd like to use.
> On Nov 10, 2010 2:18 PM, "Jason Ronallo" <jrona...@gmail.com> wrote:
> -- > You received this message because you are subscribed to the Google Groups > "Sunspot" group. > To post to this group, send email to ruby-sunspot@googlegroups.com. > To unsubscribe from this group, send email to > ruby-sunspot+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/ruby-sunspot?hl=en.
> Upgrading to sunspot_rails 1.2 pre some of this worked.
> 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
> On Wed, Nov 10, 2010 at 2:36 PM, Mat Brown <m...@patch.com> wrote: >> In Sunspot 1.2 you can use the :as option to explicitly specify the field >> name in Solr that you'd like to use.
>> On Nov 10, 2010 2:18 PM, "Jason Ronallo" <jrona...@gmail.com> wrote:
>> -- >> You received this message because you are subscribed to the Google Groups >> "Sunspot" group. >> To post to this group, send email to ruby-sunspot@googlegroups.com. >> To unsubscribe from this group, send email to >> ruby-sunspot+unsubscribe@googlegroups.com<ruby-sunspot%2Bunsubscribe@google groups.com> . >> For more options, visit this group at >> http://groups.google.com/group/ruby-sunspot?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Sunspot" group. > To post to this group, send email to ruby-sunspot@googlegroups.com. > To unsubscribe from this group, send email to
Mat, 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.
On Wed, Nov 10, 2010 at 6:17 PM, Mat Brown <m...@patch.com> wrote: > 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.
> On Nov 10, 2010 2:41 PM, "Jason Ronallo" <jrona...@gmail.com> wrote: >> Upgrading to sunspot_rails 1.2 pre some of this worked.
>> 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
>> On Wed, Nov 10, 2010 at 2:36 PM, Mat Brown <m...@patch.com> wrote: >>> In Sunspot 1.2 you can use the :as option to explicitly specify the field >>> name in Solr that you'd like to use.
>>> On Nov 10, 2010 2:18 PM, "Jason Ronallo" <jrona...@gmail.com> wrote:
>>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Sunspot" group. >>> To post to this group, send email to ruby-sunspot@googlegroups.com. >>> To unsubscribe from this group, send email to >>> ruby-sunspot+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/ruby-sunspot?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "Sunspot" group. >> To post to this group, send email to ruby-sunspot@googlegroups.com. >> To unsubscribe from this group, send email to >> ruby-sunspot+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/ruby-sunspot?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "Sunspot" group. > To post to this group, send email to ruby-sunspot@googlegroups.com. > To unsubscribe from this group, send email to > ruby-sunspot+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/ruby-sunspot?hl=en.
That patch works, but I'd actually rather just store a single @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?
On Wed, Nov 10, 2010 at 19:14, Jason Ronallo <jrona...@gmail.com> wrote: > Mat, > 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.
> Please let me know if there's anything else I can do to help fix this bug.
> Jason
> On Wed, Nov 10, 2010 at 6:17 PM, Mat Brown <m...@patch.com> wrote: >> 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.
>> On Nov 10, 2010 2:41 PM, "Jason Ronallo" <jrona...@gmail.com> wrote: >>> Upgrading to sunspot_rails 1.2 pre some of this worked.
>>> 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
>>> On Wed, Nov 10, 2010 at 2:36 PM, Mat Brown <m...@patch.com> wrote: >>>> In Sunspot 1.2 you can use the :as option to explicitly specify the field >>>> name in Solr that you'd like to use.
>>>> On Nov 10, 2010 2:18 PM, "Jason Ronallo" <jrona...@gmail.com> wrote:
>>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Sunspot" group. >>>> To post to this group, send email to ruby-sunspot@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> ruby-sunspot+unsubscribe@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/ruby-sunspot?hl=en.
>>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Sunspot" group. >>> To post to this group, send email to ruby-sunspot@googlegroups.com. >>> To unsubscribe from this group, send email to >>> ruby-sunspot+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/ruby-sunspot?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups >> "Sunspot" group. >> To post to this group, send email to ruby-sunspot@googlegroups.com. >> To unsubscribe from this group, send email to >> ruby-sunspot+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/ruby-sunspot?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Sunspot" group. > To post to this group, send email to ruby-sunspot@googlegroups.com. > To unsubscribe from this group, send email to ruby-sunspot+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/ruby-sunspot?hl=en.
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.
On Wed, Nov 10, 2010 at 7:23 PM, Mat Brown <m...@patch.com> wrote: > That patch works, but I'd actually rather just store a single > @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?
> On Wed, Nov 10, 2010 at 19:14, Jason Ronallo <jrona...@gmail.com> wrote: >> Mat, >> 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.
>> Please let me know if there's anything else I can do to help fix this bug.
>> Jason
>> On Wed, Nov 10, 2010 at 6:17 PM, Mat Brown <m...@patch.com> wrote: >>> 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.
>>> On Nov 10, 2010 2:41 PM, "Jason Ronallo" <jrona...@gmail.com> wrote: >>>> Upgrading to sunspot_rails 1.2 pre some of this worked.
>>>> 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
>>>> On Wed, Nov 10, 2010 at 2:36 PM, Mat Brown <m...@patch.com> wrote: >>>>> In Sunspot 1.2 you can use the :as option to explicitly specify the field >>>>> name in Solr that you'd like to use.
>>>>> On Nov 10, 2010 2:18 PM, "Jason Ronallo" <jrona...@gmail.com> wrote:
>>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Sunspot" group. >>>>> To post to this group, send email to ruby-sunspot@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> ruby-sunspot+unsubscribe@googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/ruby-sunspot?hl=en.
>>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Sunspot" group. >>>> To post to this group, send email to ruby-sunspot@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> ruby-sunspot+unsubscribe@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/ruby-sunspot?hl=en.
>>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Sunspot" group. >>> To post to this group, send email to ruby-sunspot@googlegroups.com. >>> To unsubscribe from this group, send email to >>> ruby-sunspot+unsubscribe@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/ruby-sunspot?hl=en.
>> -- >> You received this message because you are subscribed to the Google Groups "Sunspot" group. >> To post to this group, send email to ruby-sunspot@googlegroups.com. >> To unsubscribe from this group, send email to ruby-sunspot+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/ruby-sunspot?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "Sunspot" group. > To post to this group, send email to ruby-sunspot@googlegroups.com. > To unsubscribe from this group, send email to ruby-sunspot+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/ruby-sunspot?hl=en.
