Gary Weaver
2013-May-01 21:30 UTC
better generalized n+1 queries avoidance strategy for the future?
Consider this to be a pummeling massage of a not quite living equine. If using one of the several JSON de-serialization (view) methods available in Rails (JBuilder, AMS, etc.), the suggested way to write the JSON service part of a Rails application would be: 1. Define the schema through the migrations. 2. Define the models and their associations to match the relationships in the schema. 3. Define the controller that has queries (using the model, which uses the defined schema). 4. Define the AMS, JBuilder, or whichever view that again defines the associations to determine what JSON to render. 5. Go back into the controller and have to add the necessary code (hash) to the query to eager load associations after the development of the view has been stabilized somewhat. In many cases (not all), there is unnecessary replication of what data you want from the DB, eager loaded, to provide to the client. At worst people are actually making those n+1 as separate HTTP(S) requests through different controllers and lock themselves into a design that keeps them from being easily able to eager load. This is not Roy''s vision of hypermedia-driven REST. A single resource can be composed of data from multiple table. It is just convention in Rails to have a single controller to a single model and a single model to a single table. I understand separation of concerns, but there seems to be some emerging duplication that could go away now that jbuilder views are being generated in the scaffold generator and time is being put into AMS. Just want to make it better. Thanks! -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Gary Weaver
2013-May-06 17:25 UTC
Re: better generalized n+1 queries avoidance strategy for the future?
I wrote something somewhat trivial that takes ActiveModel::Serializers and outputs what includes could help in queries to avoid n+1. If anyone would like to fork and add back similar support for JBuilder in it, that would be neat, but not holding my breath since people might not care about it. https://github.com/garysweaver/yodo After all, you only die once (unless you believe in reincarnation, and that''s fine- it isn''t trying to be preachy). On Wednesday, May 1, 2013 5:30:48 PM UTC-4, Gary Weaver wrote:> > Consider this to be a pummeling massage of a not quite living equine. > > If using one of the several JSON de-serialization (view) methods available > in Rails (JBuilder, AMS, etc.), the suggested way to write the JSON service > part of a Rails application would be: > > 1. Define the schema through the migrations. > > 2. Define the models and their associations to match the relationships in > the schema. > > 3. Define the controller that has queries (using the model, which uses the > defined schema). > > 4. Define the AMS, JBuilder, or whichever view that again defines the > associations to determine what JSON to render. > > 5. Go back into the controller and have to add the necessary code (hash) > to the query to eager load associations after the development of the view > has been stabilized somewhat. > > In many cases (not all), there is unnecessary replication of what data you > want from the DB, eager loaded, to provide to the client. > > At worst people are actually making those n+1 as separate HTTP(S) requests > through different controllers and lock themselves into a design that keeps > them from being easily able to eager load. This is not Roy''s vision of > hypermedia-driven REST. A single resource can be composed of data from > multiple table. It is just convention in Rails to have a single controller > to a single model and a single model to a single table. > > I understand separation of concerns, but there seems to be some emerging > duplication that could go away now that jbuilder views are being generated > in the scaffold generator and time is being put into AMS. Just want to make > it better. > > Thanks! >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-core+unsubscribe@googlegroups.com. To post to this group, send email to rubyonrails-core@googlegroups.com. Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. For more options, visit https://groups.google.com/groups/opt_out.