#58 ✓hold
Joe Noon

[PATCH] fixture_scenarios_with_scenario_builder fixes

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

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 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!

Comments and changes to this ticket

  • Joe Noon

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

    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.

  • Chris Wanstrath

    Chris Wanstrath August 11th, 2007 @ 10:24 PM

    • 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?

  • Chris Wanstrath

    Chris Wanstrath August 11th, 2007 @ 10:24 PM

    • State changed from “open” to “hold”
  • Chris Wanstrath

    Chris Wanstrath August 11th, 2007 @ 10:24 PM

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

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

  • Dougal Sutherland

    Dougal Sutherland August 11th, 2007 @ 10:24 PM

    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.

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.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Shared Ticket Bins

People watching this ticket

Pages