Getting rid of unwanted DB transactions?

It seems as if I am having trouble with Rails automatically wrapping
multiple SQL INSERT statements into BEGIN and COMMIT.

Is there a way to prevent Rails from doing this?

I want to create a user object when creating some other object and
asign the user to that one. And then finally I want to log in that
Users (authlogic). All in one step. But it appears as if the new user
record gets no ID, since not yet written, and thus cannot be assigned
to the rest.

This all happens only since I moved from sqlite to MySQL with InnoDB.

Thanks for your hints!

Marian

It seems as if I am having trouble with Rails automatically wrapping
multiple SQL INSERT statements into BEGIN and COMMIT.

Is there a way to prevent Rails from doing this?

That sounds like a code smell. :slight_smile: See below.

I want to create a user object when creating some other object and
asign the user to that one. And then finally I want to log in that
Users (authlogic). All in one step. But it appears as if the new user
record gets no ID, since not yet written, and thus cannot be assigned
to the rest.

How about creating the first Model, then the User model, and then
after that is setup, do the login?

Ho-Sheng Hsiao
http://hosheng.blogspot.com

Yeah, I will try that. Think my setup was backwards.

My model is like this:

SearchSubscrtipion belongs_to User
User has_many SearchSubscriptions

In the SearchSubscription model I had a before_create callback that
was trying to create the new user record if not yet available. (Thus
creating it's own parent on the fly.) Seems as if that's impossible.

I will try as you stated, without the before_create callback.

Thanks!

Marian

Yeah, I will try that. Think my setup was backwards.

My model is like this:

SearchSubscrtipion belongs_to User
User has_many SearchSubscriptions

In the SearchSubscription model I had a before_create callback that
was trying to create the new user record if not yet available. (Thus
creating it's own parent on the fly.) Seems as if that's impossible.

I will try as you stated, without the before_create callback.

Thanks!

Right, so create the User first, then create a new SearchSubscription
that belongs to the user. You might be better off having the users
created independently, that is, not attached to the idea of
"dynamically generate the user whenever they want to do a search". But
rather, "Anonymous User wants to save a search, so they are redirected
to the signup screen.'

Ho-Sheng Hsiao
http://hosheng.blogspot.com

Thanks for your reply!

Actually, forcing users to go through a registration process *before*
they do anything else is what I'm trying to avoid, because it doesn't
match with the users goals.

Now I rewrote that part so the user is created first, then the
searchSubscription is creeated, and everything is fine.