Hi Emil

Just added something to Thinking Sphinx so it doesn't try to talk to  
Sphinx if it isn't running when a model is destroyed.
Thanks for your patience with this.

Cheers

-- 
Pat

On 19/10/2008, at 9:05 PM, Pat Allan wrote:

>
> Hi Emil
>
> You raise a fair point about problems for model changes while Sphinx
> is being restarted... I don't have a neat solution for that yet -
> although I guess the system could check for the existance of the pid
> file, perhaps? And not try to update to Sphinx if that doesn't
> exist... Hmm. I'll see what I can do.
>
> Cheers
>
> -- 
> Pat
>
> On 19/10/2008, at 7:04 PM, Emil Tin wrote:
>
>>
>> during restart of the sphinx daemon i will have to take the site
>> offline to avoid potential problems in case destroying a models fail
>> because the deamon can't be contacted.
>>
>>
>> what would happpen if the delete flag is not set when a model is
>> destroyed? would a later search then cause errors, or simply return
>> empty records that could be filtered out?
>>
>> what would happen if the delta index is not updated when a model is
>> changed? nothing except search results would be a bit out of date,
>> right? as soon as the db is reindexed, things would be fine again?
>>
>> i'm considering patching my copy of ts so i would get get warnings
>> (perhaps by email) instead of exceptions if the search daemon can't  
>> be
>> reached when deleting/changing models.
>>
>>
>>
>>
>> On Oct 18, 4:41 pm, Pat Allan <[EMAIL PROTECTED]> wrote:
>>> That's correct - any change of structure (as opposed to data)
>>> requires
>>> Sphinx to be restarted.
>>>
>>> --
>>> Pat
>>>
>>> On 17/10/2008, at 12:51 AM,EmilTin wrote:
>>>
>>>
>>>
>>>> hi pat,
>>>> thanks you for reply.
>>>> i trust that the daemon is very stable, but as far as i understood
>>>> it,
>>>> whenever i change the define_index'es i have to stop, reconfigure,
>>>> reindex and restart sphinx?
>>>
>>>> On Oct 16, 6:13 am, Pat Allan <[EMAIL PROTECTED]> wrote:
>>>>> HiEmil
>>>
>>>>> Thinking Sphinx doesn't just talk to Sphinx to get deltas indexed.
>>>>> For
>>>>> example, when a model instance is destroyed, the following things
>>>>> happen:
>>>
>>>>> - Check if the instance exists in the core index
>>>>> - Flags it as deleted in the core index if it does
>>>>> - If deltas are enabled and the instance had delta set to true,
>>>>> flag
>>>>> it as deleted in the delta index
>>>
>>>>> The first two steps happen every time, whether you're using delta
>>>>> indexes or not. This is to make sure those deleted records don't
>>>>> get
>>>>> returned in search queries.
>>>
>>>>> And ideally, the Sphinx daemon should be running constantly. From
>>>>> what
>>>>> I've found (and heard from others), the daemon is very stable, and
>>>>> rarely crashes. And when it does, that's where process tracking
>>>>> tools
>>>>> like God and Monit can be useful.
>>>
>>>>> Hope this clears things up a bit.
>>>
>>>>> --
>>>>> Pat
>>>>> e: [EMAIL PROTECTED]    || m: +614 1327 3337
>>>>> w:http://freelancing-gods.com|| t: twitter.com/pat
>>>>> discworld:http://ausdwcon.org|| skype: patallan
>>>
>>>>> On 15/10/2008, at 11:27 PM,EmilTin wrote:
>>>
>>>>>> thanks for you reply.
>>>
>>>>>> i now have sphinx running on a separate ec2 instance, and rails
>>>>>> accessing it. the key was to edit the production.config.sphinx
>>>>>> file in
>>>>>> the rails config folder on the sphinx server (i deploy the rail
>>>>>> app
>>>>>> folder, but don't run the app) to 0.0.0.0 isntead of the default
>>>>>> 127.0.0.0, to make sure it listens to all interfaces, not just  
>>>>>> the
>>>>>> local one.
>>>
>>>>>> destroy an indexed model will still causes an exception if the
>>>>>> sphinx
>>>>>> server can't be reached. that's really bad, since it could mean
>>>>>> otherwise perfect cod breaks down in case th sphinx server is
>>>>>> down.
>>>>>> it's suddently making my rails app very fragile. and there's no
>>>>>> need
>>>>>> to! delta indexing is off! in any case it would be better to just
>>>>>> silently ignore the error, so problems are not multiplied. it's
>>>>>> much
>>>>>> worse to have a destroy() call fail than failing to update a non-
>>>>>> existing delta search index.
>>>
>>>>>> On Oct 15, 10:06 am, Pat Allan <[EMAIL PROTECTED]> wrote:
>>>>>>> HiEmil
>>>
>>>>>>> Sorry there's not been a reply to this, but I think the short
>>>>>>> answer
>>>>>>> is: no, there's no easy way to do this. You could overwrite some
>>>>>>> methods or something like that, but it's definitely a hackish
>>>>>>> solution, and would be best just to focus on getting the
>>>>>>> environment
>>>>>>> working correctly so this is no longer an issue.
>>>
>>>>>>> Sorry, I realise that's not really all that helpful. And I've
>>>>>>> never
>>>>>>> tried EC2, let alone getting Sphinx running on it.
>>>
>>>>>>> --
>>>>>>> Pat
>>>
>>>>>>> On 08/10/2008, at 4:59 PM,EmilTin wrote:
>>>
>>>>>>>> The problem is this: whenever the sphinx server is down, not
>>>>>>>> only
>>>>>>>> the
>>>>>>>> search page stops working. Every page that tries to delete a
>>>>>>>> model
>>>>>>>> will fail. This is a problem while I'm trying to get the sphinx
>>>>>>>> server
>>>>>>>> up running. I still haven't managed to make TS contact the
>>>>>>>> sphinx
>>>>>>>> server running on a separate EC2 instance.
>>>
>>>>>>>> Is there anyway to stop TS from trying to change the
>>>>>>>> sphinx_deleted
>>>>>>>> attribute? (Even just temporarily?)
>>>
>>>>>>>> On Oct 7, 10:18 am, Pat Allan <[EMAIL PROTECTED]>  
>>>>>>>> wrote:
>>>>>>>>> HiEmil
>>>
>>>>>>>>> Sphinx can update _attributes_ in indexes (but not fields -
>>>>>>>>> hence
>>>>>>>>> why
>>>>>>>>> some people use delta indexes) - and there's an attribute,
>>>>>>>>> created by
>>>>>>>>> Thinking Sphinx, called sphinx_deleted. This gets set to true
>>>>>>>>> when a
>>>>>>>>> model is deleted, so it won't get returned in future results
>>>>>>>>> (otherwise pagination counts are inaccurate).
>>>
>>>>>>>>> Cheers
>>>
>>>>>>>>> --
>>>>>>>>> Pat
>>>
>>>>>>>>> On 06/10/2008, at 9:12 PM,EmilTin wrote:
>>>
>>>>>>>>>> Hi!
>>>
>>>>>>>>>> I'm gettting the error 'Connection to Sphinx Daemon (searchd)
>>>>>>>>>> failed'
>>>>>>>>>> whenever I try to delete any of my indexed models.
>>>
>>>>>>>>>> It's true that the sphinx server is not running. But delta
>>>>>>>>>> indexing is
>>>>>>>>>> not turned on, so why would TS try to connect to the sphinx
>>>>>>>>>> server
>>>>>>>>>> when destroying a model?
>>>
>>>>>>>>>> none of my models include :delta => true. They only contain
>>>>>>>>>> trivial
>>>>>>>>>> things like:
>>>
>>>>>>>>>> define_index do
>>>>>>>>>>  indexes :name
>>>>>>>>>>  indexes :description
>>>>>>>>>> end
>>>
>>>>>>>>>> trace:
>>>>>>>>>> vendor/plugins/thinking-sphinx/lib/thinking_sphinx/search.rb:
>>>>>>>>>> 231:in
>>>>>>>>>> `search_for_id'
>>>>>>>>>> vendor/plugins/thinking-sphinx/lib/thinking_sphinx/
>>>>>>>>>> active_record/
>>>>>>>>>> search.rb:43:in `search_for_id'
>>>>>>>>>> vendor/plugins/thinking-sphinx/lib/thinking_sphinx/
>>>>>>>>>> active_record.rb:
>>>>>>>>>> 121:in `in_core_index?'
>>>>>>>>>> vendor/plugins/thinking-sphinx/lib/thinking_sphinx/
>>>>>>>>>> active_record.rb:
>>>>>>>>>> 137:in `toggle_deleted'
>>>>>>>>>> vendor/rails/activesupport/lib/active_support/callbacks.rb:
>>>>>>>>>> 173:in
>>>>>>>>>> `send'
>>>>>>>>>> vendor/rails/activesupport/lib/active_support/callbacks.rb:
>>>>>>>>>> 173:in
>>>>>>>>>> `evaluate_method'
>>>>>>>>>> vendor/rails/activesupport/lib/active_support/callbacks.rb:
>>>>>>>>>> 161:in
>>>>>>>>>> `call'
>>>>>>>>>> vendor/rails/activesupport/lib/active_support/callbacks.rb:
>>>>>>>>>> 93:in
>>>>>>>>>> `run'
>>>>>>>>>> vendor/rails/activesupport/lib/active_support/callbacks.rb:
>>>>>>>>>> 92:in
>>>>>>>>>> `each'
>>>>>>>>>> vendor/rails/activesupport/lib/active_support/callbacks.rb:
>>>>>>>>>> 92:in
>>>>>>>>>> `send'
>>>>>>>>>> vendor/rails/activesupport/lib/active_support/callbacks.rb:
>>>>>>>>>> 92:in
>>>>>>>>>> `run'
>>>>>>>>>> vendor/rails/activesupport/lib/active_support/callbacks.rb:
>>>>>>>>>> 272:in
>>>>>>>>>> `run_callbacks'
>>>>>>>>>> vendor/rails/activerecord/lib/active_record/callbacks.rb:
>>>>>>>>>> 298:in
>>>>>>>>>> `callback'
>>>>>>>>>> vendor/rails/activerecord/lib/active_record/callbacks.rb:
>>>>>>>>>> 290:in
>>>>>>>>>> `destroy_without_transactions'
>>>>>>>>>> vendor/rails/activerecord/lib/active_record/transactions.rb:
>>>>>>>>>> 102:in
>>>>>>>>>> `destroy_without_after_commit_callback'
>>>>>>>>>> vendor/rails/activerecord/lib/active_record/
>>>>>>>>>> connection_adapters/
>>>>>>>>>> abstract/database_statements.rb:66:in `transaction'
>>>>>>>>>> vendor/rails/activerecord/lib/active_record/transactions.rb:
>>>>>>>>>> 79:in
>>>>>>>>>> `transaction'
>>>>>>>>>> vendor/rails/activerecord/lib/active_record/transactions.rb:
>>>>>>>>>> 98:in
>>>>>>>>>> `transaction'
>>>>>>>>>> vendor/rails/activerecord/lib/active_record/transactions.rb:
>>>>>>>>>> 102:in
>>>>>>>>>> `destroy_without_after_commit_callback'
>>>>>>>>>> vendor/plugins/thinking-sphinx/lib/thinking_sphinx/
>>>>>>>>>> active_record/
>>>>>>>>>> delta.rb:58:in `destroy'
>>>>>>>>>> app/controllers/bands_controller.rb:236:in `destroy'
>>>
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Thinking Sphinx" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/thinking-sphinx?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to