Forum: RSpec id getting overwritten with 0 when testing

My code that saves a record works fine in development or production, or 
from the console. I can take the code in my test and run it in the 
console, and it works fine.

But when I run it under a model rspec, the ids are getting set to 0. Ive 
traced it through to where I do:

<Model>.create <params>

where I can see that the id is what I want to set it to in params.

Same problem with rspec 2.6 and 2.8.

Dont make me switch to Test::Unit. Anyone?

It'd be nice to have a bit of context for this issue.

It's most likely an issue with your model's validation...

Julian

On Jan 24, 2012, at 11:27 PM, Julian Leviston wrote:

>> Same problem with rspec 2.6 and 2.8.
>>
>> Dont make me switch to Test::Unit. Anyone?
> It'd be nice to have a bit of context for this issue.
>
> It's most likely an issue with your model's validation

Not sure what else to tell you. Ive a complex bit of logic I want to 
exercise thats accepting a hierarchy of objects submitted to the 
application as JSON. The controller pulls it apart into a hierarchical 
key-value hash. Ive a recursive operation that walks this structure, 
pulling out individual objects and saving them.

Everything works fine when I test it manually (e.g. in console). When I 
run the same sequence of operations with the same values in console 
(i.e. I tested it by copying the values and operations out of the spec 
into the console), it all works fine.

But it all fails horribly in rspec because the ids are getting 
overwritten with 0s. I can get to the point in my code where I hand 
things over to ActiveRecord, and the hash Im giving to create is exactly 
what Im after including the id value.

FWIW, the ids Im trying to use are UUIDs.

Since Im entirely sure the hash Im handing to create is correct, Im left 
with trying to grub around inside ActiveRecord, which I dont look 
forward to. So: in what way does RSpec modify the behavior of 
ActiveRecord that might bear on this?

On Jan 25, 2012, at 12:43 AM, Guyren G Howe wrote:

>>>
>
> http://rubyforge.org/mailman/listinfo/rspec-users
http://ariejan.net/2008/08/12/ruby-on-rails-uuid-a...

Make sure the column is 16-byte binary

On Wed, 25 Jan 2012, Justin Ko wrote:

>
> 
http://ariejan.net/2008/08/12/ruby-on-rails-uuid-a...
>
> Make sure the column is 16-byte binary
>

And be sure to update your test database's schema so that it behaves the
same as your other environments:

rake db:test:clone_structure

Patrick J. Collins
http://collinatorstudios.com

On Jan 25, 2012, at 1:42 AM, Patrick J. Collins wrote:

>
> rake db:test:clone_structure

You actually want to use "rake db:test:prepare". It does the same thing 
as "clone_structure" but doesn't create the nasty structure.sql file.

http://stackoverflow.com/questions/7693365/whats-t...

See that's HEAPS better! More information.

Pffft ... not sure what else to tell us!

Okay so NOW to me it sounds a lot like you're using a non-integer as a 
primary key which I wouldn't do...

And also, could it not be a string coersion issue? (ie params coersion)

Julian

On Jan 25, 2012, at 3:44 AM, Julian Leviston wrote:

> Okay so NOW to me it sounds a lot like you're using a non-integer as a primary 
key which I wouldn't do...

I dont think youve tried to write a server app that synchronizes with 
handheld apps over an unreliable internet connection. UUIDs make things 
*so* much easier.

The decision about the pks is made. Am I understanding from folks here 
that rspec *wont work* without integer primary keys? That is a major 
design flaw, if true.

On Wed, Jan 25, 2012 at 3:29 PM, Guyren G Howe <gisborne@emailuser.net> 
wrote:
> On Jan 25, 2012, at 3:44 AM, Julian Leviston wrote:
>
>> Okay so NOW to me it sounds a lot like you're using a non-integer as a primary 
key which I wouldn't do...
>
> I dont think youve tried to write a server app that synchronizes with handheld 
apps over an unreliable internet connection. UUIDs make things *so* much easier.
>
> The decision about the pks is made. Am I understanding from folks here that 
rspec *wont work* without integer primary keys? That is a major design flaw, if 
true.

RSpec provides a thin wrapper around the testing framework that ships
with Rails and extends T/U. I'm not sure I understand the problem yet,
but I'd be really surprised if it's anything RSpec is doing or failing
to do.

What versions of RSpec and Rails are you using?

On Wed, Jan 25, 2012 at 3:37 PM, David Chelimsky <dchelimsky@gmail.com> 
wrote:
> with Rails and extends T/U. I'm not sure I understand the problem yet,
> but I'd be really surprised if it's anything RSpec is doing or failing
> to do.
>
> What versions of RSpec and Rails are you using?

Just looked back at your initial email and see you cited rspec-2.8,
but the way Rails handles incoming params in tests changed in either
3.1 or 3.2 (I have to check). Which rails version specifically?

On Jan 25, 2012, at 1:45 PM, David Chelimsky wrote:

> Just looked back at your initial email and see you cited rspec-2.8,
> but the way Rails handles incoming params in tests changed in either
> 3.1 or 3.2 (I have to check). Which rails version specifically?

3.1.

Since I was *always* going to be providing a UUID for the pk, I didnt 
even bother changing the default value for the pk in the schema. Im 
going to try fixing that and see if its any better.

On Wed, Jan 25, 2012 at 3:49 PM, Guyren G Howe <gisborne@emailuser.net> 
wrote:
> On Jan 25, 2012, at 1:45 PM, David Chelimsky wrote:
>
>> Just looked back at your initial email and see you cited rspec-2.8,
>> but the way Rails handles incoming params in tests changed in either
>> 3.1 or 3.2 (I have to check). Which rails version specifically?
>
> 3.1.
>
> Since I was *always* going to be providing a UUID for the pk, I didnt even 
bother changing the default value for the pk in the schema. Im going to try fixing 
that and see if its any better.

I'd start by debugging to see where the wheels fall off. Are you
familiar/comfortable with Ruby's debugger?

On Jan 25, 2012, at 1:56 PM, David Chelimsky wrote:

> I'd start by debugging to see where the wheels fall off. Are you
> familiar/comfortable with Ruby's debugger?

Sure.

Whats happening is that during the save process, I get to field_changed? 
in dirty.rb, which does

  value = column.type_cast(value)

when I look at column here, it believes @sql_type = integer. Which seems 
weird.

So at this point, it occurs to me to check this against my test 
database, and the columns in the test database are indeed integers! How 
does this come to be?

On Jan 25, 2012, at 4:50 PM, Guyren G Howe wrote:

>
> when I look at column here, it believes @sql_type = integer. Which seems weird.
>
> So at this point, it occurs to me to check this against my test database, and 
the columns in the test database are indeed integers! How does this come to be?

And note that

  rake db:test:load

doesnt change anything.

On Wed, Jan 25, 2012 at 7:20 PM, Guyren Howe <guyren@mac.com> wrote:
>>
> doesnt change anything.
I'm not sure what rake db:test:load actually does, but `RAILS_ENV=test
rake db:reset` should probably do the trick.

What db are you using, btw?

On Jan 25, 2012, at 6:20 PM, Guyren Howe wrote:

>>
> doesnt change anything.
> _______________________________________________
> rspec-users mailing list
> rspec-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Please paste the table from your schema.rb file.