- Job Vacancy: Senior PM at Foolproof
- Job Vacancy: Programme Manager at Foolproof
- Job Vacancy: Senior Designer at Foolproof
- Job Vacancy: Account Manager at Foolproof
- Job Vacancy: Software Engineer in Test at Axon Vibe
- Job Vacancy- EIRA Knowledge Exchange Fellow – EIRA Network (3 Posts)
- Job Vacancy- EIRA Knowledge Exchange Manager (Three Year Fixed Term Contract)
- Job Vacancy- Front end developer at Zipline
- Job Vacancy- Data Architect at Axom Vibe
- Job Vacancy- Digital Marketing Manager
Pattern: Single CrUD Transaction
Software Patterns became popular with the publishing of the Gang of Four book, “Design patterns: elements of reusable object-oriented software” (ISBN-13: 978-0201633610) in 1994. It contains a number of patterns, most of which every developer should know, even if it’s to know to avoid the likes Singleton. However, these aren’t the only patterns! Indeed, patterns are not created, they are discovered and documented. Whole conferences are dedicated to software patterns (http://www.europlop.net/), where delegates are encouraged to bring their pattern write-ups for appraisal by their peers and the experts.
In 2000 I joined the ACCU, a group for programmers who strive for better software. I was encouraged by another member to write for the group’s magazine, but I didn’t think I’d have anything to contribute that someone better hadn’t already thought of and written about. As I gained experience I found I had quite a lot to write about and to challenge.
In the same way you’d have thought that 23 years after the Gang of Four book most if not all of the software patterns had been discovered and documented. However, it appears not and I was very surprised to find that what I’m calling the “Single CrUD Transaction” pattern, although used by many, doesn’t appear to have been written up anywhere publicly. I checked with industry experts and they weren’t aware of it being written-up either.
This is my first software pattern write up and where better to share it for the first time than Norfolk Developers Magazine?
Single CrUD Transaction
To create, update and delete items in a datastore within a single transaction.
Sometimes it’s necessary to create, update and delete items in a datastore in a single transaction. Traditional web applications support create, update and delete in separate transactions and require the page to be reloaded between each action.
Modern web applications allow the items of a list to be created, updated and deleted in a browser without any interaction with the server or the underlying datastore. Therefore when the list is sent to the server side it must determine which items are new, which already exist and must be updated and which have been removed from the list and must be deleted.
One simple solution is to delete all of the items from the datastore and simply replace them with the list of line items passed from the browser to the server. There are at least two potential drawbacks with this approach:
- If the datastore (such as a relational database) uses unique, numerical ids to identify each item in the list, the size of the ids can become very big, very quickly.
- If the datastore (such as a relational database) has other data which references the ids of the items in the list, the items cannot be deleted without breaking the referential integrity.
The Single CrUD Transaction pattern gets around these drawbacks by performing three operations within a single transaction:
- Delete all of the list items from the datastore whose ids are not in the list passed from the browser to the server.
- Update each of the items in the datastore whose ids match ids in the list passed from the browser to the server.
- Create new items in the datastore for each item in the list passed from the browser to the server which do not yet have ids.
Each action is executed within a single transaction so that if any individual action fails the list is returned to its original state.
Use the Single CrUD transaction pattern when:
- Datastores cannot have new items added, existing items updated and/or items removed in separate transactions.
- Creating new ids for each item in the list each time the datastore is modified is expensive or cumbersome.
- Removing all the items of a list from a datastore and recreating the list in the datastore breaks referential integrity.
Advantages and Disadvantages
- Entire update happens within a single transaction.
- Three separate calls to the datastore within a single transaction.
Originally published on Naked Element
Words by Paul Grenyer