-
Notifications
You must be signed in to change notification settings - Fork 122
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
skip + take vs limit + offset poll #576
Comments
Well, when use pagination with Limit & Offset, I have problems using joins as other people. I understand that I should use "Take and Skip" with joins, but what is the main difference, the performance? |
@csxcode well it's looking pretty close atm so I think I might do a bit of research and see what the diff is (been a while since I've properly looked at query performance) and see if we can convince more people! If there's no performance difference then I guess we leave it? |
I second @csxcode point. I don't think this is a question of only performance. Depending on the query "take and skip" may be preferable over "limit and offset". |
Like it was said by the creator of typeorm:
|
One issue I find though is when I have joins with selection and an orderBy clause. Neither |
cloud someone shows me how to change the query type to TAKE_LIMIT. I couldn't find it in the documentation. sorry for commenting on the irrelevant issue. |
const result = await paginate(
queryBuilder,
{
limit: 10,
page: 1,
paginationType: PaginationTypeEnum.LIMIT_AND_OFFSET
}
); |
I think after several extra months, it's pretty unanimous that Limit & OffsetUses query based method for selection Skip & TakeUses javascript filter to filter results |
Seems like there are some conflicts between the default method of querying. I feel this is a bit of an opinionated choice in some cases and I also don't want to be bias! I personally would stick with limit + offset as it's perfect for simple queries however some people may differ.
Please could people vote for their perfered method, once I have enough votes say by end of November we can release a breaking change if required.
The text was updated successfully, but these errors were encountered: