An error on edge at -r 2767

[sinclair bain-2]

Morning,

Having done an svn up this morning all my specs are broken with the following:

SQLite3::SQLException in ServiceConfig with minimum set of valid parameters should return nil for the service path'

SQL logic error or missing database

C:/development/sandbox/prototypes/user_admin_client/config/../vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in `before_eval'

 

None of my code had changed.

All  specs worked immediately prior to the 'svn up' this morning. 

Now all are broken immediately after the svn up.

I am trying to track this down but hoping for some "Help ..." .

Cheers!

sinclair

 

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[sinclair bain-2]

Hi,

Updated from  the trunk/edge again today however all the specs still fail as before.

I uninstalled and moved back to the 1.0.8 release and all specs are successful again.

Unfortunately, no Story Runner.

Cheers!

sinclair

On 10/22/07, sinclair bain <rspec.user@...> wrote:

Morning,

 

Having done an svn up this morning all my specs are broken with the following:

 

SQLite3::SQLException in ServiceConfig with minimum set of valid parameters should return nil for the service path'

SQL logic error or missing database

C:/development/sandbox/prototypes/user_admin_client/config/../vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in `before_eval'

 

 

None of my code had changed.

All  specs worked immediately prior to the 'svn up' this morning. 

Now all are broken immediately after the svn up.

 

I am trying to track this down but hoping for some "Help ..." .

 

Cheers!

sinclair

 

 

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[David Chelimsky-2]

On 10/23/07, sinclair bain <rspec.user@...> wrote:
> Hi,Updated from  the trunk/edge again today however all the specs still fail
> as before.
>
> I uninstalled and moved back to the 1.0.8 release and all specs are
> successful again.
>
> Unfortunately, no Story Runner.

Sorry Sinclair, but I have no idea what is causing your woes. I think
we need to see some code and some backtraces if you want any help.
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[sinclair bain-2]

Ok

Using rails 1.2.3

> rails trunk-error -d sqlite3

> cd trunk-error

> ruby script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/rspec

> ruby script/plugin install svn://rubyforge.org/var/svn/rspec/trunk/rspec_on_rails

> ruby script/generate rspec

In an editor create the following model spec (spec/models/foo_spec.rb)

require File.dirname(__FILE__) + '/../spec_helper'

describe 'trunk error' do

  it 'should fail' do

    true.should == false

  end

  it 'should not fail' do

    true.should == true

  end

  

end

> rake spec:models -t

This causes the problem.

1)

SQLite3::SQLException in 'trunk error should not fail'

SQL logic error or missing database

C:/development/sandbox/prototypes/trunk-error/config/../vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in `before_eval'

2)

SQLite3::SQLException in 'trunk error should fail'

SQL logic error or missing database

C:/development/sandbox/prototypes/trunk-error/config/../vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in `before_eval'

Finished in 0.61 seconds

Now if the plugins are removed then the 1.0.8 release installed

> ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_1_0_8/rspec

> ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_1_0_8/rspec_on_rails

> ruby script/generate rspec

 Then 

> rake spec:models -t

Then the specs behave as coded i.e. 1 success and 1 fail.

This was not the case last week. This did not occur until 

On 10/23/07, David Chelimsky <dchelimsky@...> wrote:

On 10/23/07, sinclair bain <rspec.user@...> wrote:
> Hi,Updated from  the trunk/edge again today however all the specs still fail
> as before.
>
> I uninstalled and moved back to the 1.0.8 release and all specs are
> successful again.
>
> Unfortunately, no Story Runner.

Sorry Sinclair, but I have no idea what is causing your woes. I think
we need to see some code and some backtraces if you want any help.
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[sinclair bain-2]

Oops,

A bit over-zealous on the send.

As I meant to add 

This was not the case last week. This did not occur until yesterday when I svn upped the project (I had installed the rspec trunk as an svn:external). 

This all occurs on WindowsXP

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[David Chelimsky-2]

