Set date in text_field rails 3.2.1 - ruby-on-rails

I have just upgraded to rails 3.2.1.
I use the jQuery UI datepicker to set dates in rails text_fields. The field sets a date column in the database.
But, now it does not work.
I have this code in the view.
<%= p.text_field :due, :value => Time.now.strftime("%m/%d/%Y"), :id => "dialog_project_date" %>
If I don't change the date all goes well. If I change the date Rails puts nil in the database. This also happens when I disable jQuery datepicker and enter the date (with the right format) manually.
It seems to me that there is something with the way rails handles the formatting of the date field.
I can't find a solution. Does anybody have an idea?
Update
I used the debugger in the create action. Here's the otuput
(rdb:22) params
{"utf8"=>"✓", "authenticity_token"=>"4IChBeyKzkc4dwzje1RMPy2GBTMs5m2zrBPBFbIIKJw=", "project"=>{"name"=>"gunnaer", "description"=>"", "due"=>"03/17/2012", "customer_id"=>""}, "commit"=>"Save", "controller"=>"projects", "action"=>"create_index"}
(rdb:22) #project
#<Project id: nil, name: "gunnaer", description: "", due: nil, active: true, budget: nil, hour_price: nil, firm_id: 1, customer_id: nil, created_at: nil, updated_at: nil>
(rdb:22) #project.due = "03/17/2012"
"03/17/2012"
(rdb:22) #project
#<Project id: nil, name: "gunnaer", description: "", due: nil, active: true, budget: nil, hour_price: nil, firm_id: 1, customer_id: nil, created_at: nil, updated_at: nil>
The params is right, but the due param does not get set to the instans variable. The format is the same when I do not change the date. When I do not change it, it works.
Strange..

Your date format is wrong. Try using "yyyy/mm/dd"
This works:
ruby-1.9.2-p290 :002 > b = Blog.first
=> #<Blog id: 1, title: "Something", created_at: "2012-03-09 13:38:23", updated_at: "2012-03-09 13:38:32">
ruby-1.9.2-p290 :003 > b.created_at
=> Fri, 09 Mar 2012 13:38:23 UTC +00:00
ruby-1.9.2-p290 :004 > b.created_at = "2012/03/17"
=> "2012/03/17"
ruby-1.9.2-p290 :005 > b.save
=> true
ruby-1.9.2-p290 :006 > Blog.first
=> #<Blog id: 1, title: "Something", created_at: "2012-03-17 00:00:00", updated_at: "2012-03-09 13:58:55">
This does not:
ruby-1.9.2-p290 :007 > b.created_at = "03/17/2012"
=> "03/17/2012"
ruby-1.9.2-p290 :008 > b.save
=> true
ruby-1.9.2-p290 :009 > Blog.first
=> #<Blog id: 1, title: "Something", created_at: nil, updated_at: "2012-03-09 13:59:22">
EDIT
You have a few options for date format, which you should specify in your jquery ui code. See this link for examples - http://jqueryui.com/demos/datepicker/date-formats.html

To debug, first see what values are being POSTed to your controller. Either check the log or use a debugging proxy such as fiddle.
Then use the Rails console to isolate where the problem is happening.
UPDATED
The problem is that latest ver of Ruby (not Rails) assumes European date formats. A work-around to still use US format

Related

How to show values of a instance with line break in Rails console

