Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

EDIT

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();
});
share|improve this question
    
The "save as you go" sounds extremely counterproductive, care to expand a bit on how that would work? Or perhaps provide some references that explain the approach? –  Yannis Rizos Apr 3 '12 at 23:34
1  
Also, sometimes if you don't want to lose data but don't want bad data either you can save to some sort of "staging area" then commit it, but whether and how this works is pretty application specific. –  psr Apr 3 '12 at 23:41
    
@YannisRizos I gave examples of both, as they would be used. I'm not quite sure exactly how to explain the process. I can think of it clearly but not really describe it. –  izuriel Apr 3 '12 at 23:59
    
@psr I think in practice that fits our final save action, all changes made exist on the object in memory until you call the save which will commit those changes to the database. But I disregarded the first part of you comment, these changes will be lost as soon as the object is deferenced in memory. –  izuriel Apr 4 '12 at 0:00
1  
Considered using a standard O/R mapper? –  user1249 Apr 4 '12 at 9:11
show 1 more comment

2 Answers 2

up vote 5 down vote accepted

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.

share|improve this answer
1  
+1. If you aren't grouping data together in a way that makes save-as-you-go impractical, you probably don't need a DB. –  Mason Wheeler Apr 4 '12 at 0:12
    
Thanks for the answer! –  izuriel Apr 4 '12 at 2:03
add comment

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.

share|improve this answer
    
Thanks for you answer, despite going off topic I found it informative. –  izuriel Apr 4 '12 at 2:03
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.