Lighthouse has a new layout. Prefer the old one? Return to the old layout, and switch back any time from the link at the top of each page.

[PATCH] fixture_scenarios_with_scenario_builder fixes

#58

There are a few issues with fixture_scenarios_with_scenario_builder:

1. nested scenarios built in ruby can contain conflicting yaml labels

2. yaml files begin with ---, so when multiple are concat together everything after the second --- is ignored by yaml

3. if we workaround the --- issue by manually removing them, there is a second issue: (assuming we havent been bitten by #1 Add get_multi to cache_fu and all yaml labels are uniq) the yaml gets loaded into a hash, which is not ok for preserving order. this would make nesting suspect at best.

4. it was my experience that you can not modify an existing record in a nested scenario, only add new records (Mysql::Error: Duplicate entry exception)

Here are my additions:

1. Make inferred_record_name fallback much more unique, with a preference for primary_key if using the default "id", otherwise the sequence number

2. Load yaml fixtures into the database on a per file basis instead of concating everything and doing one pass. This preserves order of nesting and name scoping issues.

2a. #load_fixtures_from_yaml abstracts the fixture loading part

3. Added #insert_fixtures override which now will attempt to remove a record and retry if it gets an exception while inserting. limited to 1 retry, otherwise reraises the error

Please contact me to discuss if there are any questions.

Pastie patch:

http://pastie.caboo.se/77262

Also, thanks for this branch of the fixture_scenarios plugin. Nesting is what I was looking for when I found it!

Reported by Joe Noon · August 11th, 2007 @ 10:24 PM

State: hold
Milestone: none
Assigned to: Chris Wanstrath Chris Wanstrath

Activity

  1. Joe Noon
    Joe Noon

    Updated PATCH:

    http://pastie.caboo.se/77416

    I may just start my own branch from here since it seems like I am changing some core decisions in the code. Please let me know if you think this would be best.

    August 11th, 2007 @ 10:24 PM

  2. Chris Wanstrath
    Chris Wanstrath
    • State changed from new to open

    I don't get why we need to duplicate information.

    Is the reason because if you've fixtures/users/users.yml and fixtures/users/unauthorized/users.yml, only one of those two files will be loaded?

    Having to destroy records you don't want in a nested scenario seems weird. Is this what you're currently doing?

    August 11th, 2007 @ 10:24 PM

  3. Chris Wanstrath
    Chris Wanstrath
    • State changed from open to hold

    August 11th, 2007 @ 10:24 PM

  4. Chris Wanstrath
    Chris Wanstrath

    For the record, I refactored this into a fixture_scenarios add-on rather than forking the plugin proper.

    http://plugins.require.errtheblo...

    August 11th, 2007 @ 10:24 PM

  5. Dougal Sutherland
    Dougal Sutherland

    I discovered the fixture_scenarios_builder plugin earlier today, and in a fit of ecstasy converted all my old-school fixtures to a scenario.rb file. But I ran into issues with nesting: namely, I can't (cleanly) have my child scenarios refer to data in parents, to set up model relationships and such. And then I discovered this ticket, and apparently there's an add-on that solves exactly that problem. Awesome.

    Unfortunately, I can't seem to find it in svn. Am I just stupid?

    And I get lots of problems trying to apply Joe's patch. Files aren't named the same as when he made it, and after I fixed all those I got an error about a hunk ending suddenly: I'll try to get it working later, but if there's an add-on somewhere, that would be so much more convenient.

    August 11th, 2007 @ 10:24 PM

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.