-
Notifications
You must be signed in to change notification settings - Fork 4
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
Show SQL mode with pretty print SQL statements #131
Comments
@ftrotter I have completed the first part of this, adding the route, view and configuration to display the formatted SQL. I have not added buttons to the views yet. With Array: If not enabled (config options exist both on report and in config/zermelo.php): |
I have created issue #134 for the work on the views |
The current implementation of this seems entirely dependant on the report value of isSQLPrintEnabled() It this is "true" the SQL view will work even if the configuration value is set to "false". |
Yup, totally dumb. There should be a guard in the controller so it can’t be overridden in the model. Thanks @ftrotter ! |
the folks at doctrine have a nice SQL formatter tool:
https://github.com/doctrine/sql-formatter
And they are slowly working to ensure that some of my requests are met (I stronly prefer forcing the SQL commands and functions to be upper case).
I would like to have a url for every report that instead of showing the data view shows the SQL view.. Something like:
https://example.com/ZermeloSQL/ReportName/arg1/arg2?something=this&also=that
Which pretty prints the SQL that would have been generated from any of the following:
https://example.com/Zermelo/ReportName/arg1/arg2?something=this&also=that
https://example.com/ZermeloCard/ReportName/arg1/arg2?something=this&also=that
https://example.com/ZermeloGraph/ReportName/arg1/arg2?something=this&also=that
It just calls the report and gets all of the SQL that would be generated. The system should be smart enough to display an array of SQL when that is what is returned by the original report.
There should also be a configuration parameter at both the report and the configuration level to turn this functionality off, and the tool should ship with this turned off by default in both places. To do otherwise would be a tremendous security risk.
But for intranet deployments like ours I can see it being always on...
Regular reports should be "aware of" the fact that "showing SQL" is an option when it is turned on (in both the report itself and in the global config) and present a link "show the SQL that made this report". Ah, even the thought sounds glorious.
The text was updated successfully, but these errors were encountered: