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