When using the versioned decorator I noticed that when adding or

revoking an api key the service it associated with was of course added
to db.session.dirty.

That resulted in an updated version of service being added to the
service history table that showed no visible difference from that
record immediately precending it as the change was to another table,
namely the api_key table. A new api key or revoked api key was correctly
added to api_key and api_key_history tables. However I think an
'unchanged' service history record may be a bit confusing as you'd need
to correlate with api_keys to work out what the change was.

I think it's best to just record the new/revoked api_key and not create
another version of the service.

This pr wraps the exisiting versioned decorator with one that take a
class which you are interested in versioning.

Using the new decorator you only get a new version and history record
for the class you pass to outer decorator.

If the exising behaviour is acceptable to the powers that be then by all
means ignore/close this pr.

tests/app/dao/test_api_key_dao.py

@@ -111,3 +111,18 @@ def test_should_not_allow_duplicate_key_names_per_service(notify_api,
         fail("should throw IntegrityError")
     except:
         pass
+
+
+def test_save_api_key_should_not_create_new_service_history(notify_api, notify_db, notify_db_session, sample_service):
+
+    from app.models import Service
+
+    assert Service.query.count() == 1
+    assert Service.get_history_model().query.count() == 1
+
+    api_key = ApiKey(**{'service': sample_service,
+                        'name': sample_service.name,
+                        'created_by': sample_service.created_by})
+    save_model_api_key(api_key)
+
+    assert Service.get_history_model().query.count() == 1