Rails Nested Resource Issues

Martyn Taylor mtaylor at redhat.com
Fri Sep 21 10:17:38 UTC 2012


On 09/20/2012 09:49 PM, Jason Guiditta wrote:
> On 20/09/12 16:16 +0100, Martyn Taylor wrote:
>> I've created a new topic on the "Ruby on Rails: Talk" forum: 
>> https://groups.google.com/forum/?fromgroups#!forum/rubyonrails-talk
>>
>> I was directed here by: http://rubyonrails.org/community.  If I get 
>> little response on the forum I'll escalate it to the core list.
>>
>> Regards
>>
>> Martyn
>>
> So, I have been searching around the intertubes today, and from what I
> can tell, passing in <something>_attributes was a deliberate design
> decision by the rails team[1].  That doesn't make it suck any less, but
> it does indicate that at least we aren't the ony ones to hit this
> problem.  I am still quite suprised that more people are not doing
> what we want to do here though.  Makes me wonder if perhaps it is more
> common to do as lutter and the deltacloud crew have done with cimi,
> and not support direct CRUD on nested objects, at least via the api?
We have a requirement to be able to do build/push in a single request.  
The API was intended to support this by accepting a Create TargetImage 
request with a nested Provider Image.
> Not sure, but I found a couple links I wanted to pass along in case
> they are of any help:
>
> http://stackoverflow.com/questions/4052677/rails-nested-resources-input-vs-output-format-inconsistency 
>
> https://gist.github.com/653925
Thanks.  I think this further confirms the issue, and that others are 
experiencing the same problem.
> I briefly played with the above gist just now, as it seemed similar to
> the proposed before_filter idea we discussed earlier, but it had some
> syntax problems, and I don't think I'll have time to get through
> cleaning it up for proper testing today.  If the problem remains
> tomorrow, I will try to help look some more.
>
> -j
>
> [1]
> http://groups.google.com/group/rubyonrails-core/browse_thread/thread/3c61e00916c365e5/d3d68be5ec9084f5 
>
>

 From that explanation it seems that the developer has chosen the easy 
route rather that the correct route.  It doesn't seem to be a high level 
design decision thinking about the API and how will effect layers 
above.  But an implementation decision, which follows the easiest route; 
in order offer some form of nested resource functionality.





More information about the aeolus-devel mailing list