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

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
=>

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


David A. Black | [email protected]
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB’s Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

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 E.

On 12/2/06, [email protected] [email protected] wrote:

going to be returned, that should require a special flag.
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB’s Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org


Cell: 808 782-5046
Current Location: Melbourne, FL

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

On 12/2/06, Anthony E. [email protected] wrote:

Hi –

Is there any possibility of refining or reverting this change, so as
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com


rm -rf / 2>/dev/null - http://null.in

Dont judge those who try and fail, judge those who fail to try…

On Sat, 2 Dec 2006, Pratik wrote:

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

On 12/2/06, [email protected] [email protected] wrote:

going to be returned, that should require a special flag.
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
Current Location: Melbourne, FL


David A. Black | [email protected]
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB’s Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

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.


rm -rf / 2>/dev/null - http://null.in

Dont judge those who try and fail, judge those who fail to try…

Hi –

On Sat, 2 Dec 2006, Pratik wrote:

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.

David


David A. Black | [email protected]
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB’s Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] http://www.manning.com/black | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org

[email protected] wrote:

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

Justin F. wrote:

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.

…but shouldn’t this be raised in the Rails core list?

Justin

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.

On 12/2/06, [email protected] [email protected] wrote:

On Sat, 2 Dec 2006, Pratik wrote:

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

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

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.

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

On 12/2/06, [email protected] [email protected] wrote:

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?

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

Jeremy K. wrote:

Is there any possibility of refining or reverting this change, so as
foo.bars.size
gigantic #inspect in their production log when an exception occurs.
Thanks, Jeremy! IIRC there’s an IRB option to turn off the use of
inspect on results… but it sounds as if you are advocating a ‘limited
output’ form of inspect. It’s a distant memory, but I think I have used
LISP systems that worked like that.

regards

Justin

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:

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