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] > <mailto:[email protected]>> 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] >> <mailto:[email protected]>> 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 <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+ >>>> <mailto:[email protected]> <>unsubscribe >>>> <mailto:[email protected]>@googlegroups.com >>>> <mailto:[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] <>. >>> 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] >> <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] > <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.
