Raise on write conflict in save

Create issue
Issue #5 resolved
Jean-Tiare Le Bigot created an issue

The current way to prevent accidental overwrite of the database item is to provide a set of "expected values". This implies to keep track of the original values on the user model side especially when a migration is involved.

To adress this, we will:

remove the 'expect values' argument

add a "raise on conflict flag" to replace it.

Comments (6)

  1. Éric Araujo

    I just found a use case for the expected_values argument: In a CMS for QA people, I’d like to have a form to edit a challenge object but would like the view to fail, not to retry like a transaction, if the item was edited between GET form and POST change. I was thinking of putting the value in a hidden form field and pass that as expected value in the save call.

  2. Éric Araujo

    Actually, I’m going to do get-change-save, not from_dict-save, so I don’t need the expected_values argument, I’ll do a check before that (just after the get, I’ll check that the field is the same as the hidden form field), so hidden _raw_fields + raise_on_conflict param works for me.

  3. Jean-Tiare Le Bigot reporter

    In the draft implementation, I introduced a ``from_db_dict`` method used internaly by the mapper. Whenever this helper is called, the raw dict is backed-up for the "raise on conflict" feature. It should bring the best of both worlds :)

  4. Log in to comment