Which is a better design pattern for a database wrapper: Save as you go or Save when you're done?

Question

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 data
var 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 data
var 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();
});

Answer 1

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.

Answer 2

I'd go for explicitly calling the save() method. Otherwise you'll get redundant saves when you don't need them. What if you have some sort of "onKeyUp" event. Do you really want to save as the user is typing each character? You'd be locked into that model.

In a multi-tiered app it's good for the code to be "aware" of the tier it's on. You don't need to hide it by having a bunch of state saving magic going on behind the scenes. Why is being "aware" good? Because hiding it is obfuscating how it works, not abstracting. (my opinion).

On another topic...... instead of Node.save(); use save(Node n); Actually save could still be a method of an object, just not the Node object. Why? Saving is not something that a node does. And this functionality literally is different depending on which tier your on, suggesting it's a behavior of the tier, not the node.

For example lets say you have Node.Draw(); This method doesn't even make sense on the serverside. Instead do something like GameBoard.Draw(Node n);

I'm probably getting too far off topic, but that's my 2 cents.

Answer 3

This post is old, but I had the same issue with respect to an inventory management project my company is building. It's a web-based PHP application with a PostgreSQL backend. We opted for the Save-As-You-Go approach as opposed to a Stage-and-Commit style (I borrowed the terms from version control because it's accurate here), because we want to offer feedback to the user immediately if there's an issue saving a record update to the actual database. Waiting until the script is closing and destructors are being called to finally discover there's an issue with saving all the user's changes was an unacceptable risk (given the complexity that our transactions can have). The drawback might be increased database traffic, but the user can know rather than hope that his changes have been made correctly. Those are the pros and cons I considered when answering this question for myself. Hopefully my answer will assist somebody else too.