On 22 Dec 2009, at 10:17, [email protected] wrote:
[good stuff snipped]
>
> Clearly this wouldn't solve all cases, and some restrictions would
> have to be laid out in the docs, especially about valid "order by"
> phrasing, and resolving table name issues in adding the reflection
> conditions to the subselect conditions...
>
> But anyone have any thoughts about this?
>
What I would really like to see in the eager loading stuff is a bit more
customisation ability - as you point out your solution would have various edge
cases, and eager loading other association types have other caveats (eg
interpolated conditions, customer finder sql etc...). A lot of the time the
best solution to a particular solution is database specific (or even app
specific). It would be super awesome if it was possible to tell active record
"and here is how you eager load this association".
What activerecord would need to do is to provide the ids of the parent objects
and probably (so that you could reuse custom include code) details about the
assocation. The end user code would just need to return the records (probably
as a hash of primary keys to arrays of objects, leaving AR to mark the
associations as loaded and wire up the stuff
It seems to me like this wouldn't be too hard - find_associated_records would
just need to check the association options for the presence of method name /
proc and if so just call that (plus some refactoring for habtm). (Might be a
good time to rejig eager load of hmt and hot so that they don't take two steps).
It would get a little nasty in the cases of associations that are sometimes
eager loaded via this mechanism and sometimes via the old join mechanism - i
suppose you'd just have to make it clear that the eager load method you provide
is only used in your former case.
It would also be nice if you could specify a class providing whatever required
methods, so as well as doing
has_one :bars, :eager_load => lambda { ... } or
has_one :bars, :eager_load => :load_bars
you could do
has_one :bars, :eager_load => SubselectEagerLoader
so all the subselect logic would be packaged up in SubselectEagerLoader (and
then if people have cool database specific optimisations / strategies they can
distribute them as gems, plugins etc)
It would mean that someone like John would have to add :eager_load =>
SubselectEagerLoader to each of his has_ones that required it. it might be nice
to be able to set some sort of default (Class, level, AR:Base level, Connection
Adapter ?), but I feel like I'm getting a little ahead of myself here.
John - sorry to have hijacked your thread here - I do feel this would be a
reasonable way of allowing people to do things the optimal way for them without
having loads of database specific paths through active record
Fred
--
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.
