Skip to content
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

Provide a dry run #79

Open
gruberrolandvaltech opened this issue Oct 31, 2018 · 1 comment
Open

Provide a dry run #79

gruberrolandvaltech opened this issue Oct 31, 2018 · 1 comment

Comments

@gruberrolandvaltech
Copy link
Contributor

It would be great if Groovy Console could provide a dry-run method. So some second button to run the script without saving any changes.

This could be done by using a wrapper around the used ResourceResolver and its session object. This could then ignore calls to resolver.commit() and session.save().

On the other hand, for non-dry-runs the session.save() could be called directly by Groovy Console. This way there is no more need for session.save() at the end of all scripts.

Bindings also need to know about the dry-run. So the information needs to be provided to them, too.

@paul-bjorkstrand
Copy link
Contributor

A pattern I often used was creating a SAVE field at the top of the script you can use @Field to make this available everywhere in the script.

Once I had a version with the data section, I added some JSON, that included that flag, and read it (safely, using ?.) from the data, and set my @Field annotated script variable, then do

if (SAVE) {
    save()
}

I use "SAVE" instead of "DRY_RUN" because of the psychology behind it: you must actively decide to save. With "DRY_RUN", you must actively decide to NOT save. With, "SAVE", if you forget to set the variable, then it doesn't save. You change the variable and re-run the script. With "DRY_RUN", if you forget to set it to true, you start accidentally saving, causing potential data corruption.

It takes some thinking when developing the script, but this is the easiest pattern to use right now. It maybe nice to have some global option (like a checkbox or something), but there are plenty of workarounds. I recommend taking a stab at implementing it yourself, if you want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants