On Apr 17, 8:03 am, ylg <[EMAIL PROTECTED]> wrote:
> On Apr 8, 9:23 pm, Jeremy Evans <[EMAIL PROTECTED]> wrote:
>
> > Unfortunately, eager loading comes at the expense of a small amount of
> > backward compatibility. If you were using uncached associations (the
> > default in sequel_model 0.5), they no longer work the same way. Now,
> > all associations act as if :cache=>true (which is now set for all
> > associations, so if you wrote a tool that worked with both cached and
> > uncached associations, it should still work).
>
> As best I can tell--my apologies if I've got it wrong as I'm still
> working through the upgrade to 1.4--it's not that un-cached
> associations work in a different way, but that they're not supported.
> So, person.taxes.filter{:year == 2007}.order(:outrageousness) can't be
> done using the built-in associations because arrays are always
> returned now, :cache or no.
If you want the dataset (similar to uncached associations), use the
association_dataset method:
person.taxes_dataset.filter{:year == 2007}.order(:outrageousness)
Don't forget that associations can take a block, and support an :order
option, too.
> This seems to leave two options: replace all code that uses that sort
> of chaining with code like Tax.filter{:person_id == person.pk && :year
> == 207}.order [...] or add "non-eager," custom association methods to
> all models, e.g., def taxes; Tax.filter{:person_id == self.pk}; end.
> combined with something like on_to_many :taxes_for_eager [...] (if one
> wants eager loading in places.)
Use the dataset if you want to do special filtering. I recommend
wrapping them in other methods:
def taxes_for_year(year)
person.taxes_dataset.filter(:year=>year).order(:outrageousness)
end
If you want to eagerly load with you customized associations, you'll
need to define separate associations:
one_to_many :taxes
one_to_many :taxes_2007, :class=>'Tax', :order=>:outrageousness do |
ds|
ds.filter(:year=>2007)
end
Actually, you can't currently eagerly load an association with a
block, but I'll be adding that soon. Might even make it into 1.5.0.
> No matter how I look rewriting things to support 1.4, and I strongly
> suspect I'm overlooking something very obvious, it seems the
> complexity and SLOC is going to have to go up a tad for code using
> associations >= 1.4.0. Is there a better practice/pattern for using
> model associations now?
The associations_dataset method is briefly mentioned in the RDoc. The
documentation could certainly be improved, and I welcome documentation
patches.
Hopefully, the new associations will make things less complex. Plus,
there wasn't any way around making all associations cached if eager
loading was going to be supported (unless it was only going to be
supported on cached associations). I told Sharon before the release
of 1.3, that if he ever planned to support eager loading, he shouldn't
make the association method return a dataset. I'm not sure if he
planned to support eager loading, but when I took over maintenance, it
was the first thing I added.
Jeremy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To post to this group, send email to sequel-talk@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
