I understand -- it would be a case where you do not want to deliberately
cache the resultset, and so, it would not be quite like an association
proxy.
But of course, each is all that's needed for things like
select/reject/inject. And inject, in particular, should be safe --
select/reject, any?, all?, and similar things will still benefit from not
_holding_ all items in memory, even if all items will have to be iterated
over anyway.
In fact, it's my understanding that this is the main reason for having an
enumerable interface -- when using such an interface, you're not required to
know or care whether it's a native array, the result of slurping the entire
table, one select call per iteration, or anything in between.
Of course, there are also the things like sort, uniq, and map that would
ruin your whole day -- though map, at least, could be implemented in a
lazier way, for this purpose.
On Tue, Dec 2, 2008 at 9:55 AM, acechase <[EMAIL PROTECTED]> wrote:
>
> David,
>
> I don't think it would be possible to support the enumerable interface
> in this extension because it would negate the memory management
> benefits that are the reason for using such a technique. Looking at
> the code, it looks like Andreas instantiates one ruby object at a time
> from the result set, then yields that object to the block for work to
> be done on it and frees the object after the yield returns (it's a
> little fancier than this with the Oracle extension, but in the MySQL
> version that's about it). If you were to allow for things like select/
> reject, inject, etc then you're back in a situation where some
> potentially large subset (or all) of those ruby objects are going to
> be held in memory.
>
> As for named scopes, like you said, I think that just works. The named
> scopes just insert there additional magic into the final query that
> gets made (adds additional conditions, joins, etc).
>
> Cheers,
> Andrew
>
> On Dec 1, 1:47 pm, "David Masover" <[EMAIL PROTECTED]> wrote:
> > On Sat, Nov 29, 2008 at 8:14 AM, Andreas Gungl <[EMAIL PROTECTED]> wrote:
> >
> > > MyTable.find_each_by_sql("some SQL here") { |my_table| ... }
> >
> > > MyTable.find_each(:all, :conditions => ...,
> > > :include => ...) { |my_table| ... }
> >
> > Any chance of having these work by scope/proxy, instead? For instance:
> >
> > MyTable.all.each do |record|
> > ...
> > end
> >
> > Or, something like this, with named scopes:
> >
> > User.registered.customers.each do |user|
> > ...
> > end
> >
> > I think this already works, actually -- it just implicitly converts the
> > AssociationProxy to an array. In other words, it slurps the entire result
> > set. It would be nice if this behavior could be made to transparently (or
> > optionally) do what you've implemented, rather than inventing a whole new
> > interface -- for example, find_each doesn't help when you want to use
> other
> > things from Enumerable, like select/reject, inject, etc.
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" 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/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---
