I'm trying to get an understanding about the inner features of Active Record playing with IRB.
I have a small database with a few tables which I created using SQL. Then I connected Active Record to that database using a Ruby script. I already loaded the models, which are classes with the tables' names singularized, and made all attributes accessible via attr_accessor but I only get the id and the rest return nil when trying to get them. Any clue?
I have the table "empresas" with four records and the class Empresa:
2.2.1 :001 > load 'config.db'
=> true
2.2.1 :002 > e = Empresa.all
=> #<ActiveRecord::Relation [#<Empresa id: 1, razon_social: "Holbrook Co.", cuit: "33-22564787-4", domicilio: "San Lorenzo 336", localidad_id: 7>, #<Empresa id: 2, razon_social: "Marshfield Llc.", cuit: "30-13547542-0", domicilio: "Av. de Mayo 110", localidad_id: 2>, #<Empresa id: 3, razon_social: "Iron Cobra Inc.", cuit: "30-24652120-8", domicilio: "9 de Julio 332", localidad_id: 20>, #<Empresa id: 4, razon_social: "Apple Inc.", cuit: "30-43753246-4", domicilio: "Riverside Road 342", localidad_id: 4>]>
2.2.1 :003 > e[2]
=> #<Empresa id: 3, razon_social: "Iron Cobra Inc.", cuit: "30-24652120-8", domicilio: "9 de Julio 332", localidad_id: 20>
2.2.1 :004 > e[2].id
=> 3
2.2.1 :005 > e[2].razon_social
=> nil
2.2.1 :006 > e[2].cuit
=> nil
The model looks like this:
class Empresa < ActiveRecord::Base
belongs_to :localidad
attr_accessor :razon_social, :cuit, :domicilio, :localidad_id
end
This model is required in the script that makes the connection to the database, along with active_record and fb (I'm using firebird for the database).
ActiveRecord will automatically create accessors for columns in your database tables.
When you define accessors with attr_accessor, you override those accessors.
Try removing that call to attr_accessor, then your calls should go on to the database values!
Related
I have these models
class Version
has_many :bids
end
class Bid
belongs_to :version
end
in the console:
> bid = Bid.first
which returns
> #<Bid id: 8 version_id: 5, deleted_at: nil, created_at: "2018-09-06 00:32:32", updated_at: "2018-09-06 00:32:32", created_by_id: 3, updated_by_id: 3, selected: true>
but if i try to call the version it returns nil. the version is there though
> bid.version
> nil
> Version.find(bid.version_id)
> #<Version id: 5, effective_date: "2018-09-05 23:36:24", end_date: nil, created_at: "2018-09-05 23:36:24", updated_at: "2018-09-05 23:36:24", created_by_id: nil>
what is going on? what could I be doing wrong?
So it turns out that object.version is an existing rails method. if i change the relationship to belongs_to :pricing_version the code works.
Anyone with this issue in the future just avoid naming their class Version
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 >
Following up on this 1 year old post:
Mongodb mongoid model attributes sorted by alphabetical order not insertion order
I have a rails 3.2.8 application that uses mongoid v. 3.0.0. My application occasionally uses the "update_attribute" function on a database object (e.g. a product), but when it does all attributes gets reordered alphabetically.
When I duplicate this in the console, it looks like this:
1.9.3-p385 :001 > product = Product.find("5156bc9b83c3368121000008")
=> [#<Product _id: 5156bc9b83c3368121000008, _type: nil, product_number: "123", product_name: "Some product name", long_description: "<P>Some long product description.</P>", vendor_number: "abc", language_i_d: "1234", currency_i_d: "USD", category_number: "1", image_link: "http://some-external-website.com/image-path.jpg", original_id: "123456">]
1.9.3-p385 :002 > product.update_attribute(:image_link, "http://my-own-website.com/image-path.jpg")
=> true
1.9.3-p385 :003 > exit
I now fire up the console again (for some reason I need to exit and re-open the console before the new order is displayed):
1.9.3-p385 :001 > product = Product.find("5156bc9b83c3368121000008")
=> [#<Product _id: 5156bc9b83c3368121000008, _type: nil, category_number: "1", currency_i_d: "USD", image_link: "http://my-own-website.com/image-path.jpg", language_i_d: "1234", long_description: "<P>Some long product description.</P>", original_id: "123456", product_name: "Some product name", product_number: "123", vendor_number: "abc">]
Does anyone know how to avoid this reordering?
This isn't mongoid's fault. If an update causes a document to grow and mongo had to move the document as a result then mongodb itself may reorder the document's fields (see docs and a jira issue where this is described as normal)
I don't expect a model with NULL as foreign key to belong to anything!
I have the following rails app, modelling ants and ant hills (inspired by Jozef).
$ rails -v
Rails 3.2.8
$ rails new ant_hill
$ cd ant_hill
Create the ant hill and ant models. An ant can belong to an ant hill and an ant hill can have many ants.
$ rails generate model AntHill name:string
$ rails generate model Ant name:string ant_hill_id:integer
$ vim app/models/ant.rb
$ cat app/models/ant.rb
class Ant < ActiveRecord::Base
belongs_to :ant_hill
end
$ vim app/models/ant_hill.rb
$ cat app/models/ant_hill.rb
class AntHill < ActiveRecord::Base
has_many :ants
end
$ rake db:migrate
== CreateAntHills: migrating =================================================
-- create_table(:ant_hills)
-> 0.0013s
== CreateAntHills: migrated (0.0016s) ========================================
== CreateAnts: migrating =====================================================
-- create_table(:ants)
-> 0.0035s
== CreateAnts: migrated (0.0037s) ============================================
Run the following code in a console.
$ rails c
Loading development environment (Rails 3.2.8)
Create a couple of ants, persisted, that don't belong to any ant hill.
1.9.2-p290 :001 > Ant.create! name: "August"
=> #<Ant id: 1, name: "August", ant_hill_id: nil, created_at: "2012-09-27 12:01:06", updated_at: "2012-09-27 12:01:06">
1.9.2-p290 :002 > Ant.create! name: "Bertil"
=> #<Ant id: 2, name: "Bertil", ant_hill_id: nil, created_at: "2012-09-27 12:01:13", updated_at: "2012-09-27 12:01:13">
Now instantiate an ant hill, but don't save it just yet.
1.9.2-p290 :003 > ant_hill = AntHill.new name: "Storkullen"
=> #<AntHill id: nil, name: "Storkullen", created_at: nil, updated_at: nil>
I expect this ant hill to not have any ants and it doesn't.
1.9.2-p290 :004 > ant_hill.ants
=> []
I still expect the ant hill to not have any ants but now it has two.
1.9.2-p290 :005 > ant_hill.ants.count
(0.1ms) SELECT COUNT(*) FROM "ants" WHERE "ants"."ant_hill_id" IS NULL
=> 2
Same here, it should never generate a query containing "IS NULL" when dealing with foreign keys. I mean "belongs_to NULL" can't belong to anything, right?
1.9.2-p290 :006 > ant_hill.ants.all
Ant Load (0.4ms) SELECT "ants".* FROM "ants" WHERE "ants"."ant_hill_id" IS NULL
=> [#<Ant id: 1, name: "August", ant_hill_id: nil, created_at: "2012-09-27 12:01:06", updated_at: "2012-09-27 12:01:06">, #<Ant id: 2, name: "Bertil", ant_hill_id: nil, created_at: "2012-09-27 12:01:13", updated_at: "2012-09-27 12:01:13">]
After it is persisted it behaves as expected.
1.9.2-p290 :007 > ant_hill.save!
=> true
1.9.2-p290 :008 > ant_hill.ants.count
(0.4ms) SELECT COUNT(*) FROM "ants" WHERE "ants"."ant_hill_id" = 1
=> 0
1.9.2-p290 :009 > ant_hill.ants.all
Ant Load (0.4ms) SELECT "ants".* FROM "ants" WHERE "ants"."ant_hill_id" = 1
=> []
Any insight? Is this the expected behavior?
While it seems counterintuitive, I think this behavior makes sense given your examples. Take ant_hill.ants.count for example. Count is an ActiveRecord query method that hits the database, and you're essentially asking ActiveRecord to give you all the ants that do not belong to an ant hill. Rails is simply letting you do something you should not be able to do, and not complaining about it. Should this be raising an exception instead? Possibly.
If you really want to know how many ants belong to this ant_hill object, you should be using size. It queries the object when not persisted or when the association is already loaded, and queries the database otherwise.
ant_hill.ants.size
One way you can get around this oddity is to make ant_hill_id a required field by validating its presence.
TL;DR Avoid using ActiveRecord query interface if parent object is not persisted to database.
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!