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

[Fix-16682][ApiServer] like query with % support special characher(% \ _) #16683

Open
wants to merge 6 commits into
base: dev
Choose a base branch
from

Conversation

shouwangyw
Copy link
Contributor

Purpose of the pull request

This pull request fix the querying list, text query condition use 'like' query does not support (% \ _)
Fix #16682

Brief change log

Change ParameterUtils#handleEscapes

Verify this pull request

This pull request is code cleanup without any test coverage.

(or)

This pull request is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(or)

Pull Request Notice

Pull Request Notice

If your pull request contain incompatible change, you should also add it to docs/docs/en/guide/upgrede/incompatible.md

Comment on lines +320 to +326
public static String handleEscapes(String str) {
str = StringUtils.trim(str);
if (StringUtils.isNotBlank(str)) {
str = str.replace("\\", "\\\\");
str = str.replace("_", "\\_");
str = str.replace("%", "\\%");
str = str.replaceAll("[\n|\r\t]", "");
Copy link
Member

Choose a reason for hiding this comment

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

This is a general processing method, and we should not modify it. Workflow name and task name should not contain special characters such as %. We should add verification and documentation when creating it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is a general processing method, and we should not modify it. Workflow name and task name should not contain special characters such as %. We should add verification and documentation when creating it.

I understand that this method is intended for special characters, and should be able to support like fuzzy queries.
And for general processing the character _ and \ should also be supported.This is not just a processing for workflow name and task name,validation should be implemented elsewhere.

Here are some self-tests:
image
image

Copy link
Member

Choose a reason for hiding this comment

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

Different fields should use different verification methods. For example, the workflow name should consist of uppercase and lowercase English letters or Chinese and underscores, and other symbols are illegal characters. But the workflow description can contain more special characters.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Different fields should use different verification methods. For example, the workflow name should consist of uppercase and lowercase English letters or Chinese and underscores, and other symbols are illegal characters. But the workflow description can contain more special characters.

I understand this, but this general method is not for verification, but for supporting special characters in like fuzzy queries.

Copy link
Member

Choose a reason for hiding this comment

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

This is a general processing method, and we should not modify it. Workflow name and task name should not contain special characters such as %. We should add verification and documentation when creating it.

This issue only solves the problem of workflow list query. We should follow this, and the rest do not belong to this issue.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This issue is not just about solving the workflow list query problem, the issue only takes the workflow list as an example. This is indeed a general process.

If so, we need to analyze specific problems, because different query scenarios need to use different rules. The current implementation needs optimization.

This process involves many calls, and every time you write a new query list interface, you may need to call this method.
This may not be a good implementation, but it is the smallest change,for the time being, this is also implemented in our actual project

Copy link
Member

Choose a reason for hiding this comment

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

Since the caller of this method is too extensive, it is impossible to comprehensively evaluate the influence surface. In order to reduce the impact and achieve the optimization effect, it is better to deal with it separately.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since the caller of this method is too extensive, it is impossible to comprehensively evaluate the influence surface. In order to reduce the impact and achieve the optimization effect, it is better to deal with it separately.

sure, and some places have not been searched by like, i will check it again.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have checked all the calling places, and most of them use like % query. In addition, remove some don't need % escapr processing. @SbloodyS

Copy link
Member

Choose a reason for hiding this comment

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

I have checked all the calling places, and most of them use like % query. In addition, remove some don't need % escapr processing. @SbloodyS

Since the caller of this method is too extensive, it is impossible to comprehensively evaluate the influence surface. In order to reduce the impact and achieve the optimization effect, it is better to deal with it separately.

The scope of this revision is relatively large and it does not belong to the description scope of this issue #16682 . In this Fix PR, we only need to extract the query of workflow list separately and fix it. The other is to create a DSIP for scheme design and discussion.

@SbloodyS SbloodyS changed the title [Fix-16682][ApiServer]Like text query condition support (% \ _) [Fix-16682][ApiServer] Like text query condition support (% \ _) Oct 10, 2024
@shouwangyw shouwangyw changed the title [Fix-16682][ApiServer] Like text query condition support (% \ _) [Fix-16682][ApiServer] Like fuzzy query support (% \ _) Oct 10, 2024
@shouwangyw shouwangyw requested a review from SbloodyS October 11, 2024 07:03
@shouwangyw shouwangyw changed the title [Fix-16682][ApiServer] Like fuzzy query support (% \ _) [Fix-16682][ApiServer] like with % query support special characher(% \ _) Oct 11, 2024
@shouwangyw shouwangyw changed the title [Fix-16682][ApiServer] like with % query support special characher(% \ _) [Fix-16682][ApiServer] like query with % support special characher(% \ _) Oct 11, 2024
@ruanwenjun
Copy link
Member

This caused by the specifical meaning of _ and % in mysql, there might exist other symbosl same with these. I didn't find out good idea to solve these problem, seems we need to escape these characters, but this will introduce more problems.

@ruanwenjun ruanwenjun added the discussion discussion label Oct 11, 2024
@shouwangyw
Copy link
Contributor Author

shouwangyw commented Oct 11, 2024

This caused by the specifical meaning of _ and % in mysql, there might exist other symbosl same with these. I didn't find out good idea to solve these problem, seems we need to escape these characters, but this will introduce more problems.

This is not just a problem in MySQL,the PG used in our project have The same problem, and it has been fixed and is currently in use online.

Our project testers initially discovered this issue and recorded a bug for us to fix.
But this change is not elegant enough. We have to call this method every time. It would be great if it could be made into AOP or annotations

@SbloodyS SbloodyS added this to the 3.3.0 milestone Oct 12, 2024
@ruanwenjun
Copy link
Member

This caused by the specifical meaning of _ and % in mysql, there might exist other symbosl same with these. I didn't find out good idea to solve these problem, seems we need to escape these characters, but this will introduce more problems.

This is not just a problem in MySQL,the PG used in our project have The same problem, and it has been fixed and is currently in use online.

Our project testers initially discovered this issue and recorded a bug for us to fix. But this change is not elegant enough. We have to call this method every time. It would be great if it could be made into AOP or annotations

My concern is we escape the search condition will cause more bugs, I would prefer the user use the escaped keyword in front-end. On the other hand, we cannot escape all parameters, this bug only affect fuzzy query, if we escape all parameters will cause other method have bugs.

@shouwangyw
Copy link
Contributor Author

This caused by the specifical meaning of _ and % in mysql, there might exist other symbosl same with these. I didn't find out good idea to solve these problem, seems we need to escape these characters, but this will introduce more problems.

This is not just a problem in MySQL,the PG used in our project have The same problem, and it has been fixed and is currently in use online.
Our project testers initially discovered this issue and recorded a bug for us to fix. But this change is not elegant enough. We have to call this method every time. It would be great if it could be made into AOP or annotations

My concern is we escape the search condition will cause more bugs, I would prefer the user use the escaped keyword in front-end. On the other hand, we cannot escape all parameters, this bug only affect fuzzy query, if we escape all parameters will cause other method have bugs.

Front-end escaping maybe is not suitable, this change will only be used in like fuzzy queries, others that do not require escaping are also removed.

Copy link

sonarcloud bot commented Oct 29, 2024

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

Successfully merging this pull request may close these issues.

[Bug] [ApiServer] When querying list, like query with % not support special characher(% \ _)
4 participants