I have a normal class (Event) where a boolean value is defined as
attr_accessible :archived
and in the db schema is
t.boolean "archived", :default => false
As such, the default method archived? is automatically defined.
After a debugging session I discovered this
>> a=Event.last
>> a.archived
false
>> a.archived=true
true
>> a.archived
true
>> a.archived?
false
Should't the last two values BOTH be true? What am I missing here?
Even this is not helping:
>> a.save
(0.1ms) begin transaction
(45.2ms) UPDATE "events" SET "archived" = 't', "updated_at" = '2012-12-10 06:31:57.410990' WHERE "events"."id" = 3
true
(149.5ms) commit transaction
>> a.archived?
false
Thank you in advance
Related
I have been using a state object in the database that keeps track of what seed data has been loaded into it. The structure of the table is:
create_table "toolkit_states", force: :cascade do |t|
t.boolean "signups", default: true
t.decimal "database_version", precision: 5, scale: 2
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
end
The seeds.rb file checks the database_version and runs blocks of code and then sets the database_version after running the block. It has worked fine from versions 0.1 up to 0.55.
I added a new block of seed data. To run that block the database_version is checked and it should be 0.56. The following comparison does not work:
if state.database_version == 0.56
For some reason, the number 0.56 cannot be evaluated for equality with the value stored in the database. It has worked on all the values up to 0.56.
Here is a rails console session:
irb(main):001:0> state = ToolkitState.first
ToolkitState Load (0.4ms) SELECT "toolkit_states".* FROM "toolkit_states" ORDER BY "toolkit_states"."id" ASC LIMIT $1 [["LIMIT", 1]]
=> #<ToolkitState id: 1, signups: false, database_version: 0.56e0, created_at: "2018-12-27 17:04:50", updated_at: "2018-12-27 17:04:56">
irb(main):002:0> state.database_version == 0.56
=> false
irb(main):003:0> state.database_version == 0.56e0
=> false
irb(main):004:0> state.database_version == 0.56.to_f
=> false
irb(main):005:0> state.database_version.to_f == 0.56
=> true
When I convert the value with a "to_f", the comparison works. My problem is that it as worked well without this conversion up to the value, 0.56
It occurs because state.database_version is an instance of BigDecimal class. This article explain why it is BigDecimal.
Look at this example:
BigDecimal('0.56e0')
=> 0.56e0
irb(main):008:0> BigDecimal('0.56e0') == 0.56
=> false
irb(main):009:0> BigDecimal('0.56e0').to_f
=> 0.56
As you can see 0.56e0 after transformation to float type becomes 0.56 and your comparison returns true.
Nate explained more briefly why it's happening in this comment.
irb(main):001:0> c = BigDecimal('0.56e0')
=> 0.56e0
irb(main):002:0> c == 0.56
=> false
irb(main):003:0> c = BigDecimal('0.55e0')
=> 0.55e0
irb(main):004:0> c == 0.55
=> true
Works for 0.55 and not for 0.56 Rails bug?
Failure/Error: #group.attributes.keys.should include (Group.first.attributes.keys)
expected
["id", "duration", "frequency", "period", "group_size", "location", "service", "area_of_need", "created_at", "updated_at", "therapist_id", "start_date", "end_date", "student_id", "adhoc"]
to include
["id", "duration", "frequency", "period", "group_size", "location", "service", "area_of_need", "created_at", "updated_at", "therapist_id", "start_date", "end_date", "student_id", "adhoc"]
Test:
#group.attributes.keys.should include (Group.first.attributes.keys)
Because a.should includes(b) asserts that a.include? b is true andinclude? checks to see if an array's elements includes an object, not whether one array equals another
[1].include? [1]
=> false
[1].include? 1
=> true
[[1]].include? [1]
=> true
Te answer was that the hash comparison fails on Ubuntu but works on Mac's.
My workaround is:
i=0
while i < #group.attributes.count
assert_equal #group.attributes[i], Group.first.attributes[i]
i+= 1
end
# Comparing field by field as ruby hash comparison isn't working right -
# but only on Ubuntu!
I want to create new record in spree_products_taxons table with ActiveRecord (not with pure SQL), but:
1.9.3-head :003 > Spree::ProductsTaxon.create(product_id: 666, taxon_id: 777)
NameError: uninitialized constant Spree::ProductsTaxon
Where am i wrong?
ps. In my schema file:
create_table "spree_products_taxons", :id => false, :force => true do |t|
t.integer "product_id"
t.integer "taxon_id"
end
You can try something like this
product = Spree::Product.find(666)
taxon = Spree::Taxon.find(777)
product.taxons << taxon
product.save
taxons = product.taxons
I have a binary column which contains 256-bit checksums. I can store the checksums ok, but when I try to query via the checksum, nothing is returned.
d = Digest::SHA2.new
d.update "large str i'm creating the hash with"
begin
codebase = Codebase.find_or_create_by_checksum(d.digest)
rescue ActiveRecord::StatementInvalid => e
# handle duplicate record error
end
I've tried where and different versions of find. Nothing returns. When I use find_or_create_by_checksum, since it doesn't find anything it tries to create it and an exception is raised since I have a uniq index on the checksum column, but still I need to be able to get the record with the matching checksum.
create_table :codebases do |t|
t.binary :checksum, :null => false, :limit => 32
end
add_index :codebases, :checksum, :unique => true, :name => 'name_of_the_codebas_uniq_index'
Anybody know how to do this?
So if its binary on the database, I couldn't reproduce:
migration:
class Checksum < ActiveRecord::Migration
def up
create_table :checksums do |t|
t.binary :checksum, :null => false, :limit => 32
end
end
def down
end
end
And then trying it on the rails console:
ruby-1.9.2-p290 :009 > Checksum.create(:checksum => digest.digest)
SQL (0.4ms) INSERT INTO "checksums" ("checksum") VALUES (?) [["checksum", ",&\xB4kh\xFF\xC6\x8F\xF9\x9BE<\x1D0A4\x13B-pd\x83\xBF\xA0\xF9\x8A^\x88bf\xE7\xAE"]]
=> #<Checksum id: 1, checksum: ",&\xB4kh\xFF\xC6\x8F\xF9\x9BE<\x1D0A4\x13B-pd\x83\xBF\xA0\xF9\x8A^\x88bf\xE7\xAE">
ruby-1.9.2-p290 :010 > Checksum.first
Checksum Load (0.2ms) SELECT "checksums".* FROM "checksums" LIMIT 1
=> #<Checksum id: 1, checksum: ",&\xB4kh\xFF\xC6\x8F\xF9\x9BE<\x1D0A4\x13B-pd\x83\xBF\xA0\xF9\x8A^\x88bf\xE7\xAE">
ruby-1.9.2-p290 :011 > Checksum.find_by_checksum(digest.digest)
Checksum Load (0.1ms) SELECT "checksums".* FROM "checksums" WHERE "checksums"."checksum" = x'2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae' LIMIT 1
=> #<Checksum id: 1, checksum: ",&\xB4kh\xFF\xC6\x8F\xF9\x9BE<\x1D0A4\x13B-pd\x83\xBF\xA0\xF9\x8A^\x88bf\xE7\xAE">
So it works as expected.....
We're on mongodb 2.0.0, mongo gem 1.4.1, mongo_mapper 0.9.2, rails 3.0.6.
We love MongoMapper, but we need helping resolving one nasty issue: we have a key carried over from some testing, but invoking obj.unset fails to do anything.
Specifically, we are trying to remove an "id" key (not "_id") because it's causing MM to treat obj.id as different from obj._id, which we don't want.
After clearing out the database, we ran these commands from a controller which does nothing else: (We also tried running the same code from the rails console, but it also fails.)
logger.info "#{Game.keys.keys.inspect}"
Game.unset({}, :id)
logger.info "#{Game.keys.keys.inspect}"
Game.unset(:id)
logger.info "#{Game.keys.keys.inspect}"
Output:
["jackpot", "players", "created_at", "puzzles", "ended_at", "player_index", "updated_at", "log", "_id", "id", "join_code", "puzzle_index"]
["jackpot", "players", "created_at", "puzzles", "ended_at", "player_index", "updated_at", "log", "_id", "id", "join_code", "puzzle_index"]
["jackpot", "players", "created_at", "puzzles", "ended_at", "player_index", "updated_at", "log", "_id", "id", "join_code", "puzzle_index"]
Current keys defined in our Game model:
key :players, Array, :default => []
key :player_index, Integer, :default => 0
key :puzzles, Array, :default => []
key :puzzle_index, Integer, :default => 0
key :join_code, String, :default => nil
key :jackpot, Integer, :default => 0
key :log, Array, :default => []
key :created_at, Time
key :updated_at, Time
key :ended_at, Time, :default => nil
Help?
Thanks!
It pains us to post the answer since this solidifies our status as "morons, idiots, fools, noobs, Jay Leno fans," but in case anyone else bumps into the same issue: while our model directory was clean in the dev environment, the model dir in the production environment contained old test files ... which contained an old model with the "id" key.
Obviously, removing the old files and the old models solved everything, though we're left with staggering bruises to our egos and to our heads (from excessive banging against the walls).