dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
2006-Dec-02 13:32 UTC
"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=> <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 -- David A. Black | dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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 On 12/2/06, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org <dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote:> > 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 > > -- > David A. Black | dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
I guess the old behavior should be restored only in development mode, if at all. imho. On 12/2/06, Anthony Eden <anthonyeden-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > 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 > > On 12/2/06, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org <dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote: > > > > 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 > > > > -- > > David A. Black | dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org > > 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 > > > >-- rm -rf / 2>/dev/null - http://null.in Dont judge those who try and fail, judge those who fail to try.. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
2006-Dec-02 14:13 UTC
Re: "not yet loaded" -- can we talk about this? :-)
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, Anthony Eden <anthonyeden-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> >> 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 >> >> On 12/2/06, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org <dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote: >>> >>> 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 >>> >>> -- >>> David A. Black | dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org >>> 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 >> >>> >> > > > -- > rm -rf / 2>/dev/null - http://null.in > > Dont judge those who try and fail, judge those who fail to try.. > > >-- David A. Black | dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> > 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.. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org
2006-Dec-02 14:31 UTC
Re: "not yet loaded" -- can we talk about this? :-)
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 | dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org wrote:> 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.+1 And a change like this will break many examples of console use, in tutorials and books. Justin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Justin Forder wrote:> dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org wrote: >> 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. > > +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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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, Justin Forder <justin-zSfPWr5aQuznITO/+xaoB7VCufUGDwFn@public.gmane.org> wrote:> > > Justin Forder wrote: > > dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org wrote: > >> 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. > > > > +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 > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/2/06, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org <dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Philip Hallstrom
2006-Dec-04 22:01 UTC
Re: "not yet loaded" -- can we talk about this? :-)
> On 12/2/06, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org <dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> 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.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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 12/2/06, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org <dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote:> > 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?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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Jeremy Kemper wrote:> On 12/2/06, dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org <dblack-TKXtfPMJ4Ozk1uMJSBkQmQ@public.gmane.org> wrote: >> 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? > > > 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.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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
Christopher J. Bottaro
2007-Jan-14 19:11 UTC
Re: "not yet loaded" -- can we talk about this? :-)
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... :( --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---