I have an ajax request that is causing problems in my Rails 3.0.9 app. I can see the problem in the logs, but I don't have any idea what is triggering it between the ajax call and the render. Here's the log, and the event I don't want with ** beside it:
Started DELETE "/notifications/13" for 127.0.0.1 at 2011-06-21 22:08:39 -0500
Processing by NotificationsController#destroy as JS
Parameters: {"id"=>"13"}
SQL (0.4ms) SELECT name
FROM sqlite_master
WHERE type = 'table' AND NOT name = 'sqlite_sequence'
SQL (0.3ms) SELECT name
FROM sqlite_master
WHERE type = 'table' AND NOT name = 'sqlite_sequence'
User Load (0.8ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Slug Load (0.4ms) SELECT "slugs".* FROM "slugs" WHERE ("slugs".sluggable_id = 1 AND "slugs".sluggable_type = 'User') ORDER BY id DESC LIMIT 1
****AREL (0.3ms) UPDATE "users" SET "remember_token" = NULL, "remember_created_at" = NULL, "updated_at" = '2011-06-22 03:08:40.084049', "preferences" = '---
:email_notifications: ''true''
' WHERE "users"."id" = 1
Notification Load (0.2ms) SELECT "notifications".* FROM "notifications" WHERE "notifications"."id" = 13 LIMIT 1
User Load (0.9ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
AREL (0.3ms) UPDATE "users" SET "notifications_count" = COALESCE("notifications_count", 0) - 1 WHERE "users"."id" = 1
AREL (0.1ms) DELETE FROM "notifications" WHERE "notifications"."id" = 13
Completed 200 OK in 1334ms
I'd like to somehow step by step debug this request, sort of like the way you can step through a function in javascript using firebug.
Is there a way to debug like this so I can see how that specific AREL command is getting called??
Have you looked at ruby on rails guides - debugging?? you can debug just like in gdb
This railscast is also quite useful.
Related
I realize this may not be "best practice" but this is sort of a temporary fix/experiment. I'm trying to update a record on Heroku using rails console but whenever I save it just rolls back.
UserAdmin = User.find_by(email: "User#example.com")
UserAdmin.admin = true
UserAdmin.save
The result is:
(0.6ms) BEGIN
(0.6ms) BEGIN
User Exists (0.6ms) SELECT 1 AS one FROM "users" WHERE (LOWER("users"."email") = LOWER('User#example.com') AND "users"."id" != 3) LIMIT 1
User Exists (0.6ms) SELECT 1 AS one FROM "users" WHERE (LOWER("users"."email") = LOWER('User#example.com') AND "users"."id" != 3) LIMIT 1
User Exists (0.5ms) SELECT 1 AS one FROM "users" WHERE (LOWER("users"."user_name") = LOWER('example') AND "users"."id" != 3) LIMIT 1
User Exists (0.5ms) SELECT 1 AS one FROM "users" WHERE (LOWER("users"."user_name") = LOWER('example') AND "users"."id" != 3) LIMIT 1
(0.4ms) ROLLBACK
(0.4ms) ROLLBACK
Am I going about this wrong? Is there any particular reason the record is not saving on Heroku?
What do you get if you do:
user_admin = User.find_by(email: "User#example.com")
user_admin.admin = true
user_admin.valid?
user_admin.errors.full_messages
(I realize this is not an answer yet, but posted it this way because it would be too messy as a comment.)
I have a table subscription with a column status. In my subscriptions controller I have a method accept_player that is supposed to update the subscription.status to "confirmed!"
def accept_player
#subscription = Subscription.find(params[:subscription_id_accept_player])
#subscription.status = "confirmed!"
#subscription.save
authorize #subscription
redirect_to tournament_subscriptions_path(#subscription.tournament)
end
unfortunately every time I try to trigger that method, a rollback seem to take place:
Started POST "/accept_player/39" for ::1 at 2015-07-08 22:01:21 +0100
ActiveRecord::SchemaMigration Load (12.4ms) SELECT "schema_migrations".* FROM "schema_migrations"
/Users/davidgeismar/code/davidgeismar/tennis-match/app/controllers/subscriptions_controller.rb:141: warning: duplicated key at line 155 ignored: "CardType"
Processing by SubscriptionsController#accept_player as HTML
Parameters: {"utf8"=>"✓", "authenticity_token"=>"aas8OPHBpvPwNbbmx/SVipsRM+eKo63nuVilMroxKcU9HRVonjSqEuH7aLY91gFi9PHMUsUqRqk7qhnv2m4L/A==", "subscription_id_accept_player"=>"39", "commit"=>"Confirmer ce Joueur", "subscription_id"=>"39"}
User Load (13.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 ORDER BY "users"."id" ASC LIMIT 1 [["id", 2]]
Subscription Load (11.6ms) SELECT "subscriptions".* FROM "subscriptions" WHERE "subscriptions"."id" = $1 LIMIT 1 [["id", 39]]
(5.7ms) BEGIN
Subscription Exists (0.8ms) SELECT 1 AS one FROM "subscriptions" WHERE ("subscriptions"."user_id" = 20 AND "subscriptions"."id" != 39 AND "subscriptions"."tournament_id" = 9) LIMIT 1
(12.6ms) ROLLBACK
Tournament Load (2.4ms) SELECT "tournaments".* FROM "tournaments" WHERE "tournaments"."id" = $1 LIMIT 1 [["id", 9]]
User Load (0.4ms) SELECT "users".* FROM "users" WHERE "users"."id" = $1 LIMIT 1 [["id", 2]]
Redirected to http://localhost:3000/tournaments/9/subscriptions
Completed 302 Found in 246ms (ActiveRecord: 79.7ms)
Any ideas about what might be going wrong here ?
This code:
authorize #subscription
is probably causing the rollback. If you're in dev mode, just comment it out, reload!, and try to manually add a record and see if that's the cause.
I finished few minutes ago my project. I made a commit, after this I wanted to clear DB because there was many testing records. So I ran this in my DBconsole:
sqlite> delete from users where id;
sqlite> delete from users where id=1;
sqlite> delete from posts where id=1;
sqlite> delete from votes where id=1;
After this my project didn't work(((. It returns:
We're sorry, but something went wrong.
If you are the application owner check the logs for more information.
On every page, even statics!!!!
I need my project to tomorrow. I restored from Git, but error is not disappeared.
My logs see like this:
Started GET "/" for 127.0.0.1 at 2014-03-14 04:08:40 +0200
Processing by PostsController#index as HTML
(0.4ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 1
(0.3ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 2
(0.4ms) SELECT COUNT(*) FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4)
Post Load (0.7ms) SELECT "posts".* FROM "posts" WHERE "posts"."statut" = 1 ORDER BY created_at DESC LIMIT 10
Post Load (0.6ms) SELECT "posts".* FROM "posts" WHERE "posts"."statut" = 2 ORDER BY created_at DESC LIMIT 10
Post Load (0.5ms) SELECT "posts".* FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4) ORDER BY created_at DESC LIMIT 10
Rendered posts/index.html.erb within layouts/application (23.5ms)
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 1
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 2
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4)
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 1
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 2
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4)
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 1
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE "posts"."statut" = 2
CACHE (0.0ms) SELECT COUNT(*) FROM "posts" WHERE ("posts"."statut" BETWEEN 3 AND 4)
User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 8]]
Completed 500 Internal Server Error in 74ms
This is for main page. Help me!! I can give u a git, I need to repair it, please.
You deleted all your users with this statement.
delete from users where id;
So the line in the log
User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 8]]
Won't be able to load user with id 8 because the table is empty. Maybe you need to add back a user crucial for your program to function.
I'm having a baffling problem. I have a LineItem model that accepts nested attributes for a Trackable and a Product. I am overriding the default trackable_attributes= and product_attributes= methods to allow me to find or initialize records. For example:
def trackable_attributes=(attributes)
_trackable = Project.find_or_initialize_by_id(attributes.delete("id"))
_trackable.attributes = attributes
self.trackable = _trackable
end
When I post to the LineItemController#create, even when there's only a logging statement in it, it runs all of the posted parameters as if I'm trying to build/create a new line item. I don't have any before_filters that would be doing this on the #create method.
def create
logger.info("LineItemsController#create")
end
Webserver logs:
Started POST "/line_items" for 127.0.0.1 at 2013-04-10 14:02:13 -0700
Processing by LineItemsController#create as JS
Parameters: {"utf8"=>"✓", "authenticity_token"=>"MY_SECRET_TOKEN", "line_item"=>{"trackable_type"=>"Project", "tax_rate"=>"0", "price"=>"0.00", "provided_on_formatted"=>"Apr 10", "trackable_attributes"=>{"company_attributes"=>{"id"=>"87", "name"=>"Handmade Design"}, "id"=>"45", "name"=>"MEdia Blitz"}, "product_attributes"=>{"id"=>"75"}, "name"=>"Design", "notes"=>"Yellow", "quantity"=>"0.00", "unit_price"=>"205.0"}, "commit"=>"+"}
Person Load (0.3ms) SELECT "people".* FROM "people" WHERE "people"."id" = 73 LIMIT 1
(0.1ms) begin transaction
(0.4ms) UPDATE "people" SET "last_request_at" = '2013-04-10 21:02:13.861629', "perishable_token" = 'kzsB5dnCOHfykO1XMMi9', "updated_at" = '2013-04-10 21:02:13.863622' WHERE "people"."id" = 73
[paperclip] Saving attachments.
(1.2ms) commit transaction
Account Load (0.2ms) SELECT "accounts".* FROM "accounts" WHERE "accounts"."id" = 369 LIMIT 1
Person Load (0.3ms) SELECT "people".* FROM "people" WHERE "people"."account_id" = 369 ORDER BY id LIMIT 1
{"company_attributes"=>{"id"=>"87", "name"=>"Handmade Design"}, "id"=>"45", "name"=>"MEdia Blitz"}
Project Load (0.2ms) SELECT "projects".* FROM "projects" WHERE "projects"."id" = 45 LIMIT 1
Company Load (0.2ms) SELECT "companies".* FROM "companies" WHERE "companies"."id" = 87 LIMIT 1
trackable_attributes=(attributes)
trackable assigned
{"id"=>"75"}
Product Load (0.2ms) SELECT "products".* FROM "products" WHERE "products"."id" = 75 LIMIT 1
product_attributes=(attributes)
product assigned
LineItemsController#create
Notice that I have many logging statements scattered through my custom accepts_nested_attributes_for setters that are being called before the #create method even begins.
Is this normal? It seems to be causing problems with when I want to instantiate a new line_item the normal way in my LineItemsController#create method.
I'd really appreciate any help as I'm lost on where to start.
This one is driving me absolutely crazy. I tested updating user's email address on dev and staging environments, and it all worked fine. It updates unconfirmed_email field and sends out a confirmation email address.
However, only in production environment, it fails!
In dev/staging environment, I see the following statements when a user updates his/her email address.
User Load (0.5ms) SELECT "users".* FROM "users" WHERE "users"."id" = 2 LIMIT 1
Profile Load (0.3ms) SELECT "profiles".* FROM "profiles" WHERE "profiles"."user_id" = 2 LIMIT 1
(0.1ms) BEGIN
User Exists (0.6ms) SELECT 1 FROM "users" WHERE ("users"."email" = 'aaaa#yahoo.com' AND "users"."id" != 2) LIMIT 1
(0.3ms) UPDATE "users" SET "unconfirmed_email" = 'aaaa#yahoo.com', "updated_at" = '2012-08-27 04:22:10.470329' WHERE "users"."id" = 2
User Load (0.3ms) SELECT "users".* FROM "users" WHERE "users"."confirmation_token" = 'jUcfXqMqDjeEsJ3TEKws' LIMIT 1
(0.3ms) UPDATE "users" SET "unconfirmed_email" = 'aaaa#yahoo.com', "updated_at" = '2012-08-27 04:22:10.470329', "confirmation_token" = 'jUcfXqMqDjeEsJ3TEKws', "confirmation_sent_at" = '2012-08-27 04:22:10.473264' WHERE "users"."id" = 2
However, in production, I see the following.
User Load (6.7ms) SELECT "users".* FROM "users" WHERE "users"."id" = 5 LIMIT 1
Profile Load (2.1ms) SELECT "profiles".* FROM "profiles" WHERE "profiles"."user_id" = 5 LIMIT 1
(1.2ms) BEGIN
User Exists (1.3ms) SELECT 1 FROM "users" WHERE ("users"."email" = 'aaaa#yahoo.com' AND "users"."id" != 5) LIMIT 1
(1.2ms) ROLLBACK
One more odd thing. I could update the email address manually in rails console.....
1.9.3p194 :005 > u.update_attributes(:email => "aaaa#yahoo.com")
(1.3ms) BEGIN
User Exists (1.4ms) SELECT 1 FROM "users" WHERE ("users"."email" = 'aaaa#yahoo.com' AND "users"."id" != 1) LIMIT 1
(1.4ms) UPDATE "users" SET "unconfirmed_email" = 'aaaa#yahoo.com', "updated_at" = '2012-08-27 05:05:26.337961' WHERE "users"."id" = 1
User Load (1.4ms) SELECT "users".* FROM "users" WHERE "users"."confirmation_token" = 'Yyg98zno81adJt4mp7pG' LIMIT 1
(1.4ms) UPDATE "users" SET "unconfirmed_email" = 'aaaa#yahoo.com', "updated_at" = '2012-08-27 05:05:26.337961', "confirmation_token" = 'Yyg98zno81adJt4mp7pG', "confirmation_sent_at" = '2012-08-27 05:05:26.342299' WHERE "users"."id" = 1
Profile Load (1.4ms) SELECT "profiles".* FROM "profiles" WHERE "profiles"."user_id" = 1 LIMIT 1
(1.7ms) COMMIT
=> true
Any help would be much appreciated!
Thanks,
I was trying to figure out what the differences are between the two environments - dev/staging vs. production. Since staging and production have pretty much identical settings, the only I could think of was cacheing. So, I changed the update_attributes line to the following and it worked.
if #user.reload.update_attributes(:email => params[:email])