Thanks again. I'll be looking at Factories after this app is deployed.
I also need to work out how to properly stub/mock Paperclip and AWS S3
(among other external dependencies). I read the first FactoryGirl
release post by the thoughtbot guys, it does look a lot easier.
Properly designing a spec - especially in relation to user permissions
- is something that's still a mystery to me, but the FactoryGirl
examples seem to be clearing things up.
On Oct 5, 4:45 pm, DrMark <[EMAIL PROTECTED]> wrote:
> Aloha Neil,
>
> Comments inline below.
>
> DrMark
>
> On Oct 3, 7:00 am, Neil <[EMAIL PROTECTED]> wrote:
>
> > Thanks DrMark.
>
> snip
>
> > I'm hoping to move away from fixtures at some point. Until then,
> > wouldn't manually setting IDs for fixtures work?
>
> Absolutely. This is the way fixtures worked before foxy fixtures were
> introduced. If you use an id in your fixture, that number is used
> instead of the auto generated foxy fixture id.
>
> > Why doesn't foxy
> > fixtures assign IDs starting from 0 (potentially reducing the
> > sql_query_range max to something less than the 1058960291 I have in my
> > Users table)?
>
> Foxy fixtures create the id of the object based on a hash of the
> object's name. This allows you to always calculate the id of an object
> given its name. It is a great idea, but doesn't work well with
> Sphinx.
>
> To be honest, we don't use fixtures any more for our tests. Once you
> begin to use fixtures for a while, you realize that maintaining them
> is a hassle. Each time you update your model, you must update all of
> your fixtures. However, there is a solution. We use factories. A
> factory allows you to create a valid object any time that you need
> one. You can also customize the new objects by passing attributes when
> you create it. When you update your model, you simply update the
> factory with the corresponding changes. You then don't have to worry
> about your tests failing due to incorrect fixture data.
>
> We are using FactoryGirl and I am very happy with it.
>
> Best of luck :)
>
>
>
> > On Oct 3, 5:19 pm, DrMark <[EMAIL PROTECTED]> wrote:
>
> > > Neil,
>
> > > Make certain that you understand the implications of putting
>
> > > 'sql_range_step: 100000000'
>
> > > in your code. This will run fine in the beginning when you only have a
> > > few records. However, when your indexed tables become large, this is a
> > > big-time fail. Basically, you are telling sphinx to load 100 million
> > > records at a time when doing an index. This will, of course,
> > > completely mangle any hope of indexing your tables and will eat huge
> > > amounts of RAM on any decent sized table. The default setting of 5000
> > > rows at a time could even be too large depending upon the data in your
> > > tables.
>
> > > The real problem here are your foxy fixtures. I will reiterate this
> > > for future folks. You should NOT use Sphinx with foxy fixtures. The
> > > only solution to the sparse id problem created by foxy fixtures is the
> > > sql_range_step idea above, which is a terrible idea in a real
> > > production environment.
>
> > > Best of luck,
>
> > > DrMark
>
> > > On Oct 2, 10:43 pm, Neil <[EMAIL PROTECTED]> wrote:
>
> > > > Thanks again, Pat. I think we're nearly there. TS still seems to be
> > > > removing the sql_range_step, even if I use 'rake thinking_sphinx:index
> > > > INDEX_ONLY=true', Does this look right to you?
>
> > > > source comment_0_core
> > > > {
> > > > type = mysql
> > > > sql_host = localhost
> > > > sql_user = root
> > > > sql_pass = my password
> > > > sql_db = my_database
>
> > > > sql_query_pre = SET NAMES utf8
>
> > > > sql_query_pre =
> > > > sql_query = SELECT `comments`.`id` * 14 + 0 AS `id` ,
> > > > CAST(`comments`.`body` AS CHAR) AS `body`, CAST(`news_items`.`title`
> > > > AS CHAR) AS `comment_news_item_title`, CAST(`newsfeeds`.`name` AS
> > > > CHAR) AS `comment_newsfeed_name`, CAST(`users`.`name` AS CHAR) AS
> > > > `comment_user_name`, UNIX_TIMESTAMP(`comments`.`created_at`) AS
> > > > `created_at`, `comments`.`is_private` AS `is_private`, `comments`.`id`
> > > > AS `sphinx_internal_id`, 1539927024 AS `class_crc`, '1539927024' AS
> > > > `subclass_crcs`, 0 AS `sphinx_deleted` FROM comments LEFT OUTER
> > > > JOIN `news_items` ON `news_items`.id = `comments`.news_item_id LEFT
> > > > OUTER JOIN `newsfeeds` ON `newsfeeds`.id = `comments`.newsfeed_id
> > > > LEFT OUTER JOIN `users` ON `users`.id = `comments`.user_id WHERE
> > > > `comments`.`id` >= $start AND `comments`.`id` <= $end GROUP BY
> > > > `comments`.`id` ORDER BY NULL
> > > > sql_query_range = SELECT MIN(`id`), MAX(`id`) FROM `comments`
> > > > sql_range_step = 100000000
> > > > sql_query_info = SELECT * FROM `comments` WHERE `id` = (($id - 0) /
> > > > 14)
> > > > sql_attr_timestamp = created_at
> > > > sql_attr_bool = is_private
> > > > sql_attr_uint = sphinx_internal_id
> > > > sql_attr_uint = class_crc
> > > > sql_attr_multi = uint subclass_crcs from field
> > > > sql_attr_uint = sphinx_deleted
>
> > > > }
>
> > > > I would love to make a patch but I only started with programming back
> > > > in March, so unless someone guides me I'll probably make a mess. I'll
> > > > give it a go if there's little chance of me wasting your time with a
> > > > messy commit request. Also, did the foxy fixtures patch look ok? I was
> > > > considering putting it in an initializer because the app doesn't use
> > > > text unit (so it could easily be forgotten about) and it would be good
> > > > to make it applicable to the fixtures loaded in to the development
> > > > database (or is this already happening?).
>
> > > > Cheers
>
> > > > On Oct 3, 4:39 am, Pat Allan <[EMAIL PROTECTED]> wrote:
>
> > > > > You'll need to put sql_range_step into your development.sphinx.conf
> > > > > file, correct, inside the relevant sources.
>
> > > > > It's getting overwritten because that's what thinking_sphinx:index
> > > > > does, by default. If you use rake thinking_sphinx:index
> > > > > INDEX_ONLY=true, then it'll be fine, until you next change your index
> > > > >
> > > > > structures in your models, and want to regenerate the configuration
> > > > > file.
>
> > > > > I do want to support sql_range_step, on a per-index basis (ie: using
> > > > > set_property), but haven't done so yet. Patches welcome :)
>
> > > > > Sorry for the hack solution
>
> > > > > --
> > > > > Pat
>
> > > > > On 03/10/2008, at 4:35 AM, Neil wrote:
>
> > > > > > Right, I'm still seeing these DOCID MAX, but at least the engine
> > > > > > yard
> > > > > > guys are going to take care of the crontab and sphinx setup.
>
> > > > > > Because I'm using Rspec, I'm not sure whether I can use the test
> > > > > > helper to override the Fixture class methods, (I actually have an
> > > > > > empty test folder anyway, excluding the new test_helper), either
> > > > > > way,
> > > > > > this is what I now have in the test helper;
>
> > > > > >http://pastie.org/283913
>
> > > > > > Is that the correct implementation?
>
> > > > > > Also, I have absolutely no idea where I put this 'sql_range_step:
> > > > > > 100000000'. Presumably it's the development.sphinx.conf, right? If
> > > > > > so,
> > > > > > between which braces do I put it? I've tried all sorts but Sphinx
> > > > > > seems to strip it out no matter where I put it (indexer, searchd,
> > > > > > source 'some source' etc). I did some reading up via Google and the
> > > > > > Insoshi guys seemed to have different options when it comes to the
> > > > > > Ultrasphinx config file, so I couldn't work it out from there,
> > > > > > either
> > > > > > - even though they do explain the problem with foxy fixtures. Any
> > > > > > ideas?
>
> > > > > > Thanks
>
> > > > > > On Oct 1, 3:49 pm, Neil <[EMAIL PROTECTED]> wrote:
> > > > > >> Morten, I'm using Rspec. By the sounds of it, I could do something
> > > > > >> similar in my /spec/spec_helper.rb (?);
>
> > > > > >> class Fixtures
> > > > > >> # Sparse ids generated by foxy fixtures cause unrealistic scaling
> > > > > >> problems with Sphinx:http://dev.rubyonrails.org/ticket/11339
> > > > > >> def self.identify(label)
> > > > > >> label.to_s.hash.abs % 10000 + 1
> > > > > >> end
> > > > > >> end
>
> > > > > >> This is the spec_helper.rb;
>
> > > > > >>http://pastie.org/282852
>
> > > > > >> And I'm loading the fixtures using a 'prime' rake task;
>
> > > > > >>http://pastie.org/282856
>
> > > > > >> Jeremy, that sounds great. I'm speaking with the account manager
> > > > > >> tomorrow. If they do can the cron for me, that's one less thing to
> > > > > >> worry about. I had to save on a staging slice intially, so I'm
> > > > > >> configuring an Express slice on my mbp. I'm struggling a little
> > > > > >> but
> > > > > >> at
> > > > > >> least I'm learning a little about what the EY guys will be doing
> > > > > >> (whilst having their support available).
>
> > > > > >> Cheers
>
> > > > > >> On Sep 30, 9:37 pm, Morten <[EMAIL PROTECTED]> wrote:
>
> > > > > >>> Neil,
>
> > > > > >>> I have this in our test/test_helper.rb:
>
> > > > > >>>http://pastie.org/282397
>
> > > > > >>> Br,
>
> > > > > >>> Morten
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
