I could use a little help trouble shooting this problem.
When using the app to create a new record nothing is being saved to the database.
There are no visible errors presented.
Dropping to the command line, and using the console with the same production environment, I can create a new object and save it (I have to bypass validations). If I look in mysql database I can see the record that I created from the console.
App works fine locally.
Any thoughts on what might be the problem?
Rails 2.0.2
Sounds like a validation error.
In your controller, try using save! (with the bang) to see if will throw a meaningful error.
I am not sure what code you have in the controller, but this might help show the problem
if my_object.save
log.debug 'object saved correctly'
else
log.debug my_object.errors.full_messages
end
Good luck, if this doesn't help. Try posting the relevant controller and model code.
Have you double checked that the request (with params, etc) works correctly in development?
If not, perhaps looking at the production log file will tell you where the request was routed (e.g. which controller and action, and with which parameters).
Related
I entered
SiteData.create(site_name: "My Site", url: "http://mysite.com")
in the console, SiteData being one of my models. Now I can write SiteData.find(1) and it will echo back the entry. Great!
I'm using the db table to store all the info about my site, such as the name, the url, the Facebook page, the Google Plus pages, etc. SO I need to access it on every page. Okay, I'll use before_filter in the application controller to make this work, right?
So I went into my app, and in the Application controller, I wrote
before_filter :add_site_data
def add_site_data
#site_data = SiteData.find(1)
end
And I get an error: "Couldn't find SiteData with id=1"
What now????
This might not be the best way to do this. I am brand new to rails. But I'm totally stuck and have no idea what's going on or why here. I installed Postgres locally today and set up the test and dev dbs, but it seems to be working fine since I can still create/read/update/destroy entries from the console.
Please help! I'm going nuts here. I am using Rails 4.0.
Resetting the server fixed it.
If you know you're making entries in your database that aren't reflected when you run your app, reset the server.
This is the strangest bug I've ever encountered
I am using the Best In Place gem in my Rails app in order to allow in-place editing of a page title. The in-place editing works, and the new title gets changed in the database, but when I refresh the page, it reverts back to the old title. I don't even understand where it's getting the old title from, since it's not stored in the database anymore.
When the page is created, it is automatically given the title "Untitled Page". When I change the title to say, "Title", and look at the row for the page in the DB with the postgresql admin program, it does indeed change to "Title". But when I run Page.find(1).title in the rails console, it returns "Untitled Page"
How could this be?!
Is your app running in production mode?
The PG response and console response cannot be different unless they are being executed on two different databases.
Check that your database config is using the same database as the one you are manually connecting to when browsing PG.
Ensure that when you run the rails console you specify the environment (in case your default is not what you are running on):
$ rails c production
$ rails c development
If both of the above don't help, please post the log snippet of this action. Might be that the transaction is being rolled back. If you are using .save or .update_attribute without the "!" then this won't throw an error. This is highly unlikely though, since you are saying that the database has updated data.
Fixed it. The reason was that I was using after_initialize to set the automatic properties, which gets called whenever the ActiveRecord object gets initialized. What I really wanted was after_create. I use after_create to call a function called set_properties, where I set things like self.title, and then at the end of the function, I call self.save, which is required for the properties to get saved into the DB.
I have a pretty simple Rails app and I want send an e-mail when a work request is created. I'm pretty new to Rails so I found some details on how to do it online. Set up a Mailer, configured it, etc. Set up my templates. Fine.
In my work_requests_controller.rb I have:
def create
#work_request = WorkRequest.new(params[:work_request])
respond_to do |format|
if #work_request.save
# Tell the mailer to send a welcome Email after save
PersonMailer.work_request_init_email(#work_request).deliver
format.html... etc.
In know mailing is working because if I go to the Rails console, create WorkRequest object, and use that exact same line (PersonMailer.work...) it sends the mail just fine. But when I create a work request in my application no mail is received, no error is displayed in the browser or in logs/development.log.
In the server output I see the HTML version was rendered, and I see the info about the e-mail and it all looks both hunky and dory. Since I get no errors I'm at a loss as to how to proceed.
OK, I am officially an idiot. :-)
Working on a different problem, I was editing application.rb. I figured I needed to restart the server to make it see those changes. Suddenly, the e-mails work from inside the app.
D'oh! I did not realize (rookie mistake) that I needed to restart the server for the app to see the e-mail configuration I had placed in environment.rb yesterday. I never tried that for some reason.
I see now that and other components are run only when the server starts up. So of course, when I started up console of course it runs all the initializers and so the e-mail configuration was visible to it and the e-mails were sent.
So the answer is, restart your server, stupid. Well, anyway, at least it's working now...I'll take it where I can get it!
I would start with moving your email command to your WorkRequest model as a 'after_create' action
after_create :send_init_email
def send_init_email
PersonMailer.deliver_work_request_init_email(self)
end
See if that works, or aleast gives you a better error msg.
I've added an "account" variable to a Rails app I'm running, and tested in the development environment with a mongrel server. Everything worked fine. I set my environment to production and use our Apache server, and suddenly nothing works. After a lot of debugging, I've found that the account variable is succesfullying being SET in my methods, but it's not SAVING (that is, once it gets out of the method that sets it, it's nil). I can call save or save! as many times as I want, and it's still not being set.
The attribute is accessible, and I'm not seeing any errors in the logs... It's just not saving.
Any idea what's going on?
-Jenny
Ah, I migrated to dev, but not production. I didn't think it could be the migrations, because if it were, I reasoned, I wouldn't be able to access #video.account, or whatever, because I would get a "method does not exist" error (which is what I was getting before I migrated in dev).
A bit more information to help you out on why that happened:
Check out the file db/schema.rb - it contains a Ruby representation of your database, updated on each migration. Models in Rails base their attributes on this file.
So when you migrate in development mode, the schema file is updated. When you move to production mode, that file is kept, and Rails doesn't know that the columns you are trying to assign don't exist. As such, the object you update accepts the attribute assignment, sends the query, and moves on - not noticing that the attribute didn't really save.
That's my understanding of it - hope this helps you in your quest!
Suddenly, in my first Rails app, I've started seeing this error:
/!\ FAILSAFE /!\ Fri Sep 11 17:30:48 -0400 2009
Status: 500 Internal Server Error
ActionController::Session::CookieStore::CookieOverflow
A little research points to the usage of of cookies to store session data, but I'm not doing that (at least not intentionally). Moreover, this just started happening today. The only thing I've started working on today is the ability to upload a zip file. The zip file that I'm trying to use for testing is 1.1MB.
Additionally, Firebug shows only 2 cookies for this domain. The one named _html_session is 507B and the one named user_credentials is 147B. Are uploaded files temporarily stored in such a way that a large-ish file could be causing this? Uploading a single image works just fine.
Thanks for your help.
UPDATE: Oops. Contrary to my comments to Vitaly and xijo below, the error is not quite instant. In this case I'm uploading something to my Image model and the error is happening when my ImagesController calls #image.save!.
What's interesting is that I still don't really understand where the error happens. I created an Image#before_validation method and raising an exception there, but the CookieOverflow error happens before I ever get there. Is there any place I can drop code after the controller makes the save call and before that particular callback? My understanding is that before_validation is the first callback.
This can easily happen if you try and store a flash[:notice] = 'blah' message that is too long, since that message is stored in the session cookie.
I just ran into a similar problem today. Apparently, Rails sessions can only store 4k of data. One possible solution it to use a database store for your sessions.
To do this:
Add
config.action_controller.session_store = :active_record_store to your environment.rb file.
Create a migration file for your sessions using rake db:sessions:create
Run the migration rake db:migrate
Hope this helps
the only thing that comes to mind is that you somehow did put your .zip into the session.
To debug it:
add 'require "ruby-debug"' to your environment.rb
find the place where it prints the error message and put a 'debugger' there.
run it and it will stop when it hits the 'debugger' command
examine the call stack to see if there is anything relevant.
examine the session at that point in time. see what exactly takes the space there.
no, temporarily uploaded files are usually stored in your temp folder and have nothing to do with the cookie and its size.
What do you store in your session object and perhaps it is really a good idea to start storing the session object in the database if you use it permanently.