Forum: Ruby on Rails why can't to_xml read my mind?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-21 19:49
(Received via mailing list)
Railsters:

I suspect the answer is "because they invented it before inventing eager
loading".

The first minor issue with to_xml's refusal to read my mind is it's not
DRY
(like my mind!):

   Model.all(:include =>{ :this => :that }).
     to_xml(:include =>{ :this => :that })

With eager loading, every Model instance has its internal @this member
populated, and each This has its @that populated. So, instead of
repeating the
:include argument, to_xml could just find every populated @this and
@that
instance variable, and recursively call to_xml on it.

Do I misunderstand to_xml here? Or is it indeed refusing to read my
mind?

Another, more minor issue: to_xml( :except =>[ :secret, :password ] )

Is there, instead, a :pass argument, to positively declare what we _do_
want?
Negatively declaring the complete list of variables we _don't_ want
(being most
of them) is not just a waste of time, it's fragile if we migrate more
secret
fields into our model!

Please advise if I need to RFTM, grab a plugin, or else just live with
to_xml's
disturbing refusal to read my mind!

--
   Phlip
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2009-02-22 00:41
(Received via mailing list)
On Feb 21, 6:48 pm, Phlip <phlip2...@gmail.com> wrote:
> With eager loading, every Model instance has its internal @this member
> populated, and each This has its @that populated. So, instead of repeating the
> :include argument, to_xml could just find every populated @this and @that
> instance variable, and recursively call to_xml on it.
>

I think it is hard for AR to distinguish between

m = Model.find ...
m.do_something_that_causes_association_foo_to_be_loaded
m.to_xml

m = Model.find ..., :include => :foo
m.to_xml

In either case at the point that to_xml is called the association is
loaded - if it just spat every loaded association into the xml it
would be very easy to accidentally include stuff. Or you might include
an association at the point of loaded to make calling a certain method
(which you do want included in the xml) faster. While I can certainly
see your point I like to think of passing :include to find as nothing
more than an optimisation hint ( I will be accessing the associations
soon - you would do well to load them) that we make do with until AR
gets smarter.

> Do I misunderstand to_xml here? Or is it indeed refusing to read my mind?
>
> Another, more minor issue: to_xml( :except =>[ :secret, :password ] )
>
> Is there, instead, a :pass argument, to positively declare what we _do_ want?
> Negatively declaring the complete list of variables we _don't_ want (being most
> of them) is not just a waste of time, it's fragile if we migrate more secret
> fields into our model!

That's :only

Fred
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-22 16:51
(Received via mailing list)
Railsters:

I suspect the answer is "because they invented it before inventing eager
loading".

The first minor issue with to_xml's refusal to read my mind is it's not
DRY
(like my mind!):

    Model.all(:include =>{ :this => :that }).
      to_xml(:include =>{ :this => :that })

With eager loading, every Model instance has its internal @this member
populated, and each This has its @that populated. So, instead of
repeating the
:include argument, to_xml could just find every populated @this and
@that
instance variable, and recursively call to_xml on it.

Do I misunderstand to_xml here? Or is it indeed refusing to read my
mind?

Another, more minor issue: to_xml( :except =>[ :secret, :password ] )

Is there, instead, a :pass argument, to positively declare what we _do_
want?
Negatively declaring the complete list of variables we _don't_ want
(being most
of them) is not just a waste of time, it's fragile if we migrate more
secret
fields into our model!

Please advise if I need to RFTM, grab a plugin, or else just live with
to_xml's
disturbing refusal to read my mind!

--
   Phlip
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2009-02-22 17:01
(Received via mailing list)
Did my earlier reply not make it through ?

On 22 Feb 2009, at 15:46, Phlip wrote:

>
> Railsters:
>
> I suspect the answer is "because they invented it before inventing
> eager loading".
>
(I don't think so. eager loading was there way back in rails 1.0/1.1
(possibly before, I just know it was there then because that's when I
hopped on board, to_xml only really appeared with the whole restful
drive (1.2 +))

Fred
Aafa8848c4b764f080b1b31a51eab73d?d=identicon&s=25 Phlip (Guest)
on 2009-02-22 18:23
(Received via mailing list)
Frederick Cheung wrote:

> I think it is hard for AR to distinguish between
>
> m = Model.find ...
> m.do_something_that_causes_association_foo_to_be_loaded
> m.to_xml
>
> m = Model.find ..., :include => :foo
> m.to_xml

Then that's what I mean by reading my mind.

In a desktop app, where 'a' might live for a long time, and go thru many
uses,
to_xml should not guess that something_ was for some other purpose. In
an
event-driven app, then 'a' should be populated, used, and discarded.

Maybe we could compromise on a bit inside AR saying "I was loaded
eagerly -
mind-reading is now okay!"

Or I could just invent this:

   class ActiveRecord::Base
     def find_to_xml(include, conditions = {}, xml_options = {})
       find(:all, conditions.merge(:include => include).
         to_xml(xml_option.merge(:include => include)
     end
   end

As an optimization hint, eager-loading might be more performant (yes
it's a real
word, now), hence the best way to use to_xml ought to be eagerly, hence
we
should get DRY about it.

While we have the subject open, where's an example of to_xml{}. The RDoc
mentions it, of course, but does not illustrate it, of course.

> In either case at the point that to_xml is called the association is
> loaded - if it just spat every loaded association into the xml it
> would be very easy to accidentally include stuff.

Our unit tests include checks that everything we don't want is not
there!

Uh... really!!

>> Another, more minor issue: to_xml( :except =>[ :secret, :password ] )
>>
>> Is there, instead, a :pass argument, to positively declare what we _do_ want?
>> Negatively declaring the complete list of variables we _don't_ want (being most
>> of them) is not just a waste of time, it's fragile if we migrate more secret
>> fields into our model!
>
> That's :only

Tx! Serves me right for reading RDoc output. I gotta cut down on that,
huh?

--
   Phlip
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2009-02-22 18:47
(Received via mailing list)
On Feb 22, 5:23 pm, Phlip <phlip2...@gmail.com> wrote:
> Frederick Cheung wrote:
>
> > In either case at the point that to_xml is called the association is
> > loaded - if it just spat every loaded association into the xml it
> > would be very easy to accidentally include stuff.
>
> Our unit tests include checks that everything we don't want is not there!
>
> Uh... really!!

Sure, but to me it would be very unobvious behaviour once you had got
your failing unit test to see that the only code difference being that
you called x.foo: calling an accessor (which feels like a read only /
const thing) having a knock on effect on something unrelated would
feel weird to me. Having the :include in find mark associations as
being ok would be better.

Fred
This topic is locked and can not be replied to.