[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:
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 August 11th, 2007 @ 10:24 PM
Updated PATCH:
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 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 August 11th, 2007 @ 10:24 PM
- State changed from “open” to “hold”
-
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.
-
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.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
Dougal Sutherland