# Getting rid of unwanted DB transactions? **URL:** \ **Category:** Rails\ **Created:** [April 8, 2010, 10:40pm UTC](https://www.ruby-forum.com/t/getting-rid-of-unwanted-db-transactions/186560 "2010-04-08T22:40:47Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![mari\_an](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7ea924/32.png) [@mari\_an](https://www.ruby-forum.com/u/mari_an)\ **Post date:** [April 8, 2010, 10:40pm UTC](https://www.ruby-forum.com/t/getting-rid-of-unwanted-db-transactions/186560/1 "2010-04-08T22:40:47Z")
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 ---
**Author:** ![mari\_an](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7ea924/32.png) [@mari\_an](https://www.ruby-forum.com/u/mari_an)\ **Post date:** [April 9, 2010, 12:20am UTC](https://www.ruby-forum.com/t/getting-rid-of-unwanted-db-transactions/186560/2 "2010-04-09T00:20:53Z")
On Apr 8, 4:38 pm, Marian S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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. 🙂 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 H. [http://hosheng.blogspot.com](http://hosheng.blogspot.com) ---
**Author:** ![mari\_an](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7ea924/32.png) [@mari\_an](https://www.ruby-forum.com/u/mari_an)\ **Post date:** [April 9, 2010, 10:24am UTC](https://www.ruby-forum.com/t/getting-rid-of-unwanted-db-transactions/186560/3 "2010-04-09T10:24:57Z")
On Fri, Apr 9, 2010 at 12:19 AM, Ho-Sheng H. wrote: > > … > > That sounds like a code smell. 🙂 See below. > > > … > > How about creating the first Model, then the User model, and then > after that is setup, do the login? 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 ---
**Author:** ![mari\_an](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7ea924/32.png) [@mari\_an](https://www.ruby-forum.com/u/mari_an)\ **Post date:** [April 9, 2010, 8:36pm UTC](https://www.ruby-forum.com/t/getting-rid-of-unwanted-db-transactions/186560/4 "2010-04-09T20:36:05Z")
On Apr 9, 4:23 am, Marian S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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. 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 H. [http://hosheng.blogspot.com](http://hosheng.blogspot.com) ---
**Author:** ![mari\_an](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7ea924/32.png) [@mari\_an](https://www.ruby-forum.com/u/mari_an)\ **Post date:** [April 14, 2010, 6:09pm UTC](https://www.ruby-forum.com/t/getting-rid-of-unwanted-db-transactions/186560/5 "2010-04-14T18:09:40Z")
On Fri, Apr 9, 2010 at 8:34 PM, Ho-Sheng H. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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.’ 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. ---
**Author:** ![mari\_an](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/7ea924/32.png) [@mari\_an](https://www.ruby-forum.com/u/mari_an)\ **Post date:** [April 9, 2010, 10:25am UTC](https://www.ruby-forum.com/t/getting-rid-of-unwanted-db-transactions/186560/6 "2010-04-09T10:25:32Z")
On Fri, Apr 9, 2010 at 12:19 AM, Ho-Sheng H. wrote: > > … > > That sounds like a code smell. 🙂 See below. > > > … > > How about creating the first Model, then the User model, and then > after that is setup, do the login? 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!