Skip to main content

The functionality weaver offers a lot of benefits for writing and maintaining code:

  1. Offering dynamic weaving.
  2. Code history.
  3. Code review and managing who wrote which code.
  4. Validation while executing the query on the database.
  5. Changing code without syncing to IAM.

These benefits do not apply for expression fields. Expression fields are widely used but the support for maintaining them is very limited.

My idea for expression fields 2.0 is as follows:

  1. New codegroup and program object type: EXPRESSIONS.
  2. New type of program object: EXPRESSION. Naming: exp_<table_name)_<col_name>.
  3. For every program object of type EXPRESSION a function is generated.
  4. PK colums are given as parameters to this function.
  5. Templates are used with these parameters to return a value. 
  6. The GUI executes the function instead of the expression query specified on the column.
  7. The expression field query on table “col” is no longer needed and can be discarded since calculated_field_type = expression generates a program object.

Let me know what you guys think. 

 

Would like to include SQL prefilters as well. Same reasoning.

I strongly disagree with step 3 if you mean this should create an actual SQL function (table or scalar): 

"For every program object of type EXPRESSION a function is generated."

not only will the function slow down your SQL query it will also mess up the execution plan. I think it would be better to translate the function to a sub select or a join (cte or regular join). 

Reviewing not only expression and prefilter queries but all aspects of an applications model is something we want to provide in the future by reviewing branches. 

Terms & ConditionsCookie settings