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

Make D2 dates related functions SqlBuilder aware (DHIS-16705) #19380

Merged
merged 5 commits into from
Dec 5, 2024

Conversation

luciano-fiandesio
Copy link
Contributor

Summary

This PR enhances the integration of the SqlBuilder with the Antlr parser context and updates D2 functions to utilize the newly introduced dateDifference function.

Changes

  • Introduced a dateDifference function within the SqlBuilder for improved date manipulation.
  • Updated D2*Between functions to incorporate the SqlBuilder for uniform processing.
  • Added unit tests for all modified expression classes.

Copy link
Contributor

@maikelarabori maikelarabori left a comment

Choose a reason for hiding this comment

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

Looks good 👍
Minor suggestion added.
Thx!

@@ -422,4 +443,12 @@ public interface SqlBuilder {
* @return a drop catalog if exists statement.
*/
String dropCatalogIfExists();

enum DatePart {
Copy link
Contributor

Choose a reason for hiding this comment

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

Call it DateUnit, maybe?

Copy link
Contributor

@gnespolino gnespolino left a comment

Choose a reason for hiding this comment

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

Good job, just a minor comment

@@ -126,7 +126,7 @@ public DefaultProgramIndicatorService(
this.analyticsSqlCache = cacheProvider.createAnalyticsSqlCache();
this.sqlBuilder = sqlBuilder;

this.programIndicatorItems = new ExpressionMapBuilder(sqlBuilder).getExpressionItemMap();
this.programIndicatorItems = new ExpressionMapBuilder().getExpressionItemMap();
Copy link
Contributor

Choose a reason for hiding this comment

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

I’m curious — was there a particular reason we opted not to use dependency injection in this case?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Bit of a long story, in reality this new ExpressionMapBuilder is no longer needed, because @jimgrace showed me a better/simpler way to access the SqlBuilder. But since it was there, I figured that we can keep the list of expressions encapsulated into its own class, and yes, this could use DoI. Not sure, shall I just get rid of ExpressionMapBuilder altogether?

Copy link
Member

Choose a reason for hiding this comment

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

I think it's OK. In DefaultExpressionService these maps are still generated in the service (for all the expression types that are not program indicators), so this is not consistent with that. But all this ANLR code will be ripped out when we transition to Jan B's new parser. (Did you know about that?) I'm OK with keeping it as a separate class or putting it back where it was.

Copy link

sonarcloud bot commented Dec 4, 2024

Quality Gate Failed Quality Gate failed

Failed conditions
6 New issues
6 New Code Smells (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

Copy link
Member

@jimgrace jimgrace left a comment

Choose a reason for hiding this comment

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

Some code will also need to change at some point under org.hisp.dhis.parser.expression if Doris follows MySQL syntax rather than Postgres. Classes I've noticed in a quick review that will need changing are:
FunctionContains
FunctionContainsItems
OperatorMathPower

@@ -126,7 +126,7 @@ public DefaultProgramIndicatorService(
this.analyticsSqlCache = cacheProvider.createAnalyticsSqlCache();
this.sqlBuilder = sqlBuilder;

this.programIndicatorItems = new ExpressionMapBuilder(sqlBuilder).getExpressionItemMap();
this.programIndicatorItems = new ExpressionMapBuilder().getExpressionItemMap();
Copy link
Member

Choose a reason for hiding this comment

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

I think it's OK. In DefaultExpressionService these maps are still generated in the service (for all the expression types that are not program indicators), so this is not consistent with that. But all this ANLR code will be ripped out when we transition to Jan B's new parser. (Did you know about that?) I'm OK with keeping it as a separate class or putting it back where it was.

@luciano-fiandesio luciano-fiandesio merged commit b59d156 into master Dec 5, 2024
15 of 16 checks passed
@luciano-fiandesio luciano-fiandesio deleted the DHIS-16705_D2_DATE_EXPRESSIONS_SQLBUILDER branch December 5, 2024 07:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
run-api-analytics-tests Enables analytics e2e tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants