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] <javascript:>>
> 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:>[email protected]
>> <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] <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.