On 10/23/07, sinclair bain <rspec.user@...> wrote:
> Oops,
>
> A bit over-zealous on the send.
>
> As I meant to add
> This was not the case last week. This did not occur until yesterday when I
> svn upped the project (I had installed the rspec trunk as an svn:external).
> This all occurs on WindowsXP

Ah - I am therefore not able to help debug this precisely - though I
did follow your instructions and got a different error:

1)
SQLite3::SQLException in 'trunk error should not fail'
cannot start a transaction within a transaction
/Users/david/projects/ruby/trunk-error/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in
`before_eval'

2)
SQLite3::SQLException in 'trunk error should fail'
cannot start a transaction within a transaction
/Users/david/projects/ruby/trunk-error/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in
`before_eval'

Setting config.use_transactional_fixtures = false in
spec/spec_helper.rb resolved that. Any chance that is the source of
your problem?
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[David Chelimsky-2]

On 10/23/07, David Chelimsky <dchelimsky@...> wrote:
> On 10/23/07, sinclair bain <rspec.user@...> wrote:
> > This all occurs on WindowsXP
>
> Ah - I am therefore not able to help debug this precisely

In case this wasn't clear - because I don't have that OS available :)
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[sinclair bain-2]

David,

This does the trick.

However this is the same in the REL_1_0_8 tag yet that works as before. The only thing which changed being the rspec plugin versions.

So it looks like something else may have changed, I am wondering if this was an error case which was ignored in the REL_1_0_8 tag. 

Anyway I am where I was (?) .

I will poke around a little more ...

Thanks !

Cheers!

sinclair

On 10/23/07, David Chelimsky <dchelimsky@...> wrote:

On 10/23/07, sinclair bain <rspec.user@...> wrote:
> Oops,
>
> A bit over-zealous on the send.
>
> As I meant to add
> This was not the case last week. This did not occur until yesterday when I
> svn upped the project (I had installed the rspec trunk as an svn:external).
> This all occurs on WindowsXP

Ah - I am therefore not able to help debug this precisely - though I
did follow your instructions and got a different error:

1)
SQLite3::SQLException in 'trunk error should not fail'
cannot start a transaction within a transaction
/Users/david/projects/ruby/trunk-error/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in
`before_eval'


2)
SQLite3::SQLException in 'trunk error should fail'
cannot start a transaction within a transaction
/Users/david/projects/ruby/trunk-error/vendor/plugins/rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in
`before_eval'

Setting config.use_transactional_fixtures = false in
spec/spec_helper.rb resolved that. Any chance that is the source of
your problem?

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[David Chelimsky-2]

On 10/23/07, sinclair bain <rspec.user@...> wrote:

> David,
> This does the trick.
>
> However this is the same in the REL_1_0_8 tag yet that works as before. The
> only thing which changed being the rspec plugin versions.
>
> So it looks like something else may have changed, I am wondering if this was
> an error case which was ignored in the REL_1_0_8 tag.
>
> Anyway I am where I was (?) .

"This does the trick" sounds like the problem is solved but "I am
where I was" sounds like the problem still exists. What do you mean?
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[sinclair bain-2]

OK.

Looks like this whole area has been worked upon.

In the trunk the 

    rspec_on_rails/lib/spec/rails/dsl/behaviour/ 

directory has been reworked.

The rails_example.rb file contains the class method #before_eval where the error is sourced.

In REL_1_0_8 this functionality was in the base.rb file there is no #before_eval functionality as such.

There is no (obvious) calls to 

   #prepend_before {setup}

   #append_after {teardown}
and the #configure is slightly different.

However the #before_eval exists in the rspec/lib/spec/dsl/behaviour.rb but is an empty (no-op) implementation.

Plus Spec::DSL::Example inherits from Test::Unit::TestCase in the trunk (hence the calls to setup/teardown)

So ... somewhere in there lies the cause.    ; )

