Allow Developers to commit changes with an Advanced Query, by writing commit.

Aggregates & Queries

Up to very recently, developers were able to write a 'Commit' statement in order to have changes in the database done without publishing, as such:

Although the 'Test' feature is temporary, and rolls the changes back, because there was a commit statement, these changes would be permanent. Which meant a developer could do hot fixes without publishing. 

This ability was removed, probably as a security measure. 

I understand that this may pose a serious risk in Production Environments, but it was already possible to block the test feature entirely, and thus block the 'Commit' injection with it. So before, we had two choices.

Allow the test feature + Commit ; Don't allow the test feature ( which blocks Commit )

Now we have:

Allow the test feature ( But don't allow a commit ) ; Don't allow the test feature.

If security was the main issue, blocking the Test feature itself should solve it right?

Our alternative is to create a screen, and put the hot fixes on actions. Is there any difference between creating a screen, publishing it, running the action, deleting the screen and publishing again; and Testing a query with commit?

Looking forward to hearing from you.

Created on 5 Dec 2019
Comments (9)

There is another difference. Allow Testing allows to Test. Delete is not as important as testing queries.

BeforeCan Test QueryCan See DataCan Change Data
Allow TestYesYesYes
Don't Allow TestNoNoNo

NowCan Test QueryCan See DataCan Change Data
Allow TestYesYesNo
Don't Allow TestNoNoNo

I understand you miss that feature (I read it in the forum and heard it on the User Group from several people) but there are different issues here.

You may block Test Data to protect client privacy. That's it. There is awareness that data can't be used.

When you do a Commit, there is no registry on OutSystems of how the data disappeared. The query was tested and deleted. It was a mistake? No one saw.

If you are forced to publish a page/action, you leave a trail. There is awareness that a page exists where data can tampered. Not only you think twice before pressing the Run Query, but the page itself can validate what type of query is running.

For me, that page makes as much sense as the custom CRUD actions where you save dates and users automatically, create a log of interactions and validate the data and the operation.

Some businesses may not need it, but it is a best practice.

Indeed, a trail of evidence is left when publishing the screen.

 If that is the only thing keeping a Commit instruction from being a feature, perhaps a trail can be added. Whenever you test a query, a log can be created saying user X ran Query: 'XXXXX' at YYYY-MM-DD HH:mm:ss.

I understand the security issue, but hopefully a middle group can be reached where the development team can still manipulate the database without publishing. 

Removing it makes sense for a production environment where you need to leave a trail of evidence that you tampered with data, but for a Dev or Tst environment not having this feature is doing more harm than good, I mean how often you need to delete data from a table because you created a bug? or you created a field that was text but you want to convert it to integer now?
Now we have to create a screen, with a button and a screen action just to fix this, or a timer and run it... 

Now I miss this feature. I think it’s a very useful in lower environments.

+1, OutSystems, please make our work more easy not more difficult. 

+1 for the idea. Good one.

Maybe have it only on environments that aren't in production mode.

The Forge has this great component SQL Sandbox created by Leonardo Fernandes, that allows you to execute SQL statements directly on the Platform Database. It even allows you to do so on External Databases.

Check it out if you haven’t already!



Changed the category to Aggregates & Queries