Hi Melody,

I think that error was due to your alternative id column being nil on creation? 
I’ve just pushed a commit that allows for that scenario, but if I’ve diagnosed 
correctly, I’d recommend ensuring the id is set before the initial save, just 
to be sure.

If I’ve got it wrong though, do let me know :)

— 
Pat

> On 20 Jul 2017, at 1:23 am, Melody B <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> 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
>  
> <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 <http://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 <http://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.
>>>>>> My database is postgres has uuid primary keys
>>>>>> 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
>>>>>> I set secondary_id as the primary key for sphinx in the index definition 
>>>>>> with the following code:
>>>>>> 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 thinking-sphi...@ <>googlegroups.com 
>>>>>> <http://googlegroups.com/>.
>>>>>> 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 
>>>>>> <https://groups.google.com/group/thinking-sphinx>.
>>>>>> For more options, visit https://groups.google.com/d/optout 
>>>>>> <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 
>>>>> <https://groups.google.com/group/thinking-sphinx>.
>>>>> For more options, visit https://groups.google.com/d/optout 
>>>>> <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 
>>>> <https://groups.google.com/group/thinking-sphinx>.
>>>> For more options, visit https://groups.google.com/d/optout 
>>>> <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 
>>> <https://groups.google.com/group/thinking-sphinx>.
>>> For more options, visit https://groups.google.com/d/optout 
>>> <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 
>> <https://groups.google.com/group/thinking-sphinx>.
>> For more options, visit https://groups.google.com/d/optout 
>> <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] 
> <mailto:[email protected]>.
> To post to this group, send email to [email protected] 
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/thinking-sphinx 
> <https://groups.google.com/group/thinking-sphinx>.
> For more options, visit https://groups.google.com/d/optout 
> <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