Giters

nestjsx / nestjs-typeorm-paginate

:page_with_curl: Pagination response object function + types for typeorm + nestjs

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Regression: `count` returns 0

GerkinDev opened this issue · comments

commented

See e76c940#r57500408.

I think paginateRepository should actually take a FindManyCondition instead of a FindManyOptions, since limit and page are passed separately.
In this case, order should be set in IPaginationOptions.

I guess you're working on it. But I could PR if you want.

commented

#567 FindManyOptions was choosen in favour of FindManyCondition because of confusing and conflicting. As for your title I guess you're refering to v^3.1.0? As I've broken complex count queries with typeorm trying to resolve the count as a sub query. Currently having issues with duplicate select params + parameters.
The problem is I'm trying to duplicate the query and use it as a sub query however select properties are duplicated because the alias is changed (yea not quite sure). I'm trying to resolve this though. Don't suppose you've got any ideas on how to duplicate a query with typeorm + keep the having, select and where properties in without duplicating them when cloning?

commented

Indeed, this is related to ^3.1.0, and with a mongodb Repository (not using query builder).

Why don't you conditionally use Repository.findAndCount method ?

commented

I could however that doesn't fix the problem for more complex queries. If you're having an issue with count queries you can revert to 3.0.0 where the problem doesn't exist. This is my fault for not releasing this as an alpha tag

commented

No problem, would do that ;) please update the issue once you have found a proper solution

commented

I've released 3.1.2 which has the correct query. My tests had an issue which confused me into thinking the cloned querybuilder had duplicate expressions

commented

v3.1.2 doesn't fix my issue. Moreover, by looking at 367b6ea, it seems you only changed things related to query builder. I'm using pure repository.

Having a changelog would help me find out which version introduced the change I'm having troubles with.

commented

Ahh I see. Would you mind providing an example of your usage please? I shall revert this change if required.

Yea I really need to start doing changelogs 😂 scared of getting them wrong!

commented

Example:

@Controller( 'article' )
export class ArticleController {
	public constructor(
		@InjectRepository( Article ) private readonly articleRepository: MongoRepository<Article>,
	){}

	@Get( ':kind' )
	public getPage(
		@Param( 'kind' ) kind: string,
		@Query( 'page', new DefaultValuePipe( 1 ), new ParseIntPipe() ) page: number,
	): Promise<Pagination<Article>>{
		const langs = [ 'en', 'fr' ];
		return paginate(
			this.articleRepository,
			{ limit: PAGE_SIZE, page, route: `${environment.baseUrl}/rest/article/${kind}` },
			{ where: { kind, lang: { $in: langs }}} );
	}
}

In the meantime, I reverted to ~3.0.0

About changelogs: Yeah, manual generation is a pain. I see you already use relatively standard commit messages formats. If you don't enforce this, you might be interested in husky to ensure commit messages formats and commitizen which exports a git-cz cli util to prompt standard messages. Then, use standard-version to auto-generate changelog and deduce bump type from commit history. I personally use those tools in each of my projects.

commented

Ahh so for the latest version you can remove the where key word basically but I'm still going to revert this change as it's removed the abaility to add order bys and relations which I think should be in here. was brought in by #567 #608 Reverting in #620

Thanks for the advice on change logs! I shall look that up and see if I can add that!

commented

Reverted in 3.1.3 now so you should be able to use FindConditions<T> again in paginate() with repository