Anyway I get the Story Runner back with the manual config modification so that's where we want to be.

Cheers!

sinclair

 

On 10/23/07, David Chelimsky <dchelimsky@...> wrote:

On 10/23/07, David Chelimsky <dchelimsky@...> wrote:
> On 10/23/07, sinclair bain <rspec.user@...> wrote:
> > This all occurs on WindowsXP
>
> Ah - I am therefore not able to help debug this precisely

In case this wasn't clear - because I don't have that OS available :)
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[David Chelimsky-2]

On 10/23/07, sinclair bain <rspec.user@...> wrote:
> So ... somewhere in there lies the cause.    ; )
>
> Anyway I get the Story Runner back with the manual config modification so
> that's where we want to be.

Just to be clear - that's where you *should* have been all along. It
looks config.trans_fixtures... was broken, and is now working
correctly :)
_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[sinclair bain-2]

Ignorance was  bliss.

Cheers!

sinclair

On 10/23/07, David Chelimsky <dchelimsky@...> wrote:

On 10/23/07, sinclair bain <rspec.user@...> wrote:
> So ... somewhere in there lies the cause.    ; )
>
> Anyway I get the Story Runner back with the manual config modification so
> that's where we want to be.

Just to be clear - that's where you *should* have been all along. It
looks config.trans_fixtures... was broken, and is now working
correctly :)
_______________________________________________

rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Scott Taylor-6]

On Oct 23, 2007, at 1:54 PM, David Chelimsky wrote:

> On 10/23/07, sinclair bain <rspec.user@...> wrote:
>> Oops,
>>
>> A bit over-zealous on the send.
>>
>> As I meant to add
>> This was not the case last week. This did not occur until  
>> yesterday when I
>> svn upped the project (I had installed the rspec trunk as an  
>> svn:external).
>> This all occurs on WindowsXP
>
> Ah - I am therefore not able to help debug this precisely - though I
> did follow your instructions and got a different error:
>
> 1)
> SQLite3::SQLException in 'trunk error should not fail'
> cannot start a transaction within a transaction
> /Users/david/projects/ruby/trunk-error/vendor/plugins/
> rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in
> `before_eval'
>
> 2)
> SQLite3::SQLException in 'trunk error should fail'
> cannot start a transaction within a transaction
> /Users/david/projects/ruby/trunk-error/vendor/plugins/
> rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in
> `before_eval'
>
> Setting config.use_transactional_fixtures = false in
> spec/spec_helper.rb resolved that. Any chance that is the source of
> your problem?

My guess is that something screwy is going on with transactional  
fixtures / rollbacks with rspec.  (I'm running on rspec trunk, rails  
1.2.3) Two things tip me off to this:

1. I was able to use sqlite3 a few days ago.  Now I'm getting a  
series of errors if I try to run sqlite3 in test mode (as per the  
original report).  I haven't tried turning off transactional  
fixtures, but when I do, I'll report back.
2. My colleague/co-worker runs the test suite with rake spec, I  
prefer to use Autotest.  His tests have been passing, while when I  
run them, they are failing.  We have removed the fixtures directory  
both from the test and spec directories.  We generate the data per  
test case (or in setup/before(:each) blocks).  Here was one test,  
which was failing (although passing two days ago):

describe %(User who is trying to ignore items from the review queue) do

   before :each do
     @user = create_user
   end

   it "should not find any of the ignored items in the review queue" do
     item = create_writing
     create_ignored_item(:created_at => 25.hours.ago, :user =>  
@user, :item => item)
     @user.hack_review_queue.should == []
   end
end

Running ruby-debug, I found that in the example there were 80 Items  
left hanging around.  Only one Item should be around from this test  
case.  Adding the following did the trick:

before(:each) do
   Item.delete_all
   @user = create_user
end

