Denis Walker

Dry-Run Testing in the RIPE Database

Denis Walker
2 You have liked this article 0 times.

Have you ever wanted to test an update to the RIPE Database, without actually changing anything in the database? Well now you can "dry-run" it - see what will happen without changing anything.


We have always suggested that if you want to "try" an update to see what happens, you should do so in the TEST Database. But the TEST Database is a sterile land with hardly any data in it. We also reset it every day. So if you want to test anything that has dependencies on other data you have to reproduce it all in the TEST Database to do the test. That in itself can be a major effort. And tomorrow it is all gone.

To address this, we have introduced a simple new feature - "dry-run" - that lets you test updates on the production RIPE Database. All your data is there. All dependencies are taken care of. Submit your update and see what the result will be. But nothing actually changes. It is perfectly safe.

How do I use it?

Submit an update by any update method: Syncupdates, Webupdates, REST API or email. At the moment we can only process a single object in the update. To handle multiple objects in using "dry-run" could be done, but it would require much more work to set it up. If the interest is there we can add this later.

Enter whatever you want for this single object. Use the correct syntax or include deliberate errors, full set of credentials or not - it all depends what you want to test. Somewhere in the update enter the "dry-run:" pseudo attribute on a new line:


It does not need a value, but if you add any text it will be ignored. It can be anywhere in the update message, just as "password:" can be. Then submit the update.

What happens?

The update is received by the RIPE Database production software. We do all the checks on it:

  • Syntax
  • Business rules
  • Authorisation
  • Referential integrity

Then we stop! Nothing is changed in the RIPE Database.

What do I see?

An acknowledgement message is returned to the user who submited the update by the normal channels, depending on the input method used. No notifications are sent. So only the user who is testing the update gets the results. For a dry-run update that would modify an object, the diff output that would normally be in the notification message is added to the dry-run acknowledgement message. This helps to show what would be changed by an actual update.


What if...? What would happen...? How would it look...? Would this work...? These type of questions can now be answered by a simple dry-run update. Why not give it a try and see if it is useful for you.

Please let us have some feedback below, good or bad - we would like to know what you think!

2 You have liked this article 0 times.

You may also like

View more

About the author

From 2001 to 2015 I was a developer and then the business analyst for the RIPE Database with the RIPE NCC. During this time I have been involved in every aspect of it's design and development of the software, web services and infrastructure, it's philosophy, legal, political and policy aspects, documentation, testing and future planning and specifying of new features

Comments 3