I start to using pry in a rails console.
When I get a instance of a Rails model, the values are shown without line breaks like this:
pry(#<Class:0x1022f60e0>):1> first
=> #<Article id: 1, name: "What is Music", content: "Music is an art form in which the medium is sound o...", created_at: "2011-08-24 20:35:29", updated_at: "2011-08-24 20:37:22", published_at: "2011-05-13 23:00:00">
from http://railscasts.com/episodes/280-pry-with-rails?view=asciicast
Is there way to show the values with line breaks like this?
Article
id: 1
name: "What is Music"
content: "Music is an art form in which the medium is sound o..."
created_at: "2011-08-24 20:35:29"
updated_at: "2011-08-24 20:37:22"
published_at: "2011-05-13 23:00:00"
You could call .to_yaml on the model instance! It returns a string that's formatted almost exactly like you're requesting it to be.
Here are some examples of to_yaml output:
http://yaml4r.sourceforge.net/doc/page/examples.htm
I would recommend that you install awesome_print.
Add it to your Gemfile:
group :development do
gem 'awesome_print'
end
And install it with bundle install.
Now use ap to print it in the console:
pry(#<Class:0x1022f60e0>):1> ap first
#<Article:0x1022f60e0> {
:id => 1,
:name => "What is Music"
:content => "Music is an art form in which the medium is sound o..."
:created_at => "2011-08-24 20:35:29"
:updated_at => "2011-08-24 20:37:22"
:published_at => "2011-05-13 23:00:00"
}
I think, the below trick will work for you.
arup#linux-wzza:~/Rails/model_prac> rails c
Loading development environment (Rails 4.1.4)
2.1.2 :001 > Comment.first
Comment Load (0.4ms) SELECT "comments".* FROM "comments" ORDER BY "comments"."id" ASC LIMIT 1
=> #<Comment id: 1, value_old: "I am a good Boy.", value_new: "I am a bad Boy.", created_at: "2014-08-02 17:36:14", updated_at: "2014-08-02 18:21:42">
2.1.2 :002 > y Comment.first
Comment Load (0.4ms) SELECT "comments".* FROM "comments" ORDER BY "comments"."id" ASC LIMIT 1
--- !ruby/object:Comment
attributes:
id: 1
value_old: I am a good Boy.
value_new: I am a bad Boy.
created_at: 2014-08-02 17:36:14.249466000 Z
updated_at: 2014-08-02 18:21:42.511522000 Z
=> nil
2.1.2 :003 >

Rails new objects are nil

I'm playing with rails again and found this behavior, when i create a new instance of a Post model with some attributes it tells me that all attributes are nil, why it is happening?
Loading development environment (Rails 4.0.0)
2.0.0-p451 :001 > a = Post.new(title: "Rails", content: "Rails Post")
=> #<Post id: nil, title: nil, content: nil, author: nil, rating: nil, created_at: nil, updated_at: nil>
2.0.0-p451 :002 > a.title
=> "Rails"
2.0.0-p451 :004 > a.content
=> "Rails Post"
2.0.0-p451 :005 > a.inspect
=> "#<Post id: nil, title: nil, content: nil, author: nil, rating: nil, created_at: nil, updated_at: nil>"
2.0.0-p451 :006 > a.errors.messages
=> {}
2.0.0-p451 :007 > a.valid?
=> true
class Post < ActiveRecord::Base
attr_accessor :title, :content, :author, :rating
end
You are defining attr_accessor for all your properties, which is a shortcut for defining getters and setters for an instance variable of the same name like so:
def content
#content
end
def content=(new_content)
#content = new_content
end
Rails will also auto-generate you methods with these names, for every database field that your model has. These methods will conflict with each other.
When you call post.content = 'foo', instead of calling the Rails-generated method that will internally set your model's content attribute to 'foo', you're calling the attr_accessor-defined method which will set the instance variable #content to 'foo'.
The output of inspect is iterating over the Rails-defined model attributes, not the instance variables.
Did you actually mean to declare these attributes as attr_accessible instead of attr_accessor?

Why can't I destroy this variable in Ruby?

In the rails console, I do this:
input = Input.create :name => "foo"
=> #<Input id: 8, name: "foo", created_at: "2013-05-07 11:45:17", updated_at: "2013-05-07 11:45:17">
Input.all
=> [#<Input id: 8, name: "foo", created_at: "2013-05-07 11:45:17", updated_at: "2013-05-07 11:45:17">]
input
=> #<Input id: 8, name: "foo", created_at: "2013-05-07 11:45:17", updated_at: "2013-05-07 11:45:17">
input.destroy
=> #<Input id: 8, name: "foo", created_at: "2013-05-07 11:45:17", updated_at: "2013-05-07 11:45:17">
> Input.all
=> []
> input
=> #<Input id: 8, name: "foo", created_at: "2013-05-07 11:45:17", updated_at: "2013-05-07 11:45:17">
> input.reload
ActiveRecord::RecordNotFound: Couldn't find Input with id=8
> input
=> #<Input id: 8, name: "foo", created_at: "2013-05-07 11:45:17", updated_at: "2013-05-07 11:45:17">
What I'd really expect to see is something like:
> input
=> nil
The object is deleted from the database but the variable still exists and is still trying to point to it. What's going on?
The input variable stores a reference to the instance in memory. Destroying the record will remove the row from the database. Calling input.reload (docs) raises an exception when attempting to find the record but doesn't set the value of your variable to nil on your behalf.
This behavior can be useful in the span of a DELETE request in which you want to display information about the object you removed. For example:
class WidgetsController < ApplicationController
def destroy
#widget = Widget.find(params[:id])
#widget.destroy
respond_with #widget, notice: "You successfully removed #{#widget.name}"
end
end
The destroy method makes the SQL call to the database and destroys the row in the table that contains it. It does still allow you to manipulate the object in the application as long as it’s still in scope (i.e) the callbacks and
filters are allowed even after destroying the object.
It is better to use "delete" if we don't want the callbacks to be triggered or if we want better performance
you can use input.delete

time type field getting bad default datetime if it is invalid

Terrible title, but this is what I have:
Loading development environment (Rails 3.2.8)
1.9.3p194 :001 > Product
=> Product(id: integer, name: string, date: datetime, created_at: datetime, updated_at: datetime, end_time: datetime, start_time: time)
1.9.3p194 :002 > p = Product.new
=> #<Product id: nil, name: nil, date: nil, created_at: nil, updated_at: nil, end_time: nil, start_time: nil>
1.9.3p194 :003 > p.start_time = "foo"
=> "foo"
1.9.3p194 :004 > p.start_time
=> 2000-01-01 00:00:00 UTC
I wouldn't expect an invalid time to parse into a valid one. This is causing me issues with validations from form submissions.
This is somewhat related: Rails 3 - Validation for Time existence
And leads to this issue in github: https://github.com/rails/rails/issues/6045
I tried eye tracing the code, but nothing pops out at me except that the "foo" shouldn't parse and it should return nil.
EDIT: I created a sample app that displays this exact behavior https://github.com/danbeaulieu/test-app
But really it's just a bare bones app with a single model.
You can use validates_timeliness which validates dates, times and datetimes .
Then in your model you can do
validates_time :start_time
OR have a look at my GIST to handle default date validation

Rails ActiveRecord :counter_cache not updated if assocation not set up before create. Intentional?

I've implemented a belongs_to relation with :counter_cache => true and I notice that the counter cache does not get updated if the relation was not set up before the initial save.
For instance, say a company has_many employees. If I do
company.employees << Employee.new(:name => "Joe")
The counter gets updated correctly but if I do
company.employees << Employee.create(:name => "Joe")
The counter remains unchanged.
For more details, here are the models:
class Employee < ActiveRecord::Base
belongs_to :company, :counter_cache => true
end
class Company < ActiveRecord::Base
has_many :employees
end
And here's a Rails Console session that demonstrates this:
Loading development environment (Rails 3.0.5)
ruby-1.9.2-p180 :001 > company_a = Company.create(:name => "ACME")
=> #<Company id: 1, name: "ACME", created_at: "2011-07-22 01:31:39", updated_at: "2011-07-22 01:31:39", employees_count: 0>
ruby-1.9.2-p180 :002 > company_a.employees << Employee.new(:name => "Bob")
=> [#<Employee id: 1, company_id: 1, name: "Bob", created_at: "2011-07-22 01:31:59", updated_at: "2011-07-22 01:31:59">]
ruby-1.9.2-p180 :003 > company_a.reload
=> #<Company id: 1, name: "ACME", created_at: "2011-07-22 01:31:39", updated_at: "2011-07-22 01:31:39", employees_count: 1>
ruby-1.9.2-p180 :004 > company_a.employees << Employee.create(:name => "Joe")
=> [#<Employee id: 1, company_id: 1, name: "Bob", created_at: "2011-07-22 01:31:59", updated_at: "2011-07-22 01:31:59">, #<Employee id: 2, company_id: 1, name: "Joe", created_at: "2011-07-22 01:32:28", updated_at: "2011-07-22 01:32:28">]
ruby-1.9.2-p180 :005 > company_a.reload
=> #<Company id: 1, name: "ACME", created_at: "2011-07-22 01:31:39", updated_at: "2011-07-22 01:31:39", employees_count: 1>
The documentation does say that the counter is incremented/decremented when the object is created/destroyed but I was thinking it should monitor updates as well to be useful. Otherwise, say, moving employees between companies would quickly result in counters that are totally off.
Is this the expected behavior? If so, what's the rationale? And if not, am I doing something wrong? I tried this in Rails 3.0.5 and Ruby 1.9.2
Thanks!

Resources