Advice on managing object graph in memory

I’ve experienced several inconsistencies when I traverse related
ActiveRecord objects before they are saved into database. For example:
c = parent.children.build # => #Child:0x222222
parent.children # => [#Child:0x222222]
c.parent.children # => [] … it should return the
same
as parent.children

My question is this: is it generally a bad idea to interact with object
graph that’s unsaved? While it’s common practice to build an object in
memory, bounce it back and fourth between the view and the controller
all
without saving it, I find that kind of paradigm hard to achieve when I
need
to build multiple objects that are related to each other. It seems to
only
work well for a single object, in which case the only inconsistency is
that
it doesn’t have an ID yet.

Thoughts?
Eric

Eric L. wrote:

memory, bounce it back and fourth between the view and the controller
all without saving it, I find that kind of paradigm hard to achieve when
I need to build multiple objects that are related to each other. It
seems to only work well for a single object, in which case the only
inconsistency is that it doesn’t have an ID yet.

Thoughts?

You can manually stitch things together, such as back links for
belongs_to associations, and by adding c.parent = parent after
the build in your example. Build should probably do this
automatically.


We develop, watch us RoR, in numbers too big to ignore.

Hmm… that seems kind of inconvenient, but I’ll give it a try, thanks.

By the way, is the inability to back reference from child
(c.parent.children
) a generally known behavior, or is it something that should be fixed in
the
framework?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs