On Tuesday, December 3, 2013 7:40:07 PM UTC-6, Jeremy Evans wrote:
>
> What's your reason you need this to be in after_initalize, instead of
> called lazily when the association is loaded? Note that if you are eager
> loading the association with the object, after_load will operate as if it
> was called by after_initialize. In other words:
>
> Bar.many_to_many :foos, :after_load=>proc{...}
> Bar.eager(:foos).all{ #foos after load proc alread called once for each
> bar}
>
I am trying to have each loaded Bar perform a custom task using each of its
Foos. This means that I am not concerned with doing anything after the
members of the foos association is loaded. I just need to do something
with the members of foos after their Bar instance is retrieved.
I still can't detect a reason that you would want to do this during
> after_initialize, unless something_special_with(album) mutates the
> receiver. Is that the case?
I probably don't want to do it during after_initialize, necessarily. I
just need the custom task to modify Bar, using information from the members
of foos, whenever a Bar is instantiated with the query results.
Are you saying that something like
class Bar < Sequel::Model
many_to_many :foos, :after_load => proc do |foo|
something_special_with(self)
end
eager(:foos).all
end
will do the trick? Isn't the eager(:foos).all statement an explicit
invocation? I am trying to have foos loaded automatically and implicitly.
You probably want to add this after plugin: rcte_tree:
>
> one_to_many :children, :clone=>:children, :eager=>:albums
>
I attempted this, and it results in that "weird error when attempting to
access a count of the cloned Artist.children association" I was talking
about.
undefined method `id' for {:count=>10}:Hash
To solve this, I tried to change
jimi.children_dataset.count
to this
jimi.children.count
and that seemed to work, but then when attempting to remove a node from the
children association
class Bar < Sequel::Model
def remove
self.parent.remove_child self
end
end
I got another error
undefined method `id' for {:one=>1}:Hash
The caching plugin only populates the cache when you do a primary key
> lookup, and only uses cache lookups by primary key, so based on the code
> you've shown, I wouldn't use it. Roll your own caching:
> def after_initialize
GloballyDefinedConcurrentHashMapInstance[pk] ||= children.each{|artist|
> artist.each(&method(:something_special_with))}
end
> So this doesn't cache the object, but caches the presumably expensive
> calculation. Good luck with cache invalidation :)
Hrm. Sounds like I may have to figure out some other way to reduce my
datasource round-tripping.
The reason this routine is so slow is because some hundreds of queries and
> after_initialize hooks get executed against the datasource backend, even if
> there are only a couple dozen nodes in the branch.
>
I'm assuming that's due to things not being eagerly loaded currently.
I think that this is correct.
There's always:
> jimi.descendants_dataset.where(...).all
I'll give that a shot.
My goodness, this Google WYSIWYG editing is atrocious. The Quote button
and Undo function are completely broken.
Thanks again,
-Nels
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/groups/opt_out.
