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