I have a model (Parent) that has a has_many association with another
model (Child). I read that there are performance issues (relating to
GC) with too many associations. I was about to add more has_many
associations to the parent model to get child objects ordered by
different columns like so:
Is this going to make ruby hold on to this parent object and 4 child
object and use up a lot of memory? (Does the parent model get all the
child records child, child1, child2 and child3 as soon as Parent.find
is called? Or are they only really queried when I access, say,
parent.child1?)
Is it better to just do a Child.find with the parent_id inside the
controller? Or would it use up as much memory as soon as I do
Child.find?
I have a model (Parent) that has a has_many association with another
model (Child). I read that there are performance issues (relating to
GC) with too many associations. I was about to add more has_many
associations to the parent model to get child objects ordered by
different columns like so:
This design cries out for refactoring... as soon as I see something1,
something2, something3 when the series is essentially infinite (though I
wouldn't want to feed or clothe them all), alarm bells start ringing.
Consider a 'relations' model that takes a person id, a different person
id, and a relation (child, parent, grandparent, spouse, ex-spouse, etc,
etc), which maintains that "person1 is a relation of person2".
Extra points if you implement the relation model in a bi-directional
order (each relation needs to know its inverse), whereby creating the
tuple 'person1, parent, person2' automatically creates 'person2, child,
person1'.
Thanks, Ar Chron - I'm afraid I don't really understand what you're
suggesting that I do. (sorry..) I already have a cross-reference
table (childx) between the parent and the child that connects them.
In my model, parent has many child, but child can have only one
parent.
The only reason I am defining the child, child1, child2 and child3
inside the parent model is to get a list of child records that belongs
to a parent sorted by different columns in the child table. (I
thought it was an easy and efficient way to get at the record .. :-\
but maybe this is not a good idea?) And my question was if this is
better or worse memory-wise than doing something like this:
# method defined in the Child model
Child.find_by_parent_id(some_parent_id, sort_order)
inside the controller each time I needed a child record pulled sorted
by a different column. (So no child, child1, child2 or child3 defined
in Parent.)
Thanks again - I'll try to read more to understand this. Maybe it'll
lead to what you were trying to tell me in the first place.
I have a model (Parent) that has a has_many association with another
model (Child). I read that there are performance issues (relating to
GC) with too many associations. I was about to add more has_many
associations to the parent model to get child objects ordered by
different columns like so:
Is this going to make ruby hold on to this parent object and 4 child
object and use up a lot of memory? (Does the parent model get all the
child records child, child1, child2 and child3 as soon as Parent.find
is called? Or are they only really queried when I access, say,
parent.child1?)
Is it better to just do a Child.find with the parent_id inside the
controller? Or would it use up as much memory as soon as I do
Child.find?
Provide some named scopes in Child to do the sorting then you can do
parent.children.sorted_by_desc
parent.children.sorted_by_name
or whatever (you might think of better names). This should do the
sort in the db query so there should be no efficiency issues, provided
you have indexes on the sorted columns of course.
Hi Colin,
This was exactly what I was after. I have to do some performance
testing, but it already seems faster with named_scope.
Thanks very much!
Kumi