(There is also one more example in this description block which  
creates 20 items, which I've omitted for clarity.  Sorry if the spec  
is opaque - the method under question is looking for an Item which  
isn't being ignored/skipped, and I've created just one item, which  
*is* being skipped, so it shouldn't find that one item in our queue).

The point of this is: 80 items shouldn't be hanging around.  Looks  
like a problem of transactional fixtures (which rolls back to the  
test database for every test case).

Scott




_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users

[Scott Taylor-6]

On Oct 24, 2007, at 2:58 AM, Scott Taylor wrote:

Is no one else experiencing roll back problems on Trunk rspec?

Scott

>
> On Oct 23, 2007, at 1:54 PM, David Chelimsky wrote:
>
>> On 10/23/07, sinclair bain <rspec.user@...> wrote:
>>> Oops,
>>>
>>> A bit over-zealous on the send.
>>>
>>> As I meant to add
>>> This was not the case last week. This did not occur until
>>> yesterday when I
>>> svn upped the project (I had installed the rspec trunk as an
>>> svn:external).
>>> This all occurs on WindowsXP
>>
>> Ah - I am therefore not able to help debug this precisely - though I
>> did follow your instructions and got a different error:
>>
>> 1)
>> SQLite3::SQLException in 'trunk error should not fail'
>> cannot start a transaction within a transaction
>> /Users/david/projects/ruby/trunk-error/vendor/plugins/
>> rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in
>> `before_eval'
>>
>> 2)
>> SQLite3::SQLException in 'trunk error should fail'
>> cannot start a transaction within a transaction
>> /Users/david/projects/ruby/trunk-error/vendor/plugins/
>> rspec_on_rails/lib/spec/rails/dsl/behaviour/rails_example.rb:17:in
>> `before_eval'
>>
>> Setting config.use_transactional_fixtures = false in
>> spec/spec_helper.rb resolved that. Any chance that is the source of
>> your problem?
>
> My guess is that something screwy is going on with transactional
> fixtures / rollbacks with rspec.  (I'm running on rspec trunk, rails
> 1.2.3) Two things tip me off to this:
>
> 1. I was able to use sqlite3 a few days ago.  Now I'm getting a
> series of errors if I try to run sqlite3 in test mode (as per the
> original report).  I haven't tried turning off transactional
> fixtures, but when I do, I'll report back.
> 2. My colleague/co-worker runs the test suite with rake spec, I
> prefer to use Autotest.  His tests have been passing, while when I
> run them, they are failing.  We have removed the fixtures directory
> both from the test and spec directories.  We generate the data per
> test case (or in setup/before(:each) blocks).  Here was one test,
> which was failing (although passing two days ago):
>
> describe %(User who is trying to ignore items from the review  
> queue) do
>
>    before :each do
>      @user = create_user
>    end
>
>    it "should not find any of the ignored items in the review  
> queue" do
>      item = create_writing
>      create_ignored_item(:created_at => 25.hours.ago, :user =>
> @user, :item => item)
>      @user.hack_review_queue.should == []
>    end
> end
>
> Running ruby-debug, I found that in the example there were 80 Items
> left hanging around.  Only one Item should be around from this test
> case.  Adding the following did the trick:
>
> before(:each) do
>    Item.delete_all
>    @user = create_user
> end
>
> (There is also one more example in this description block which
> creates 20 items, which I've omitted for clarity.  Sorry if the spec
> is opaque - the method under question is looking for an Item which
> isn't being ignored/skipped, and I've created just one item, which
> *is* being skipped, so it shouldn't find that one item in our queue).
>
> The point of this is: 80 items shouldn't be hanging around.  Looks
> like a problem of transactional fixtures (which rolls back to the
> test database for every test case).
>
> Scott
>
>
>
>
> _______________________________________________
> rspec-users mailing list
> rspec-users@...
> http://rubyforge.org/mailman/listinfo/rspec-users

_______________________________________________
rspec-users mailing list
rspec-users@...
http://rubyforge.org/mailman/listinfo/rspec-users