detect and recompile report formulas on formula parser / serializer fixes

[dknochen]

if we discover a bug in the code generation of excel formulas then we need to recompile all formulas of a report at once. Right now, this is an admin and testing feature (using the /recompile page), but we need to integrate this in the complete picture.

Not sure, how to do it correctly at the moment (a version marker would work, I think). IMHO this should be completely transparent to the user. For this we would need to be able to detect whether a report needs to be recompiled or not.

[MatthiasBrantner]

I’m afraid this is a feature that helps us ignoring bugs in the code generation. Did you fix the bugs that triggered you having to use this script?

Matthias

On Jul 31, 2014, at 2:51 AM, Dennis Knochenwefel notifications@github.com wrote:

if we discover a bug in the code generation of excel formulas then we need to recompile all formulas of a report at once. Right now, this is an admin and testing feature (using the /recompile page), but we need to integrate this in the complete picture.

Not sure, how to do it correctly at the moment (a version marker would work, I think). IMHO this should be completely transparent to the user. For this we would need to be able to detect whether a report needs to be recompiled or not.

— Reply to this email directly or view it on GitHub.

[dknochen]

@MatthiasBrantner Yes, I fixed something in the code generation and - because of that - I had to recompile all formulas.

As formulas are only compiled when they are created or updated they remain unchanged even after such a fix. So, we need this feature to propagate fixes made to the code generation into the already compiled formulas and to be able to test those.

Does this make sense?

I'm not sure, I understood your comment? Could you explain, how it helps ignoring bugs?

[MatthiasBrantner]

I understand what you need this for.

The problem is that such a feature is adding black magic to the system. Even if it’s run automatically it’s very hard to maintain.

Here are the scenarios that I see:

1. A user creates a report that works and he is happy with it. That is, the rules work as he expects them. If there are no modifications to the report it will keep working as the user expects it to do.
2. A user creates a report and something doesn’t work as he expects it to because the rule compiler has a bug. In this case, he should contact us and we can look into the problem.
3. A user created a report that he believes works but we find out there is a bug. In this case, we can create a release and tell users that they need to upgrade their report to a new version. This could be an explicit action triggered by the user that is using functionality as you described. What is needed for this is a field in the report that tells the system/us which version of the code was used to generate the report.

Does this make sense? I’m not a believer of magic *-all scripts because I believe they introduce magic in the system, usually require a lot of code, and it’s hard to trace what is/was going on.

Matthias

On Jul 31, 2014, at 9:11 AM, Dennis Knochenwefel notifications@github.com wrote:

@MatthiasBrantner Yes, I fixed something in the code generation and - because of that - I had to recompile all formulas.

As formulas are only compiled when they are created or updated they remain unchanged even after such a fix. So, we need this feature to propagate fixes made to the code generation into the already compiled formulas and to be able to test those.

Does this make sense?

I'm not sure, I understood your comment? Could you explain, how it helps ignoring bugs?

— Reply to this email directly or view it on GitHub.

[dknochen]

@MatthiasBrantner thanks for clarifying. I see your point now and maintainability is a good argument.

So, overall, we agree that there needs to be a way to upgrade all formulas, correct?

If I do understand correctly, you would like to signal the user to upgrade the formulas (in case a new version was released) instead of upgrading automagically, which makes sense as it puts the user in control. The version marker solution would work here as well.

Alternatively (just as a brainstorming), we could get rid of the client side code generation completely and generate the code on-the-fly from the AST at runtime (then it depends on the project's platform version). Not sure what the performance penalty would be.

[MatthiasBrantner]

So, what do we do?

[dknochen]

I think, we should take the time to plan and discuss this in the team meeting. It is neither a blocking nor an urgend issue right now.