I know this is probably a bad way to ask this question. I was unable to find another question that addressed this.The full question is this: We're producing a wrapper for a database and have two different viewpoints on managing data with the wrapper.The first is that all changes made to a data object in code must be persisted in the database by calling a save method to actually save the changes. The other side is that these changes should be save as they are made, so if I change a property it's saved, I change another it's save as well.What are the pros/cons of either choice and which is the proper way to manage the data?To provide more information, we're using Node.js, and we're writing our own wrapper for Neo4j because we feel that the current one available is not complete, or have run into issues where we need more functionality. That being said, an example of the save as you go method (these examples are in Javascript):// DB is defined as a connection to the database via HTTP(REST)// data being an object that would represent new datavar node;db.getNodeById(data.id, function(err, result) {  node = result;  // This function task an optional callback as a third parameter because in  // in addition to setting the property on the node object it saves the  // new value to the database by making an HTTP request.  node.set(firstName, data.newFirstName);  // auto saved as well  node.set(lastName, data.newLastName);  // end here as the node has already been updated with your changes.});And the opposing example would be:// DB is defined as a connection to the database via HTTP(REST)// data being an object that would represent new datavar node;db.getNodeById(data.id, function(err, result) {  node = result;  // This changes the value for the node object only, nothing in the  // database is changed.  node.set(firstName, data.newFirstName);  node.set(lastName, data.newLastName);  // Save all your changes  node.save();});
Which is a better design pattern for a database wrapper: Save as you go or Save when you're done?
design patterns;database
If you need transactions in your application, you will need to offer some kind of explicit Save option.   If the applications don't need transactions, using a database (as opposed to, say, a NoSQL technology) may be redundant.This also means that the Save operation should not be a method called on the mutated object.   It should be a method on the transaction object, or the session. 