-
-
Notifications
You must be signed in to change notification settings - Fork 48
discover pages displays no more than 3 posts per author #1089
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @alphatownsman, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
This pull request modifies the discover
view in catalog/views.py
to limit the number of posts displayed per author to a maximum of 3. It achieves this by using a window function to assign a row number to each post by author and then filtering the results to include only the first 3 posts per author.
Highlights
- Limit posts per author: The main goal is to limit the number of posts displayed on the discover page to a maximum of 3 per author.
- Window function: A window function (
RowNumber
) is used to partition posts by author and assign a row number based on the publication date. - Filtering: The query is filtered to only include posts where the author row number is less than or equal to 3.
Changelog
- catalog/views.py
- Added a window function to partition posts by author and assign a row number based on publication date.
- Filtered the query to limit the number of posts per author to 3.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
A window's pane,
A limit set with care,
Posts now in order.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
The pull request introduces a change to limit the number of posts displayed per author on the discover page. This is achieved by using a Window function to annotate each post with an author_row number and then filtering the posts to only include those with an author_row less than or equal to 3. Overall, the change seems reasonable and addresses the issue described in the pull request title.
Merge Readiness
The code change appears to be a straightforward implementation of the desired functionality. Given that there are no critical
or high
severity issues, the pull request is reasonably ready to be merged. However, it's advisable to ensure that the performance of the query with the added window function is acceptable, especially with a large number of posts. I am unable to approve the pull request, and users should have others review and approve this code before merging.
# Limit to no more than 3 posts per author | ||
popular_posts = popular_posts.annotate( | ||
author_row=Window( | ||
expression=RowNumber(), | ||
partition_by="author_id", | ||
order_by="-published", | ||
) | ||
).filter(author_row__lte=3) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This block of code limits the number of posts per author. Consider adding a brief comment explaining the purpose of the author_row
annotation and the subsequent filtering for better readability.
# Limit to no more than 3 posts per author | |
popular_posts = popular_posts.annotate( | |
author_row=Window( | |
expression=RowNumber(), | |
partition_by="author_id", | |
order_by="-published", | |
) | |
).filter(author_row__lte=3) | |
# Limit to no more than 3 posts per author | |
popular_posts = popular_posts.annotate( | |
author_row=Window( | |
expression=RowNumber(), | |
partition_by="author_id", | |
order_by="-published", | |
) | |
).filter(author_row__lte=3) # Filter to include only the first 3 posts per author |
No description provided.