Does RSpec work nicely with UUID primary keys?

I have my application happily generating UUID primary keys using the
uuidtools gem.

But the auto-generated specifications created by “script/generate
rspec_scaffold…”, etc, assume that one is using a sequential integer
primary key.

For those who have hit this same issue, is it just a matter of rewriting
the auto-generated specifications to take this into account, or does one
have to dig into the code of rspec because this assumptions is hardwired
in?

Thanks in advance.

On Jul 5, 2008, at 9:03 AM, John K. wrote:

one
have to dig into the code of rspec because this assumptions is
hardwired
in?

What happens when you run the generated examples?

On Sat, Jul 5, 2008 at 10:03 AM, John K. [email protected] wrote:

But the auto-generated specifications created by “script/generate
rspec_scaffold…”, etc, assume that one is using a sequential integer
primary key.

That’s just the fixtures in spec/fixtures. They’re using the old
fixture style, where all the IDs are hardcoded. You can modify the
fixtures easily enough simply by removing the ID field from each of
them; if you’re using Rails 2.0 or higher, read up on the “foxy
fixtures” behavior where it handles ID generation and associations in
a much smarter way.

Better yet, for more flexibility, get rid of the fixtures entirely and
create your test data using some sort of factory method. If you’re
doing something fundamentally different with your data like UUID
primary keys, you might have to do this. The Peepcode screencasts
about RSpec show easy examples of how to define create_foo() methods
in your specs. Or you could use one of the various fixture
replacement plugins/gems:

Fixture Replacement 2:
http://replacefixtures.rubyforge.org/
(This is the one I use. I love it.)

Factory Girl:
http://giantrobots.thoughtbot.com/2008/6/6/waiting-for-a-factory-girl

can_has_fixtures:
http://github.com/benburkert/can_has_fixtures/tree/master

If you use any of these, you will of course end up having to change
the autogenerated specs in spec/models. But for models at least, the
RSpec generator puts virtually nothing in, so that only means changing
one or two lines of code each time. I don’t consider that much of a
burden.


Have Fun,
Steve E.
Deep Salt Team

David C. wrote:

What happens when you run the generated examples?

My code uses single table inheritance (STI) and a MySQL database, so I
thought it best to create some new simple projects with a single model.

(1) I created a new project using SQLite with a single model. All 58
auto-generated specifications ran successfully.

(2) I created a new single-model project using SQLite but added a UUID
primary key. All 58 auto-generated specifications ran successfully.

(3) I created a new project using MySQL with a single model. Again, all
58 auto-generated specifications ran successfully.

(4) (2) I created a new single-model project using MySQL but added a
UUID primary key. All 58 auto-generated specifications ran
successfully.

Hmm. So, it’s not the UUIDs that are causing problems with my
application… but perhaps single table inheritance. Will do more tests
and post again when I’ve better defined the problem.

Sorry for the confusion, Dave, but perhaps this will help somebody else
searching the list.

And Steve, will look into your suggestions for fixtures. Thanks very
much.

Jarkko L. wrote:

If you add some new code (without writing new specs for it),
even in the form of using plugins, and your existing specs still run,
it doesn’t mean your code is working correctly because you didn’t
write specs for that part of the functionality yet.

That makes a lot of sense, and a useful gotcha to keep in mind. Since
I’m just in the very early stages of my project, it makes sense for me
start-over, get my specs working from the beginning, and ensure that
they still pass after introducing inheritance through the addition of a
parent class.

Very impressed with the quality of replies on this list. : )

On 5.7.2008, at 18.37, John K. wrote:

(2) I created a new single-model project using SQLite but added a UUID
Hmm. So, it’s not the UUIDs that are causing problems with my
application… but perhaps single table inheritance. Will do more
tests
and post again when I’ve better defined the problem.

The thing is, the scaffolding specs are specs for the behaviour of the
scaffolded controllers/models/views. If you want to change that
behaviour, your specs should reflect that assumption. If you add some
new code (without writing new specs for it), even in the form of using
plugins, and your existing specs still run, it doesn’t mean your code
is working correctly because you didn’t write specs for that part of
the functionality yet. Using UUID probably changes things so little
that (especially if/when they mock the models) it won’t trip the
scaffolding specs per se.

//jarkko


Jarkko L.
http://jlaine.net
http://dotherightthing.com
http://www.railsecommerce.com
http://odesign.fi

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs