I have a site that uses MySQL, Rails 1.2.3, and apache (proxy load
balancer). I have 4 mongrels running.
Every so often when I use capistrano to deploy my latest stuff, it
seems that one or more of the rails gets into a “i don’t want to set
created_at” mood. I end up with a sprinkling of records in my db with
created_at of null and some created right around the same time with it
set correctly. If is restart the rails the problem will clear. It
has happened a couple of times. Now I’m getting psychotic and running
sql commands all the time checking the hot tables for the rogue
mongrel.
Anybody else run into this problem? I have since put in a MySQL
constraint to force a non-null created_at but the whole thing makes me
a little nervous about my up to know trusted rails.
sql commands all the time checking the hot tables for the rogue
mongrel.
Anybody else run into this problem? I have since put in a MySQL
constraint to force a non-null created_at but the whole thing makes me
a little nervous about my up to know trusted rails.
Yep. Here is a sample of one of the tables that goes nuts. For the
most part, it works as advertised, I have just had a few periods
where all of a sudden I find records in the db with created_at.nil? ==
true. I have displays that :order => ‘created_at DESC’ and they don’t
work correctly. This does not just happen on one table, but across
many different tables. But not everything. That is what makes me
suspect a rogue mongrel.
class CreateReading < ActiveRecord::Migration
def self.up
create_table :readings do |t|
t.column :notification_id, :integer
t.column :bean_id, :integer
t.column :created_at, :datetime
t.column :updated_at, :datetime
t.column :cleared, :boolean, :default => false
end
end
mysql -v
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 92725 to server version: 5.0.22
I changed the database tables forcing the constraint of the created_at
cannot be null. So now instead of quietly chugging along it causes an
error and I get the nice notification email with the trace. The nice
thing is that the email tells me which specific rail is causing the
crash. This has happened twice since last December and both times it
was only 1 of the 4 rails that went nuts.
To recap:
I have 4 mongrels that run fine for a time. Then for some reason, one
of them (that’s the only case I’ve run into so far) will start
forgetting to set created_at on new record creates. If I restart the
mongrels, the problem clears.
Here is my nice SQL message:
Mysql::Error: #23000Column ‘created_at’ cannot be null: INSERT INTO
notifications (updated_at, title, bean_id, url, description, triggering_event, created_at) VALUES(NULL, ‘Bean Comment’, 7780, ‘/
you_tube_movie_bean/view/?bean_id=7780&full_screen=true’, ‘Tony De
Ruvo has commented on this bean. Title: “this is soo funny”
Description: check out parts 2 and 3\n\n’, ‘Comment’, NULL)
/usr/lib/ruby/gems/1.8/gems/activerecord-1.15.3/lib/active_record/
connection_adapters/abstract_adapter.rb:128:in `log’
So you can see that the insert for some reason is setting created_at
to NULL (last field in the parens).
How can I look into the rails bug db to see if this has ever been seen
before?
No. The model works fine for weeks with 1000s of inserts. When the
condition happens, it seems like every insert from that particular
rail sets created_at to NULL. Since I put the non-null constraint on
the tables, I get crashes whenever that particular rail tries to
insert into any of those tables. Simultaneously, the other 3 non-
freaked out rails are inserting using the same code.
I’ve had the same problem. Activerecord seems to set created_at and
updated_at to null sometimes. I haven’t managed to see any pattern in
it. Currently I’ve added this to my model to fix it.
since there is a bug in activerecord(?)…
def before_create
self.created_at = Time.now
self.updated_at = Time.now
end
Hi, no, no hidden fields or anything like that. Nothing strange appears
in the log file. And the fields are set to datetime, and no overrides.
So… it’s strange.
I’ll keep you updated if I manage to find out what causes it.
Tobias
Ryan B. wrote:
Very interesting, still.
You don’t have any hidden_fields or select boxes with created_at and
nothing
overriding in the model?
Your field is set to datetime?
On Fri, May 9, 2008 at 6:15 PM, Tobias Nurmiranta < [email protected]> wrote: