-
Notifications
You must be signed in to change notification settings - Fork 353
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
Make D2 dates related functions SqlBuilder aware (DHIS-16705) #19380
Conversation
There was a problem hiding this 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 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Call it DateUnit, maybe?
There was a problem hiding this 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(); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Quality Gate failedFailed conditions See analysis details on SonarQube Cloud Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE |
There was a problem hiding this 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(); |
There was a problem hiding this comment.
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.
Summary
This PR enhances the integration of the
SqlBuilder
with the Antlr parser context and updates D2 functions to utilize the newly introduceddateDifference
function.Changes
dateDifference
function within theSqlBuilder
for improved date manipulation.D2*Between
functions to incorporate theSqlBuilder
for uniform processing.