Open delgadom opened 7 years ago
Since we don't use response objects like this internally, it feels a bit weird to create them artificially. @jrising we currently have a log function in the works - see #178.
You can also access an object's history more programatically with get_history, which returns a list of dictionary objects containing version metadata. What do you think?
Maybe there can be a get_last_status
function? The problem with that is that it's pretty easy to miss updating the internal information for that when adding a new function, and then confusion ensues.
I see two potential problems with querying get_history. First, it seems like that is designed to return the whole history, which seems like it could be a big database query when otherwise no query is needed. Second, how should I determine if the most recent call to archive.update
bumped the version or not?
Yeah this does seem like an issue - it would be nice to be able to do something along the lines of
>>> res = archive.update('my_file.txt', response=True)
>>> assert res['status'] == 'success' # or
>>> assert 'bumped' in res['result']
I'm upgrading this to a todo for the next minor release. thanks @jrising
Since we'll have to construct the response, any votes on what you want it to look like?
Just a placeholder for @jrising's suggestion -
Maybe we could return a response object for archive actions giving the final effect? This could have information about version bumping, archive creation/deletion, etc.
I like the fact that our read/write operations are silent, just like regular file operations. Maybe the response object could be returned if an optional flag is used?
Possible UX