Questions about ActiveRecord aggregation


#1

Hi all,

I’m quite new to rails. These may be silly questions, but I really
need your advice.

According to <>, composite objects
in aggregation are value objects, which means their values cannot be
changed. So if say Person is the model class and Address is the
composite class, the way to update a person’s address is to create a
new Address object, assign it to the person and then save. This works
fine with small composite object with just a few properties. If the
composite object has many properties, I think this will a performance
problem.

Now in my project, I get a table with about 50-60 columns. I want to
divide it into several parts using aggregation. The problem is that,
one of these composite objects will have 20 columns and another with
10 columns. I’m wondering if this will cause a performance problem
since each time even only one of the composite object’s properties
needs to be updated, the whole 20 columns or so will be updated
together. Is there a way to avoid this? Or this is just the way rails
work?

I was thinking about split this big table into several small ones, but
this doesn’t seem to be reasonable in a OO perspective. Do I have to
split the table in order to hold performance or is there better way?

Aonther question is about multi-layer aggregation, say I want to model
a table into A, B, C there classes and use a a.b.c relationship. Is
this possible?

Thanks a lot.


#2

allen wrote:

Hi all,

Aonther question is about multi-layer aggregation, say I want to model
a table into A, B, C there classes and use a a.b.c relationship. Is
this possible?

Thanks a lot.

Yes,

Take a look here:

http://api.rubyonrails.org/classes/ActiveRecord/Associations/ClassMethods.html#M000530


#3

On 4/6/07, allen removed_email_address@domain.invalid wrote:

Hi all,

I’m quite new to rails. These may be silly questions, but I really
need your advice.

Not silly. Just inexperienced.

According to <>, composite objects

in aggregation are value objects, which means their values cannot be
changed. So if say Person is the model class and Address is the
composite class, the way to update a person’s address is to create a
new Address object, assign it to the person and then save.

Not the case, in actuality.
You can do
person.address.zipcode = ‘63201’
person.address.save
or (since you said aggregation),
address1 = person.addresses[0]
address1.zipcode = ‘63201’
address1.save

This works

together. Is there a way to avoid this? Or this is just the way rails
work?

If you only need to update one column, you can use lines such as:
person.address.update_attribute(“zipcode”, “63102”)

I was thinking about split this big table into several small ones, but

this doesn’t seem to be reasonable in a OO perspective. Do I have to
split the table in order to hold performance or is there better way?

Aonther question is about multi-layer aggregation, say I want to model
a table into A, B, C there classes and use a a.b.c relationship. Is
this possible?

Absolutely, as the other poster said. It is a standard practice in
Rails.

Thanks a lot.

You’re welcome :slight_smile:


#4

Thanks for your patient explanation. Where can I get a close look to
all this rails API besides the online document on the offical web
site. Is there a downlaodable version? Since I cannot stay online all
the time.

Another question: Say I want to create a composite class with 20
properties, must I create the initialize method using all these
properties? This is boring and easy-mistaken. Is there a better way to
do this?


#5

Thanks, man. This really helps a lot.

On 4ÔÂ7ÈÕ, ÉÏÎç3ʱ08·Ö, Jamal S. removed_email_address@domain.invalid


#6

Thanks for your reply, but I don’t quite get it for the second
question. What do you mean by “put them all in hash” and
“instance[hash]”?

On Apr 8, 1:24 am, Jamal S. removed_email_address@domain.invalid


#7

If you only need to update one column, you can use lines such as:
person.address.update_attribute(“zipcode”, “63102”)

just want to clear this up. update_attribute() does not just update a
single column in the database. it updates the single attribute in the
model then saves the record…

same as doing

model.some_attribute = ‘foo’
model.save


#8

allen wrote:

Thanks for your patient explanation. Where can I get a close look to
all this rails API besides the online document on the offical web
site. Is there a downlaodable version? Since I cannot stay online all
the time.

One way

  1. Download Rails sources (svn export
    http://dev.rubyonrails.org/svn/rails/trunk target_dir)
  2. cd target_dir/railties
  3. rake
  4. This gives you a target_dir/rails/doc/api/index.html, containing the
    complete Rails API docs.

Source: http://article.gmane.org/gmane.comp.lang.ruby.rails/6047
Google:
http://www.google.dk/search?q=download+rubyonrails+doc&btnG=Søg&hl=da
Keyword: download rubyonrails doc

Another question: Say I want to create a composite class with 20
properties, must I create the initialize method using all these
properties? This is boring and easy-mistaken. Is there a better way to
do this?

It will be easier for you to put them all in hash

instance[hash]


#9

On 4/9/07, Chris H. removed_email_address@domain.invalid wrote:

same as doing

model.some_attribute = ‘foo’
model.save

And, a further clarification… it is actually the same as
model.some_attribute = ‘foo’
model.save(false)
update_attribute does not perform validation
update_attributes does perform validation.