22/focus view#28
Conversation
| def ancestors_until_parent(node_id, parent_id) | ||
| ancestors = Node.join_recursive { |q| q.start_with(id: node_id).connect_by(parent_id: :id).where('nodes.id >= ?', parent_id) } | ||
| ancestors_map = Hash.new { |h, k| h[k] = Array.new } | ||
| ancestors.each { |n| ancestors_map[n.parent_id] << n } | ||
| branch_root = ancestors.find_by(id: parent_id) | ||
| return ancestors_map, branch_root | ||
| end | ||
|
|
There was a problem hiding this comment.
This could be quite expensive. What's the complexity class? Do we have an performance measure for it? How many round-trips to the database will it make?
There was a problem hiding this comment.
I don't have a performance measure for it atm. Since it recurses all the way up to the parent of the post, it would make n trips, where n is the number of direct children between the parent and the current node. Since it has to retrieve all the parents, wouldn't it have to do this? I'm not familiar w optimising db queries so I'll look into it.
There was a problem hiding this comment.
Do you have any suggestions on how we could improve this? I'm currently setting up a method to create a post with 500 nested children and then will run a benchmark on what I currently have.
There was a problem hiding this comment.
I've just pushed a new commit that will create a deep nested root node - if you run rake n_fake_nodes=500 db:drop db:create db:migrate db:setup, it will create it on setup. I ran a benchmark on it using the console and these are the results I got:
@label="normal: ", @real=0.19937049999134615, @cstime=0.0, @cutime=0.0, @stime=0.0, @utime=0.09464000000000006, @total=0.09464000000000006>]
This was running the ancestors_until_parent function with the root node and focusing on the very bottom of the node (i.e. 500 levels deep). Do you see any issues w this? This ran pretty quickly imo but I don't have much of a reference as to what is considered acceptable.
There was a problem hiding this comment.
I don't have a performance measure for it atm. Since it recurses all the way up to the parent of the post, it would make n trips, where n is the number of direct children between the parent and the current node. Since it has to retrieve all the parents, wouldn't it have to do this? I'm not familiar w optimising db queries so I'll look into it.
from memory join_recursive uses ARHQ which means that the query is recursive, but it's just one query.
With rack-mini-profiler you should get a thing in the top left like this:
That will show you how many SQL queries are made and the breakdown of time spent.
wrt optimizing db queries, you can look into the "n+1 problem" if you like. it's badly named but sorta gets the point across.
3 participants
Added a focus button on each comment under a post. When you click on it, it'll bring you to a new page where you are able to view only the relevant posts associated with that comment.
Relevant posts include:
illustration taken from microblog here:
note from max on diagram:
Essentially like the show context feature in reddit.