Similar-looking bug now here:

NoMethodError:
  undefined method `*' for nil:NilClass
~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-c45b52438001/lib/thinking_sphinx/core/index.rb:33:in
 
`document_id_for_key'
~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-c45b52438001/lib/thinking_sphinx/core/index.rb:29:in
 
`document_id_for_instance'
~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-c45b52438001/lib/thinking_sphinx/deltas/default_delta.rb:16:in
 
`delete'
~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-c45b52438001/lib/thinking_sphinx/active_record/callbacks/delta_callbacks.rb:14:in
 
`block in after_commit'
~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-c45b52438001/lib/thinking_sphinx/active_record/callbacks/delta_callbacks.rb:13:in
 
`each'
~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-c45b52438001/lib/thinking_sphinx/active_record/callbacks/delta_callbacks.rb:13:in
 
`after_commit'
~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-c45b52438001/lib/thinking_sphinx/callbacks.rb:7:in
 
`block (2 levels) in callbacks'


I'm guessing there will probably end up being a couple more of these? If I 
find the time I can try to submit a PR, but I'm pretty swamped with other 
commitments today. Thanks for being so responsive and helpful with this!

~ Melody

On Wednesday, July 19, 2017 at 10:54:51 AM UTC-4, Pat Allan wrote:
>
> Okay, just pushed a commit to the develop branch which should help get the 
> ball rolling:
>
> https://github.com/pat/thinking-sphinx/commit/c45b5243800124f2c5d60f05fa501ed1cdca32d4
>
> Give that a shot, and if you hit any further problems, do let me know. PRs 
> are certainly welcome, though I’m well aware there’s a lot of code in TS, 
> so any confusion is completely understandable. :)
>
> — 
> Pat
>
> On 20 Jul 2017, at 12:05 am, Pat Allan <[email protected] 
> <javascript:>> wrote:
>
> Definitely looks like a bug to me - and now that I’m investigating 
> further, it looks like there are several bugs. Am putting some integration 
> specs in place and working on getting the alternative-id feature actually 
> working! Though it’s midnight here, so it’s likely something I’ll get a bit 
> further on tomorrow.
>
> On 19 Jul 2017, at 11:43 pm, Melody B <[email protected] <javascript:>> 
> wrote:
>
> A little update:
>
> I'm currently running the latest development version of thinking-sphinx from 
> github, riddle 2.2.0, and told sphinx to treat the uuid keys as strings. 
> Configuration generates now, but I'm getting the same error I was when I 
> locally patched my gem version before I reached out -- whenever I try to 
> save a new instance of my indexed model it fails with this stack trace:
>
> TypeError:
>   no implicit conversion of Fixnum into String
> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-9860c9452279/lib/thinking_sphinx/core/index.rb:29:in
>  
> `+'
> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-9860c9452279/lib/thinking_sphinx/core/index.rb:29:in
>  
> `document_id_for_key'
> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-9860c9452279/lib/thinking_sphinx/deltas/default_delta.rb:16:in
>  
> `delete'
> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-9860c9452279/lib/thinking_sphinx/active_record/callbacks/delta_callbacks.rb:14:in
>  
> `block in after_commit'
> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-9860c9452279/lib/thinking_sphinx/active_record/callbacks/delta_callbacks.rb:13:in
>  
> `each'
> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-9860c9452279/lib/thinking_sphinx/active_record/callbacks/delta_callbacks.rb:13:in
>  
> `after_commit'
> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/bundler/gems/thinking-sphinx-9860c9452279/lib/thinking_sphinx/callbacks.rb:7:in
>  
> `block (2 levels) in callbacks'
> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/activesupport-4.2.8/lib/active_support/callbacks.rb:455:in
>  
> `public_send'
>
>
> Taking a cursory glance at the delete method in DefaultDelta I'm 
> wondering if this is perhaps possibly the culprit?
>  
>
> def delete(index, instance)
>   ThinkingSphinx::Deltas::DeleteJob.new(
>     index.name, index.document_id_for_key(instance.id)
>   ).perform
> end
>
>  
> I don't know much about how the pieces of this fit together, but I 
> wouldn't expect instance.id to be the correct key to fetch on when an 
> alternative primary key has been defined. I can continue to try to chase 
> this down and perhaps submit a PR if you think this is likely a bug, or try 
> to find a minimally reproducing example that I can share so that we can 
> rule out configuration or environment issues? I'm open to suggestions on 
> how best to proceed.
>
> ~ Melody
>
> On Wednesday, July 19, 2017 at 3:22:37 AM UTC-4, Pat Allan wrote:
>>
>> It doesn’t look like you have MVAs - the example you shared is a field 
>> (via the `indexes` method), and your right, the joins using UUID columns to 
>> get to that data should be fine. The attributes (via the `has` method) you 
>> have listed, as you’ve noted, are UUIDs and strings should do the trick 
>> there.
>>
>> So, maybe Sphinx and TS can actually do what’s needed? Do you want to 
>> talk about what’s now not working?
>>
>> Cheers,
>>
>> — 
>> Pat
>>
>> On 19 Jul 2017, at 12:49 pm, Melody B <[email protected]> wrote:
>>
>> I'm not sure whether I need multi-value attributes or not, the only line 
>> I have in here that's particularly similar to the one you quoted is this:
>>
>> indexes choices.option.canonical_name, as: :option_names
>>
>>
>> In order to get that data, you would need to join choices and option on 
>> uuid columns, as all of these models have uuid primary & foreign keys. I 
>> don't think I have any that do this specifically for ids, I defined these 
>> to get it to stop crashing on configure:
>>
>> has response_id, type: :string
>> has response.mission_id, type: :string
>> has questioning.question_id, type: :string
>>
>>
>> But it still doesn't seem to be working -- this may have more to do with 
>> my app code than thinking sphinx/sphinx though, I haven't gotten deep into 
>> sorting it out now that it's no longer completely broken. I'll try updating 
>> to develop, a newer riddle, and making sure I'm on a good version of sphinx 
>> (I'm on 2.2.11 locally, and could hopefully update production instances if 
>> necessary)
>>
>> I've been getting slowly resigned to the fact that I may need to switch 
>> search solutions (and actually already tried switching to pg_search because 
>> in terms of the actual search features we're taking advantage of our needs 
>> are really very mild and removing an external dependeny seemed like a net 
>> benefit in terms of future maintenance) but it can't do 
>> highlighting/excerpting on searches against associations (weird bug) and 
>> hasn't updated to expose an interface for postgres 9.6's exact phrase 
>> matching yet. I've been trying to evaluate other solutions, but finding 
>> info about which ones support the exact weird combination of constraints 
>> I'm dealing with when they support each thing I want to do separately is a 
>> bit of a challenge.
>>
>> In any case, thanks so much for your help!
>>
>> ~ Melody
>>
>> On Tuesday, July 18, 2017 at 10:09:35 PM UTC-4, Pat Allan wrote:
>>>
>>> Hmm. The recent versions of Sphinx do support filtering on string 
>>> attributes, so you could possibly set the explicit `:type => :string` for 
>>> attributes based on UUID columns. However, that’ll only work for 
>>> single-value attributes (and additionally, you’ll want to use the latest in 
>>> the `develop` branch for TS and ensure the bundled version of the Riddle 
>>> gem is v2.2.0, as there are some changes around properly quoting string 
>>> attributes in search queries).
>>>
>>> If you’re not across the Sphinx terminology, a multi-value attribute 
>>> (MVA) is essentially an attribute with a data type of array, but the arrays 
>>> can only hold integers. So, in practice it might look something like the 
>>> following in a TS index definition:
>>>
>>>     has users.id, :as => :user_ids
>>>
>>> I’d expect, however, that TS is fine with generating SQL joins across 
>>> UUID keys - it’s just the actual attribute values being the issue. If you 
>>> need multi-value UUID attributes, then it feels like your paths are either 
>>> adding fake foreign keys, or switching to a different search tool - and I’m 
>>> sure neither of those options are particularly simple. Fingers crossed that 
>>> you only need single-value attributes for the UUID columns?
>>>
>>> Feel free to ask any further questions :)
>>>
>>> — 
>>> Pat
>>>
>>> On 19 Jul 2017, at 11:36 am, Melody B <[email protected]> wrote:
>>>
>>> Thanks, I forgot that I had locked my version to 3.1.x in my gemfile 
>>> when I tried to update the gem, so I hadn't noticed that I wasn't on the 
>>> latest. I feel a bit silly now. I'm now getting a different error relating 
>>> to my foreign keys (which are also uuid) not mapping to a valid sphinx 
>>> type. 
>>>
>>> Is there a way around this besides adding additional fake foreign keys 
>>> to go with my fake primary keys and putting those on every model I need 
>>> sphinx to be aware of? Would there even be a way to configure thinking 
>>> sphinx so that it tried to find the associated records through those 
>>> instead? Unfortunately I genuinely do need UUID keys for this app.
>>>
>>> ~ Melody
>>>
>>> On Tuesday, July 18, 2017 at 9:11:04 PM UTC-4, Pat Allan wrote:
>>>>
>>>> Hi Melody,
>>>>
>>>> There was a couple of commits related to fixing alternative primary 
>>>> keys that are part of v3.3.0 - I realise if you’re not familiar with this 
>>>> gem or Sphinx it could be daunting, but I’d recommend upgrading if at all 
>>>> possible.
>>>>
>>>> The release notes for v3.2.0 and v3.3.0 (the only releases since 
>>>> v3.1.4) cover off notable changes - I’d say there’s a good chance you 
>>>> won’t 
>>>> hit any issues though:
>>>> https://github.com/pat/thinking-sphinx/releases/tag/v3.2.0 
>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fpat%2Fthinking-sphinx%2Freleases%2Ftag%2Fv3.2.0&sa=D&sntz=1&usg=AFQjCNHh69DuVoiXcTHiNlQYsZTDWlq_TA>
>>>> https://github.com/pat/thinking-sphinx/releases/tag/v3.3.0 
>>>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fpat%2Fthinking-sphinx%2Freleases%2Ftag%2Fv3.3.0&sa=D&sntz=1&usg=AFQjCNGTQohrWlNsNkBgQ_IFFcGiTo8UzQ>
>>>>
>>>> If the error (or something like it) is still happening on v3.3.0, do 
>>>> let me know!
>>>>
>>>> Cheers,
>>>>
>>>> — 
>>>> Pat
>>>>
>>>> On 19 Jul 2017, at 8:10 am, Melody B <[email protected]> wrote:
>>>>
>>>> I'm getting an error on configure:
>>>>
>>>> Generating configuration to ~/myapp/config/development.sphinx.conf
>>>> rake aborted!
>>>> NoMethodError: undefined method `<<' for nil:NilClass
>>>> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/active_record/sql_source.rb:96:in
>>>>  
>>>> `block in append_presenter_to_attribute_array'
>>>> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/active_record/sql_source.rb:93:in
>>>>  
>>>> `each'
>>>> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/active_record/sql_source.rb:93:in
>>>>  
>>>> `append_presenter_to_attribute_array'
>>>> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/active_record/sql_source.rb:131:in
>>>>  
>>>> `prepare_for_render'
>>>> ~/.rbenv/versions/2.2.0/lib/ruby/gems/2.2.0/gems/thinking-sphinx-3.1.4/lib/thinking_sphinx/active_record/sql_source.rb:65:in
>>>>  
>>>> `render'
>>>>
>>>>
>>>> I have a few weird things going on in my setup that are (probably?) 
>>>> having an impact.
>>>>
>>>>    1. My database is postgres has uuid primary keys
>>>>    2. I defined a custom field that generates a bigint in a 
>>>>    before_create callback called secondary_id -- this seemed like the 
>>>>    best way to provide sphinx with something it could index on but if this 
>>>> is 
>>>>    the wrong way to go about keeping my uuid primary keys i'm open to 
>>>>    alternative suggestions
>>>>    3. I set secondary_id as the primary key for sphinx in the index 
>>>>    definition with the following code:
>>>>       1. ThinkingSphinx::Index.define :answer, with: :active_record, 
>>>>       primary_key: :proxy_id do ... end
>>>>       
>>>> I'm honestly not sure what's going on here -- I tried poking around in 
>>>> the code to sort out why this was happening and I tried guarding for 
>>>> nil on that line allows configuring to finish, but it predictably 
>>>> continues to explode during actual operation when I create a new instance 
>>>> of
>>>>  :answer -- I knew that was a longshot, but any help would be 
>>>> appreciated. I'm not particularly experienced with sphinx or 
>>>> thinking-sphinx, I inherited this project after it was already in 
>>>> place (the move to uuid primary keys is fairly recent, and this is the 
>>>> last 
>>>> major blocker) so just let me know if you need any additional info or 
>>>> context.
>>>>
>>>> -- 
>>>> You received this message because you are subscribed to the Google 
>>>> Groups "Thinking Sphinx" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send 
>>>> an email to [email protected].
>>>> To post to this group, send email to thinkin...@googlegroups. 
>>>> <http://googlegroups.com/>com <http://googlegroups.com/>.
>>>> Visit this group at https://groups.google.com/group/thinking-sphinx.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Thinking Sphinx" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to thinking-sphinx+ <javascript:>unsubscribe <javascript:>
>>> @googlegroups.com <javascript:>.
>>> To post to this group, send email to [email protected].
>>> Visit this group at https://groups.google.com/group/thinking-sphinx.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Thinking Sphinx" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected].
>> To post to this group, send email to [email protected].
>> Visit this group at https://groups.google.com/group/thinking-sphinx.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Thinking Sphinx" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> To post to this group, send email to [email protected] 
> <javascript:>.
> Visit this group at https://groups.google.com/group/thinking-sphinx.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Thinking Sphinx" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> To post to this group, send email to [email protected] 
> <javascript:>.
> Visit this group at https://groups.google.com/group/thinking-sphinx.
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Thinking Sphinx" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/thinking-sphinx.
For more options, visit https://groups.google.com/d/optout.

Reply via email to