Adam Shimali d14be2067c 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.

2016-04-21 18:10:57 +01:00

..

app

When using the versioned decorator I noticed that when adding or

2016-04-21 18:10:57 +01:00

__init__.py

bumped client version

2016-02-09 18:48:02 +00:00

conftest.py

Update limit to message_limit.

2016-04-11 16:53:40 +01:00