2

I have been working on a DJANGO back-end which main use case would be the capability to store a given set of pictures with its related tags.

The current design foresees dedicated REST-ful APIs for creating a new set, adding a picture to a given set and associating tags to a given set : this results into distinct client calls.

For instance :

BEGIN the "create new set" transaction

  1. create a new set and receive the set ID
  2. upload the first picture of the set
  3. upload the second picture of the set (And so on depending on the total number of pictures...)
  4. Add the tags related to this newly added set

END the transaction

How can I commit/rollback such a transaction knowing that it is split among different HTTP requests ?

Am I having a design issue here ? Shall I favor a single cumulative HTTP request approach ?

Please take into account that such a back-end is to be used with mobile devices which might suffer from temporary signal loss.

Any advice is welcome.

UPDATE:

Would it be convenient to use model versioning packages such as django-revisions to solve the issue ?

codeJack
  • 2,423
  • 5
  • 24
  • 31
  • 3
    Do you really need to solve this using a DB transaction? Why not do something like this: store the pictures in the database with some flag that denotes them as 'pending'. Use the HTTP session to keep track of the user's actions while uploading the set. When finished, remove the pending flags and add the tags. – rje Sep 17 '14 at 12:43
  • I have considered this approach as well, it would fit nicely for the "create a new set" transaction. But what about a "set update" transaction where for instance a picture is deleted or replaced ? I would not benefit from a real commit/rollback with flag-based "homemade" solutions, at least not smoothly and easily. Of course if no native "out of the box" solution exists I will consider implementing my own – codeJack Sep 17 '14 at 12:50

0 Answers0