On Monday, December 2, 2013 6:50:42 PM UTC-8, Nels Nelson wrote:
> Greetings community,-
>
> Apologies in advance for the lack of brevity here, and my gratitude in
> advance for your attention.
>
> I have been attempting to get a reasonably shallow depth rcte tree model
> to work with some many-to-many associations for a few months now, and am
> failing to attain any reasonable performance.
>
> The backend is a PostgreSQL database, and the application is running in
> JRuby using the jdbc-postgres adapter. I am using Sequel version 4.4.
>
> It is certainly possibly, perhaps likely, that my design is poor or my
> model definitions are erroneous. I'm open-minded about alternative
> suggestions.
>
> Each primary tree node model instance uses the after_initialize hook to
> perform a simple looped function on the respective association members.
>
You could try switching to an after_load hook on the association instead of
after_initialize hook on the model. That's probably a better design if it
works with your app.
>
> So far I have two main problems.
>
> 1) A node instance executes the after_initialize hook every time a node
> instance is fetched, even if it has already been fetched once already.
> This is unfortunate, because I would like the program to only have to run
> this functionality once for each individual node, no matter how often the
> program retrieves that node from the datasource.
>
I think the after_load hook should fix this, since it should only be run
once.
>
> Unfortunately, I cannot seem to reliably get rcte tree model instances to
> keep themselves in a global in-memory cache (let alone a memcached
> instance), and from it be subsequently retrieved. It seems that only some
> instances are loaded into the cache, and then only the main model instance,
> with none of its associations.
>
Well, for the children association, this is expected, since Sequel doesn't
support a cache lookup for one_to_many associations. For the parent
association, it should use a cache lookup if you are using the caching
plugin.
>
> 2) The second problem arises whenever the association members of the tree
> node model instance is accessed -- the following query is ran for each
> association access:
>
> SELECT "album".* FROM "album" INNER JOIN "artist_to_album" ON
> (("artist_to_album"."album_id" = "album"."id") AND
> ("artist_to_album"."artist_id" = 1))
>
> I would like to have each association load eagerly onto each node model
> instance so that no query is ran when accessing the node's association
> members.
>
Then use Dataset#eager on the dataset that creates the objects, or the
tactical_eager_loading plugin, in conjuction with Dataset#all to load the
objects.
The query you post does not make sense in rcte_tree context, since it
appears to be using a join table, and the rcte_tree plugin does not.
> I think that I understand that this may not be possible in conjunction
> with the rcte_tree plugin for Sequel. For some reason I was under the
> impression that association eager loading was working for normal
> associations, just not for the tree associations. (Perhaps until recently?)
>
The only thing the rcte_tree plugin gives you is that it allows you do get
all ancestors or descendents (or descendents to some level) in a single
query. You so far have not described usage of those features, so you are
probably just using the associations added by the tree plugin (which the
rcte_tree plugin loads).
> I have tried both using, and not using, the :caching and
> :tactical_eager_loading plugins on the album module. I've tried using and
> not using those plugins on all involved model definitions. Nothing seems
> to make a difference.
>
The caching plugin should only affect the parent lookup, not the children
lookup. The tactical_eager_loading plugin should affect things, but it
requires that you use Dataset#all to retrieve the objects originally.
> Is it indeed still the case that the rcte tree plugin is simply
> incompatible with these plugins entirely? If so, I suppose I will have to
> come up with another approach to obtaining a traversable tree model, or
> something similar.
>
No, it should be compatible as described above.
> I have considered using Neo4j instead of PostgreSQL and Sequel.
>
I don't have much experience with Neo4j, so I can't say whether it would be
a better choice or not. However, I think PostgreSQL and Sequel should be
able to do what you need.
> Thanks again for your consideration.
>
Hopefully the above has been helpful in some way. If you have additional
questions, it would be a good idea to post simple self-contained example
code that isn't working the way you want, and ask how to do what you want
in the context of the example.
Thanks,
Jeremy
--
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.
