Skip to content

OBGM-545 Fix pagination for product list#4135

Merged
awalkowiak merged 1 commit intofeature/upgrade-to-grails-3.3.10from
OBGM-545
Jul 4, 2023
Merged

OBGM-545 Fix pagination for product list#4135
awalkowiak merged 1 commit intofeature/upgrade-to-grails-3.3.10from
OBGM-545

Conversation

@kchelstowski
Copy link
Collaborator

The problem was with a difference between joining type in Grails 1 vs Grails 3 - we were fixing this once, but the join was added in a wrong place, because we should join synonyms only if we provide params.name.
Additionally - the pagination was showing wrong results, because the LEFT_JOIN was giving us duplicate results which was then cut by the distinct.
Why it was giving duplicate results is due to LEFT_JOIN being used - if a product has 4 synonyms, it was considered 4 times in the query.
A workaround for that was to add an additional criteria to the createAlias, which was to join by product.id and synonym.product_id AND synonymTypeCode = SynonymTypeCode.DISPLAY_NAME - this will remove the duplicates, because we can have only one DISPLAY_NAME synonym.

Fortunately we can add additional criteria in createAlias - since it might be difficult to find, I'm attaching a link to docs of that: https://docs.jboss.org/hibernate/orm/4.1/javadocs/org/hibernate/Criteria.html#createAlias(java.lang.String,%20java.lang.String,%20org.hibernate.sql.JoinType,%20org.hibernate.criterion.Criterion)

@awalkowiak awalkowiak merged commit 3af9fc9 into feature/upgrade-to-grails-3.3.10 Jul 4, 2023
@awalkowiak awalkowiak deleted the OBGM-545 branch July 4, 2023 11:10
Copy link
Member

@jmiranda jmiranda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A workaround for that was to add an additional criteria to the createAlias, which was to join by product.id and synonym.product_id AND synonymTypeCode = SynonymTypeCode.DISPLAY_NAME - this will remove the duplicates, because we can have only one DISPLAY_NAME synonym.

@kchelstowski What if this last part wasn't true? Is there a way for us to write this query so we don't get duplicates.

In the original query, I know there would be a record returned for products without a display name. But does including the "like" restriction filter these results out?

Also why do we use "like" instead of "equals".

@kchelstowski
Copy link
Collaborator Author

@jmiranda obviously if the last part wasn't true, we might have a problem again, but I'd say the risk is very low.
I have not thought through how to make it work if we have some OneToMany relationships, because if you take a look at the conditions above, they all are about singletons (glAccount, category, productFamily, etc).
The problem with making query itself is not the problem, because the distinct would get rid of the duplicates - the problem is with the moment when the pagination is done - it is done AFTER the distinct, so by getting duplicates, we have e.g. 7-8 results per page, not 10.

As for eq vs like I agree, it's a bummer. In this case they'll evaluate to the same thing, but I agree it should've been eq (I don't know why I made it like). I can change it one of my upcoming PRs if that sounds good to you. Thanks for pointing that out.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants