If it's critical data, then it's critical data, and I think that overrides any indexing speed decreases (and I've no idea how much slower it would become normally, but it'll be massively faster than if you don't use it with fixtured data).
-- Pat On 17/06/2009, at 5:03 PM, Nalin Mittal wrote: > > What are the cons of using a large sql_range_step? Is it a bad idea to > do this in production? > I have records in my prod database that stemmed from fixtures but are > critical at this point. It would be a huge pain to update the ids and > not break any of the associations. > > Would love to hear your thoughts. > > On Apr 20, 6:55 am, Pat Allan <[email protected]> wrote: >> An alternative method is to specify your ids explicitly (yes, I >> realise this is more work). >> >> Personally, I steer clear of fixtures, and use Pete Yandell's >> Machinist.http://github.com/notahat/machinist/tree/master >> >> Good to know you figured it all out though :) >> >> -- >> Pat >> >> On 16/04/2009, at 4:59 AM, matt wrote: >> >> >> >>> Adding a large value for the option 'sql_range_step' to sphinx.yml >>> did >>> the trick, e.g. >> >>> config/sphinx.yml : >> >>> development: >>> address: localhost >>> port: 3312 >>> mem_limit: 64M >>> sql_range_step: 1000000000 >> >>> test: >>> address: localhost >>> port: 3313 >>> mem_limit: 64M >>> sql_range_step: 1000000000 >> >> > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
