On Aug 31, 1:41 pm, [email protected] wrote: > I'm not sure I completely understand the question, but if I had a block I'd do > something like: > > @bar_1 = Bar.get(params[:id => foo_1.id]) > #this will grab all the parameters of that bar based on the id
Sorry, that's because my example was really terrible given the actual problem, so thanks for taking a stab in spite of that. Let me try this instead: say we've a Person obj we need to get early on in a controller method (i.e. inside a repository block), using: Person.get(session[:my_id]) Later on, still in the same controller method and so repository block, we need to get the author of a Post for an unrelated reason, which in some cases coincidently happens to be the same Person as was retrieved above, this time with: Post.get(params['id']).author These two calls (Person.get and post.author) result, again, in some cases, in identical queries going to the DB from DM within the same repository block, i.e., select [...] from people where id = 1; Now, in real scenarios where the relations are much more numerous and complex, those additional queries really pile up fast. In some cases one can get away with tricks like if that_person_from_session.id == the_post.author_id to avoid the duplicate call, but in real scenarios the app logic almost always needs too much for that little hack to be enough. What I'm looking for is patterns or practices people may have for use with DM that avoid the identical "select by id" queries. Put another way, is there a reasonable way of faking a level one cache with DM? -- You received this message because you are subscribed to the Google Groups "DataMapper" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/datamapper?hl=en.
