"not yet loaded" -- can we talk about this? :-)

rubyonrails-talk
#1

Hi --

I was gearing up to submit a bug report on this:

q = Question.find(1)

=> #<Question:0xb771917c @attributes={"text"=>"What?", "id"=>"1",
"user_id"=>nil}>

q.answers

=> <answers not loaded yet>

when I discovered that it's actually a recently checked-in change.

It seems very strange to me; I'd rather just get what I ask for. It
appears that one can do:

   q.answers(true)

to trigger the expected response, but that seems backwards: I think
that the semantics and logic of "q.answers" can only mean "the
collection of answers belonging to q", and that if something else is
going to be returned, *that* should require a special flag.

Is there any possibility of refining or reverting this change, so as
to keep the application console as wonderfully transparent as it's
always been?

David

#2

I agree with David. When I first saw this change in the console I
scratched my head wondering what the heck I needed to do to get it to
load the associated objects. So, +1 on getting back the old behavior.

Sincerely,
Anthony Eden

#3

I guess the old behavior should be restored only in development mode,
if at all. imho.

#4

I guess the old behavior should be restored only in development mode,
if at all. imho.

It's only in the console, so it doesn't affect actual production
operations in either case. But I'd settle for having it reverted for
development mode, since that's where I'm at in the console most of the
time.

David

#5

It's only in the console, so it doesn't affect actual production
operations in either case.

Yeah. But the console comes really handy when something critical fails
in production and you have to find the solution asap on a live system.
Very rare, but does happen once in a while.

#6

Hi --

#7

dblack@wobblini.net wrote:

Hi --

It's only in the console, so it doesn't affect actual production
operations in either case.

Yeah. But the console comes really handy when something critical fails
in production and you have to find the solution asap on a live system.
Very rare, but does happen once in a while.

Definitely. My strong preference would be for "object.things" to
return object.things, every time in every mode.

+1

And a change like this will break many examples of console use, in tutorials and books.

   Justin

#8

Justin Forder wrote:

#9

Yeah this one’s been bugging me too. It got me during a demonstration to a student who’s new to console. Had to do some quick thinking there.

#10

+1

i agree. by definition a has_many on a model should return the array
of associated objects. to make this behavior conditional is extremely
confusing. the most important early learning experiences in rails i
had was the ability to play around in the console and try things like

Tree.find(1).leaves.map{|l| l.color}
=> ["red", "orange", "blue"]
but thats broken now. please fix!

The patch was applied in response to a bug filed for a developer who
had an instance of class A with many thousands of associated Bs. All
those Bs were being displayed when A was inspected, so this was a
reasonable fix. To resolve this completely it'd be good to suggest a
workaround for the submitted bug. of which this email is conspicuously
absent.

don

#11

Within console...

a = Monstrosity.find(...); 0

Notice the "; 0"? console will return '0' as the output. Now do wahtever you want with a, just don't look at it all at once.

-philip

#12

Yes, it will be fixed.

The problem it’s meant to solve is

executes ‘select count(*) from bars where foo_id=?’ and initializes the @bars association proxy

foo.bars.size

Object#inspect calls inspect on foo’s instance variables, including the @bars association proxy.

The proxy doesn’t recognize #inspect, so it loads the target (all bars, maybe millions?) and inspects that.

foo.inspect

The right way to ‘fix’ this is to override AR::Base#inspect instead.

Without a fix, those with very large associations will get, for example, a gigantic #inspect in their production log when an exception occurs.

jeremy

#13

Jeremy Kemper wrote:

#14

I agree with most everyone in this thread. I feel that q.answers
should automatically load the associated object in the console in
development mode.

This change is a little nuisance... :frowning: