Hi Oleg, This is a great idea.
I'd probably push the implementation down further to the Collection layer so that once we've succeeded in making OneToMany::Proxy a Collection subclass the speed up will be available at all levels. We actually have something similar to this in the new in-memory adapter code, but I could see it being generalized to allow iteration over any Collection, not just those stored within the in-memory adapter. Or maybe it would make sense to use a Collection inside the in-memory adapter to store the records and have this functionality pushed to Collection? Dan (dkubb) On Nov 2, 9:19 pm, Oleg Andreev <[EMAIL PROTECTED]> wrote: > Hi there! > > I've created a small monkeypatch which optimizes queries to > associations: > > http://pastie.org/306233 > > In two words: > > author.articles.all(...query...) doesn't produce SQL request when all > articles were loaded: it just filters them using standard ruby > Array#select/detect/sort methods. #all uses #select, #first uses > #detect. :order is handled too. :limit/:offset are not supported (yet?) > > When articles data is not loaded, this code behaves as usual. That is > it creates SQL query for author's articles limited and sorted with > additional query. > > PS. Comments around OneToMany::Proxy#first/#all say: > # FIXME: remove when RelationshipChain#get_children can return a > Collection > > This might mean that my patch won't be needed someday. I hope so. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
