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
On Apr 8, 4:38 pm, Marian S. [email protected]
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
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
On Apr 9, 4:23 am, Marian S. [email protected]
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
On Fri, Apr 9, 2010 at 8:34 PM, Ho-Sheng H. [email protected]
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.
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!