tag:support.flying-sphinx.com,2011-01-05:/discussionsFlying Sphinx: Recent Discussions 2024-03-29T02:05:34Ztag:support.flying-sphinx.com,2011-01-05:Discussion/37721484922023-08-24T07:16:31Z2023-08-30T13:42:37ZHeroku Flying Sphinx changes status to Not Running randomly<div><p>Thanks for the update Daniel - things had been seeming fine on my side too, great to know that matches with what you've been seeing as well :)</p>
<p>Do let me know if any other issues crop up though!</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/15398755022022-09-08T16:40:48Z2022-09-10T07:51:31ZIssue in search data<div><p>Hi there,</p>
<p>As best as I can tell, this is due to memory limits on your MySQL database. I would recommend increasing the <code>sort_buffer_size</code> setting there and see if that helps resolve the problem.</p>
<p>I’ve discussed this issue with others using Thinking Sphinx here:<br>
<a href="https://github.com/pat/thinking-sphinx/issues/819">https://github.com/pat/thinking-sphinx/issues/819</a></p>
<p>Please do let me know if that doesn’t fix the issue!</p>
<p>Kind regards,</p>
<p>— Pat</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/8471335922022-06-20T03:42:18Z2022-06-20T05:10:56Zts:rebuild/ts:stop/ts:start not working on heroku <div><p>Thanks for the speedy response Pat!</p>
<p>I believe <code>fs:regenerate</code> is what I am after.</p>
<p>Upgrading is definitely in the pipeline, you know one day :)</p></div>Gaetantag:support.flying-sphinx.com,2011-01-05:Discussion/779817922022-04-09T20:48:49Z2022-04-10T19:06:52ZUnknown MySQL error<div><p>I resolved this, I cleared the build cache and it worked after next deploy.</p>
<p>There was no error with the previous build, so couldn't tell what was happening but tat fixed it.<br>
Thanks</p></div>Rtag:support.flying-sphinx.com,2011-01-05:Discussion/779816522022-04-09T20:12:06Z2022-04-10T00:01:58ZError deploying Flying Sphinx<div><p>Thanks, I have forced version 1 so not an issue for me. On Saturday, April 9, 2022, 03:55:11 PM PDT, Pat Allan <a href="mailto:tender+d46b4e4f26@tenderapp.com">tender+d46b4e4f26@tenderapp.com</a> wrote:</p>
<p>#yiv7644084581 pre {width:92%;margin:10px 2%;padding:5px 2%;background:#efefef;border:1px solid #d6d6d6;}#yiv7644084581 blockquote {margin-left:0;padding-left:1em;border-left:5px solid #ccc;}<br>
|</p></div>r_stonehousetag:support.flying-sphinx.com,2011-01-05:Discussion/195909082021-06-09T08:42:04Z2021-06-09T21:27:44ZManticore Search<div><p>Thanks for the quick response!</p></div>Dadetag:support.flying-sphinx.com,2011-01-05:Discussion/194201822020-10-20T22:08:18Z2021-03-13T07:28:10ZAre our wordform and stopword files being used?<div><p>Great to hear it’s working! :)</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/193727682020-09-14T21:19:00Z2020-09-16T04:49:58ZMissing data<div><p>Great to know everything’s up-to-date.</p>
<p>I’m still not sure of the original cause. If you spot any other issues, do let me know!</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/192659672020-05-12T16:47:42Z2020-05-21T12:55:35ZStrange behavior when deleting new records<div><p>Some further thoughts about all of this…</p>
<ul>
<li>I've set up a test app locally with deltas and merging, and thus far, haven't been able to reproduce the issue.</li>
<li>Merges should indeed keep the delta indices small - after each merge, any delta records have their flag set to false, so the next time a record is edited/added, the index will contain only that record (and then further changes until the next merge).</li>
<li>Generally I opt for real-time indices these days instead of SQL-backed indices - this also removes the need for deltas. Is there a reason you've chosen SQL-backed indices? (It's certainly a valid approach in some cases, but I figure it's worth me asking why)</li>
<li>You've mentioned you're using <code>destroy</code> calls when deleting objects - just to confirm, this is <code>destroy</code> on a single record, thus the ActiveRecord callback lifecycle is invoked? (Though, now I think <code>destroy</code> on a relation will still instantiate all of those objects and call <code>destroy</code> on each and invoke callbacks, so maybe it's fine either way)</li>
</ul></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/192324652020-03-30T21:19:05Z2020-05-12T16:33:03ZLemmatize pathing issues?<div><p>Thanks much Pat, it looks to be working for me now! I have another question, but will open a new discussion for it.</p></div>Dave Fawcetttag:support.flying-sphinx.com,2011-01-05:Discussion/192331962020-03-31T17:26:56Z2020-04-24T13:18:06ZUse flying sphinx for heroku ci<div><p>Glad to know you got the suite working, but it's a shame real-time indices didn't work out. Certainly, feel free to ask further questions about that here (perhaps in a new thread) or via Thinking Sphinx's GitHub issues.</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/192171582020-03-10T18:57:25Z2020-03-15T06:11:33ZHow to dynamically manage wordform contents?<div><p>Hi David,</p>
<p>This is indeed technically possible - you can interact with Sphinx and the Flying Sphinx API within code, so I'm happy to talk through how this is possible, if you let me know which language your app is using.</p>
<p>However, it's worth noting - at least with Thinking Sphinx and Ruby - that normal rebuilding calls will overwrite the existing configuration each time. So, you'd need to ensure that the index configuration for your app sources the wordforms dynamically in the same manner that any later submissions of new wordforms would use.</p>
<p>Happy to dive a bit deeper with this, but if you could let me know what library/language you're using so I can provide more directly relevant suggestions, that'd be great :)</p>
<p>Cheers,</p>
<p>Pat</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/191036962019-11-06T14:25:31Z2019-11-07T02:00:07ZCan't View Logs<div><p>Thanks for pointing this out Sean - seems I didn't test an assets upgrade yesterday nearly as well as I'd hoped (and was using some <em>old</em> syntax?). All fixed now!</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/190312242019-09-17T22:17:24Z2019-09-23T15:25:32ZFlying Sphinx is Down<div><p>Hi Sean,</p>
<p>The primary server disappeared for some reason (just starting to investigate that now, not sure whether it's my problem or AWS's), but as soon as I got the downtime alert I switched over to the failover server. Sorry about the downtime!</p>
<p>Regards,</p>
<p>Pat</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/189681622019-07-24T11:36:24Z2019-07-25T07:19:10ZThinkingSphinx connection error<div><p>No worries :)</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/189400822019-06-26T19:12:48Z2019-07-15T14:45:41ZFailure to start: No such file or directory; NOT SERVING<div><p>No worries at all, great to have everything upgraded and working faster and with lower disk usage. If there's any other queries or issues, do let me know. (Though right now it's approaching 1am here in Melbourne, so I'll likely be asleep for any immediate questions!)</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/185812612018-10-17T08:56:01Z2018-10-17T21:36:36ZError after upgrading sphinx plan<div><p>Closing this issue, will continue the Cyrillic discussions in the other thread :)<br>
<a href="http://support.flying-sphinx.com/discussions/problems/40736-cyrillic-symbols-in-search">http://support.flying-sphinx.com/discussions/problems/40736-cyrilli...</a></p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/185820422018-10-17T15:05:32Z2018-10-17T21:35:24Zcyrillic symbols in search<div><p>Indexed characters are managed through the <code>charset_table</code> and (prior to Sphinx 2.2) <code>charset_type</code>. Here is Sphinx's documentation for v2.1.8 (which I believe you are using):<br>
<a href="http://sphinxsearch.com/docs/archives/2.1.8/conf-charset-type.html">http://sphinxsearch.com/docs/archives/2.1.8/conf-charset-type.html</a><br>
<a href="http://sphinxsearch.com/docs/archives/2.1.8/conf-charset-table.html">http://sphinxsearch.com/docs/archives/2.1.8/conf-charset-table.html</a></p>
<p>In Thinking Sphinx, these settings are managed in a per-environment manner within <code>config/thinking_sphinx.yml</code> - similar to <code>config/database.yml</code>. The default settings should actually work fine with Cyrillic characters, but I think the issue here is that Thinking Sphinx now expects Sphinx v2.2.x by default (which uses UTF-8 automatically and has deprecated <code>charset-type</code>). To explicitly set that, add the following to your <code>config/thinking_sphinx.yml</code> file:</p>
<pre>
<code>production:
charset_type: "utf-8"</code>
</pre>
<p>I would recommend using Sphinx 2.2.11 instead, though - and this is also managed in <code>config/thinking_sphinx.yml</code>:</p>
<pre>
<code>production:
version: 2.2.11</code>
</pre>
<p>Once you've made either of these changes, you'll want to run <code>rake ts:rebuild</code> to ensure the data is re-indexed accordingly.</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/185521552018-10-03T01:50:26Z2018-10-19T03:09:31ZUrgent issue with Flying sphinx<div><p>Hey,</p>
<p>We've got a ton of ThinkingSphinx::SphinxError - Lost connection to MySQL server at 'reading initial communication packet', system error: 0 exceptions.</p>
<p>Downgrading the plan worked but we need more than 500mb...please help. Customers are currently unable to buy from us.</p>
<p>Cheers<br>
Dito</p></div>Ditotag:support.flying-sphinx.com,2011-01-05:Discussion/185363392018-09-25T07:10:58Z2018-10-01T21:15:16ZSearch returns no results for specific key word<div><p>Does the simplest version of that (<code>Material.search "Camel"</code>) not work for you? I'm seeing the record in Sphinx, so I'm rather surprised if it doesn't get returned!</p>
<p>I am presuming it's the app named <code>fllcasts</code> - is this correct?</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/184790952018-08-27T09:03:26Z2018-08-27T13:17:28Zdelete_all is failing with v1.2.0<div><p>Wow, thanks for the heads up!<br>
Really glad I asked :)</p></div>miikatag:support.flying-sphinx.com,2011-01-05:Discussion/184672412018-08-20T21:20:14Z2024-03-08T22:03:13ZThinkingSphinx::SphinxError: Lost connection to MySQL server at 'reading authorization packet'<div><p>Hi Pat,</p>
<p>Exceptions have ceased for now. I'll let you know if it occurs again.</p>
<p>Cheers<br>
Dit</p></div>Ditotag:support.flying-sphinx.com,2011-01-05:Discussion/182696172018-06-08T13:26:49Z2018-06-09T06:03:18ZFlying Sphinx 2 in development environment<div><p>And just published the gem release that includes this fix: v2.1.2.</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/181571362018-04-24T21:14:12Z2018-04-26T04:12:11ZCannot get FS working<div><p>Ah, that was due to a fix I made yesterday - I’d noticed the errors, glad the information’s now getting through and the logs are useful :)</p>
<p>Do get in touch if anything else isn’t working as expected!</p>
<p>Cheers,</p>
<p>— Pat</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/181521532018-04-23T06:19:51Z2018-04-23T12:00:21Zts:index gives ArgumentError: wrong number of arguments (given 1, expected 0)<div><p>Thanks so much for not only reporting this bug, but fixing it! Great to know your patch is working well for you now 👍</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/181428642018-04-18T19:26:47Z2022-05-03T20:46:51ZSearch/filter by attribute of associated objects<div><p>Ah, yes you're right, what I've suggested will still match names from non-special organisations. Needing that behaviour does change things…</p>
<p>I feel there are two options here. The first is, as you initially suggested, have two indices, and your <code>where</code> clause was spot on. Sharing the rest of the index details across definitions is tricky… you <em>could</em> have a helper class that applies fields and attributes?</p>
<pre>
<code>class IndexDefiner < BasicObject
def self.call(source)
new(source).call
end
def initialize(source)
@source = source
end
def call
# Here goes the common index contents
indexes [firstname, lastname], as: :name, sortable: true
indexes organizations.name, as: :organization_name, sortable: true
end
private
def method_missing(name, *arguments, &block)
@source.__send__ name, *arguments, &block
end
end
# and in the index definitions
ThinkingSphinx::Index.define :person, with: :active_record do
IndexDefiner.call self
end
ThinkingSphinx::Index.define :person, name: :person_with_special_org, with: :active_record do
where 'organizations.special = TRUE'
IndexDefiner.call self
end</code>
</pre>
<p>And then use the <code>:indices => ["person_with_special_org_core"]</code> option in your searches.</p>
<p>A different way is to instead define an index on the joining class, which will only have one organisation rather than many:</p>
<pre>
<code>ThinkingSphinx::Index.define :person_organization, :with => :active_record do
indexes [person.firstname, person.lastname], as: :name, sortable: true
indexes organization.name, as: :organization_name, sortable: true
has organization.special, :as => :special
end</code>
</pre>
<p>And then you can search on that model, loading each person through that:</p>
<pre>
<code>PersonOrganization.search "foo", :with => {:special => true}, :sql => {:include => :person}</code>
</pre>
<p>As for which of these to use? I guess it depends on whether you want the duplicate indices (even with the slightly cleaner approach), or a single model to search on - and whether the full situation you're dealing with works in either setup?</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/180728322018-03-20T11:55:00Z2022-05-03T20:47:16ZTwo searches in one roundtrip?<div><p>Mostly it's not documented, and it's rarely requested, so it would have taken quite some googling!</p>
<p>Though I've realised it's not in the documentation at all - and I've been working on that for the upcoming v4 release, so I'll make sure it gets added shortly.</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/180572102018-03-13T13:12:28Z2018-03-14T10:05:14ZDeletion of Data!<div><p>Greatly appreciate your feedback Hassan, thank you :) And it's great to know you’ve found a solution that fits your needs a bit more elegantly than Sphinx!</p>
<p>Cheers,</p>
<p>— Pat</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/180307732018-03-02T15:19:22Z2018-03-11T00:19:00ZIndexing failing<div><p>I've spent some time over the past day trying to figure out that integer-out-of-range issue, and not having much luck. The date values are indeed fine, and I don't see anything obvious about how the other attribute values could cause such a problem (all the integers are clearly less than what can be held within a 32-bit integer).</p>
<p>However, one thing that may help improve the processing speed for the Issue index: I realise you've got the languages association in Issue set up to go through tracker, but in the index it's better to be more explicit. The change:</p>
<pre>
<code>has languages(:id), :as => :language_ids
# becomes:
has tracker.languages.id, :as => :language_ids</code>
</pre>
<p>The reason for this is to ensure TS generates just <em>one</em> join to the trackers table (it's currently generating two). This may be fixed in later versions of TS (you're using quite an old version!), but this workaround will be more reliable.</p>
<p>Also, I've removed the symbol for :id - that was only needed for TS v2 and older (but the behaviour should remain the same, so it's not a big deal, and certainly not related to the problems at hand).</p></div>Pat Allantag:support.flying-sphinx.com,2011-01-05:Discussion/179789372018-02-09T10:26:23Z2018-02-12T06:02:02Zheroku run rake fs:index is not working <div><p>Hi Ghulam,</p>
<p>I’m not sure what’s happening with the <code>fs:regenerate</code> call - does <code>ts: regenerate</code>/<code>ts:rebuild</code> work fine locally?</p>
<p>And you don’t need to worry about those configuration settings - Flying Sphinx sets those automatically.</p>
<p>— Pat</p></div>Pat Allan