I have a fixture with values like this:
product_four:
id: 4
application_id: 1
title: "oldtitle"
deleted_at: ~
Setting up a postgresql database for testing.
But I can't figure out how to set the deleted_at field to NULL rather than [empty].
I've tried:
deleted_at: :null
deleted_at: <%= nil %>
deleted_at: ~
deleted_at: NULL
And probably a couple more, without luck.
Clues for the clueless?
Just leave the value out:
product_four:
id: 4
application_id: 1
title: "oldtitle"
deleted_at:
For example:
> {:k => ''}.to_yaml
=> "--- \n:k: \"\"\n"
> {:k => nil}.to_yaml
=> "--- \n:k: \n"
> YAML.load({:k => nil}.to_yaml)
=> {:k=>nil}
Note that k: means that k has a nil value whereas k: "" means that k has an empty string as its value.
You could also use an explicit null if all your parsers are aware of the latest YAML spec:
product_four:
id: 4
application_id: 1
title: "oldtitle"
deleted_at: null
For example:
> YAML.load("--- \n:k: null\n")
=> {:k=>nil}
Related
I'm using 'mongo', '1.6.2' and 'mongoid', '2.4.11'.
I have ProPlayer model, When I run in console.
irb(main):006:0> ProPlayer.first
=> #<ProPlayer _id: 508a5549d3966f02e7000001, _type: nil, created_at: nil, updated_at: nil, first_name: "Adam", last_name: "Jones", batting_style: "R", image_thumbnail: "1.jpg", is_pro_player: true, team_id: BSON::ObjectId('508a550ad3966f02ce000012'), token_id: nil>
Here record with is_pro_player as true present but when I run where query, returns me zero records but actually there are 71 records present.
irb(main):008:0> ProPlayer.where(:is_pro_player=>true).to_a.size
=> 0
This query was working before but suddenly not working. Can anyone tell me what could be the problem?
Try the following:
ProPlayer.where(:is_pro_player.exists => true, is_pro_player: true).count
I had the same problem and I solved it by changing type from "Boolean" to "Mongoid::Boolean", then it will start putting boolean values in the db as "true" and "false" instead of "1" and "0" and "where" conditions will start working again
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
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
I'm testing Rails 3 beta 4 on Ruby 1.9.2-head, and when I start a
console and do:
Game.first.to_sql
I get this error:
ArgumentError: wrong number of arguments (0 for 1)
I know it can find the Game record, because when I type:
Game.first
it returns:
=> #<Game id: 1, name: "Galaga", created_at: "2010-06-19 11:02:37",
updated_at: "2010-06-19 11:02:37">
What am I missing? I just want to make the to_sql work in a very simple
case.
.
When you run Game.first you are returning a Game object, not a ActiveRecord::Relation object as you are expecting.
To do what you're trying to do, you'll need to do:
Game.limit(1).to_sql
This lets you run it without to_sql and return the object as you expected it, although it will be in an array, which then you can run .first on it like you wanted anyways.
irb(main):004:0> Game.limit(1).to_sql
=> "SELECT `games`.* FROM `games` LIMIT 1"
irb(main):005:0> Game.limit(1).class
=> ActiveRecord::Relation
irb(main):006:0> Game.limit(1)
=> [#<Game id: 1, name: "Galaga", created_at: "2010-06-19 11:02:37", updated_at: "2010-06-19 11:02:37">]
irb(main):007:0> Game.limit(1).first
=> #<Game id: 1, name: "Galaga", created_at: "2010-06-19 11:02:37", updated_at: "2010-06-19 11:02:37">
When you dig into the source, when you run .first on an ActiveRecord::Relation it runs the following (which is the same as I showed you):
def find_first
if loaded?
#records.first
else
#first ||= limit(1).to_a[0]
end
end
I really can't explain this behavior, notice how after I make a request the class' object id has changed, and therefore my is_a? evaluation returns false.
any ideas? I'm not even sure how to debug this. Also, this isn't related to making a request from the command line. The same behavior is exhibited on the web server as well, it's just easier to explain from the command line.
staging$ RAILS_ENV=staging script/console
Loading staging environment (Rails 2.3.2)
>> c = CartItem.new
=> #<CartItem id: nil, order_id: nil, order_source: nil, date: nil, user_id: nil, created_at: nil, updated_at: nil, paid: nil, payment_id: nil, values: nil, cart_description: nil, type: nil, price: nil, email: nil, error: nil>
>> c.class.object_id
=> 70151495336400
>> CartItem.object_id
=> 70151495336400
>> c.is_a? CartItem
=> true
>> app = ActionController::Integration::Session.new
=> #<ActionController::Integration::Session:0x7f9ad5c55db0 .... >
>> app.get("site/favorite")
=> 200
>> c.class.object_id
=> 70151495336400
>> CartItem.object_id
=> 70151496019760
>> c.is_a? CartItem
=> false
>> c.class
=> CartItem(id: integer, order_id: string, order_source: string, date: date, user_id: integer, created_at: datetime, updated_at: datetime, paid: boolean, payment_id: integer, values: text, cart_description: string, type: string, price: integer, email: string, error: string)
Every new context (request/response cycle) will regenerate the object IDs. You may want to use responds_to?, instead of is_a?.
Since the ActionController::Integration module is used for integration testing, getting a url reloads your classes, therefore redefining the CartItem identifier. You now basically have two CartItem classes, one hanging around on your stack without an identifier pointing to it anymore (the "old one") and one referenced by the CartItem identifier.