Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Discussion] Refine design of co-authored posts on profile pages #9798

Closed
TildaDares opened this issue Jun 14, 2021 · 7 comments
Closed

[Discussion] Refine design of co-authored posts on profile pages #9798

TildaDares opened this issue Jun 14, 2021 · 7 comments

Comments

@TildaDares
Copy link
Member

TildaDares commented Jun 14, 2021

Presently coauthored posts are displayed separately from normal posts as seen here https://publiclab.org/profile/warren. I suggested changing the query that gets a user's posts (notes, questions and wikis) to also include co-authored posts.

def find_posts_by_type(type = 'note')
  coauthored_tag = "with:" + name.downcase
  
  Node.where(type: type).where('node.uid = ? OR term_data.name = ? OR term_data.parent = ?', uid, coauthored_tag.to_s, 
  coauthored_tag.to_s).order('created DESC')
end

What does the community think?

@jywarren @RuthNjeri @cesswairimu

@RuthNjeri
Copy link
Contributor

Hi @TildaDares, thanks for sharing your idea. What would be the benefit of this? I guess I am also curious about the initial decision on not including the co-authored posts, maybe @jywarren or @ebarry can shed light on that.

I do see the option of accessing co-authored posts on the sidebar
Screenshot 2021-06-20 at 13 06 37

@jywarren
Copy link
Member

Fetching the co-authored posts is a less efficient database query, unfortunately, because we don't have a many-to-many relationship between nodes and users. The with:USERNAME powertag serves as our join table, but fetching it is not super efficient. So we've kind of avoided doing this as the default. @TildaDares do you see a way around it or think the performance won't be too bad? Thanks for thinking on this! Maybe we need to leave a comment somewhere to explain this too!

@TildaDares
Copy link
Member Author

@jywarren I don't see any workaround that would be more efficient.

@jywarren
Copy link
Member

Hi Tilda! If you are interested in taking this one up, i think the next steps were:

  1. think about/take notes on the potential performance impact of a dual query
  2. try some load tests in the Rails console?
  3. Try making the change and pushing it to unstable for speed tests in the dev console Network pane
  4. think about how best to document this change and make future developers aware of how it works
  5. make a final decision

How does that sound?

@TildaDares
Copy link
Member Author

Sounds good @jywarren.

@TildaDares
Copy link
Member Author

@jywarren I looked at the response time on skylight and it has a typical response of 342ms which I think is manageable considering that we don't have a many-to-many relationship.

Also, going with my initial plan of including co-authored posts with regular posts would mean fetching all of the user's notes (including co-authored posts) first before being able to get the all of the user's question and that wouldn't improve the efficiency. For now, I think it'd be best to leave the posts as is.

@jywarren
Copy link
Member

jywarren commented Aug 3, 2021

OK, I think that sounds good. Thank you for looking into it, @TildaDares !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants