Mysql::Error: SAVEPOINT

[mikej]

Nearly a month ago, I had 200 odd steps happily passing. I upgraded
Cucumber from 0.1.16 to 0.3.11 and Rails from 2.0.1 to 2.3.2 and have
had a nightmare since - I've had to reinstall operating system!

Now when I run I single feature (or a number) I get the error:

Mysql::Error: SAVEPOINT active_record_1 does not exist: ROLLBACK TO
SAVEPOINT active_record_1 (ActiveRecord::StatementInvalid)

If I go to test.log I see the error comes after an INSERT command.
The insert works fine if sent straight to the db as sql.

If I comment out Cucumber::Rails.use_transactional_fixtures the error
disappears, but then I receive other errors as the database is not
reset in between scenarios.

Any help really gratefully received,

many thanks,

Mike

[aslak hellesoy]

Nearly a month ago, I had 200 odd steps happily passing.  I upgraded
Cucumber from 0.1.16 to 0.3.11 and Rails from  2.0.1 to 2.3.2 and have
had a nightmare since - I've had to reinstall operating system!

It sounds like you had to reinstall your OS *because* you upgraded Cucumber and Rails. You're joking, right?

Now when I run I single feature (or a number) I get the error:

Mysql::Error: SAVEPOINT active_record_1 does not exist: ROLLBACK TO
SAVEPOINT active_record_1 (ActiveRecord::StatementInvalid)

http://lmgtfy.com/?q=Mysql%3A%3AError+SAVEPOINT+rails

I hope that helps.
 

[mikej]

Not really joking, ended up with new operating system after trying to
fix various bugs after the upgrade following suggestions from this
group.

No luck with the google search which I had obviously already tried.
Seems to be some disagreement with mysql, but don't know the fix.

Mike

[aslak hellesoy]

Have you tried to upgrade only Rails or Cucumber to figure out which upgrade breaks for you?

Aslak
 

Mike

[mikej]

Too late to tell what happened during the upgrade, I have a
reinstalled leopard now. I am just keen to be able to run all my
cucumber features at once rather than one at a time.

Sincere thanks for your replies,

Mike

[aslak hellesoy]

Too late to tell what happened during the upgrade, I have a
reinstalled leopard now.  I am just keen to be able to run all my

But you still have the revision in source control from before your upgrade right? You could check out the last revision before your big upgrade and try from there. I'd start by upgrading one Rails version at a time and see if that breaks anything.
 

cucumber features at once rather than one at a time.

Sincere thanks for your replies,

This sounds like an ActiveRecord transaction problem. Have you tried to get help in Rails' forums?

Aslak

Mike

[Ben Mabey]

In your Rails environment file that you use for cucumber do you have
cache_classes set to true or false? It should be set to true for
Cucumber's rollbacks to work properly. When you upgraded cucumber did
you rerun the 'cucumber' generator? It now ships with it's own Rails
env to avoid the cache_classes problem.

-Ben

[mikej]

Thanks Ben. Cache_classes set to true and have re run cucumber
generators.

[mikej]

Yep cache_classes are set to true and I re-ran the generator.

As I said, If I comment out Cucumber::Rails.use_transactional_fixtures
all is okay - I can run one feature at a time.

I could go to previous versions and go through upgrade process in
stages. Its a big hassle though!

Thanks again,

Mike

[mikej]

Narrowing in on the error now. Sorry I didn't see this before.

I use the line:

ActiveRecord::Base.connection.execute('ALTER TABLE roles
AUTO_INCREMENT = 1')

If I remove this from my code, it runs okay.

Perhaps I should post this in a mysql forum. There must be a link to
Cucumber::Rails.use_transactional_fixtures as this alters the
behaviour. It would be good to understand whats happening!

Regards,

Mike

[Stephen Eley]

On Mon, Aug 3, 2009 at 4:06 PM, mikej<mikeje...@gmail.com> wrote:
>
> ActiveRecord::Base.connection.execute('ALTER TABLE roles
> AUTO_INCREMENT = 1')
>

> Perhaps I should post this in a mysql forum.  There must be a link to
> Cucumber::Rails.use_transactional_fixtures as this alters the
> behaviour.  It would be good to understand whats happening!

Well, yeah. DDL statements (data definition, such as altering tables)
are not transactional. I'm not a MySQL expert, but in _most_ SQL
databases doing anything like that will commit your transaction
immediately.

What I'm curious about is: *WHY* in the name of all gods little-endian
and big-endian are you resetting your ID counter in the middle of a
Rails workflow? Why do you *care* what the ID values are? Are you
afraid you'll run out of numbers?

This isn't a necessary step. If you feel it is, or are truly in a
situation where it is, you've almost certainly managed to make
something too complicated.

--
Have Fun,
Steve Eley (sfe...@gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org