[POLL] What is your preferred collection update strategy?


#1

Coming from years of experience with ORM’s in the javaee world, where it is almost an abomination even to think of directly updating a database table/colllection without at least 3 layers of abstraction in between, I had found Meteor (node, javascript, whatever, I’m not pointing fingers) very liberating when I first met it.

As we now progress from the magical to more structured programming with components, imports, classes, schemas and whatnot, I keep needing to revisit how I am manipulating my data.

On the one hand, we can do

Things.update(thingId, { 
  $set: { foo: "bar" }, 
  $unset: { baz: "" }, 
  $inc: { qux: 1 },  
  $push: { quux: "corge" } 
})

which is very straightforward, does not require us to grab the document and deal with updates to the other fields in the time we fire off our own update statement.

On the other hand we can do (perhaps Astronomy is our only viable choice here to manage this properly, but the code below is just pseudo, not astronomy)

Thing = Things.findOne(thingId) // Thing is an instance of a class
Thing.set("foo", "bar")
Thing.save() // a method that the ORM provides us where it does validations followed by a collection update

This second approach is harder to manage, feels like more boilerplate code, but it has one great advantage of providing you with a complete snapshot of the document, thus allowing you to do better validation and other orm-wise important data manipulation/calculation.

But there is a small problem with this, where the data on the client and server may be different (we may have trusted data on the server, or some server-only secret data) so there may be some subtleties involved.

Anyway both approaches of course have more pros and cons than the few I mentioned here.

So what do you guys prefer?

Mind you this is not a simple schema (collection2) vs astronomy question! Whatever you use for the implementation, I wonder what your strategy is.

Now I know this is not an either/or topic, but please vote for the one you use the most, even though you occasionally prefer the other (but I tried to provide the gray area options anyway):

  • Pull up the doc, update props of the doc, overwrite it back as a whole
  • Update props directly (set, push, inc etc)
  • I use both depending on usecase (please comment below to elaborate)
  • I’m torn in between and would like some best practice to emerge

0 voters

Of course I’d also be very happy if you can also elaborate by your comments.

PS: There may be an argument that there should be other options provided in the poll, like event sourcing / cqrs but let’s add that option if more than a few people object to its exlusion.

PPS: Some may argue even collection2 takes the orm-like approach with autoform, because especially arrays are hard to deal with, without knowing the full document - at least the array itself as a whole, but that’s a specific case, so does not demonstrate its overall strategy.


#2

The second approach could cause race conditions in a multi-user environment, couldn’t it? i.e. if two or more users want to modify the same document at the same time, they all get the same copy of the document, change it, then save it. The result may be that only the last save applies.

Though I have had to use such an approach in some cases because $inc and aggregate operators in MongoDB are imprecise for monetary calculations.


#3

I’d say that set, push, inc make up probably 90% of what I do. But also, it’s sometimes convenient to grab the doc, run it through a function and overwrite the original. Usually that happens using methods that can only be called by the server, though.


#4

@tab00 that’s a problem that did exist since the dawn of persisted data and it certainly has many solutions, granted updating data on the fly mitigates most of that specific problem.

@vigorwebsolutions yeah, the methods are an interesting place to work within and I quite like that myself.

But still, having boo booed direct data manipulation for years in favor of layers of abstractions and domain objects, I find this sudden u-turn somewhat interesting.

Is there an elephant in the room? Do I just get over it and enjoy the freedom?


#5

Haha, I feel the same way sometimes. I have fields to track the userids/dates of creation, modification, etc. and sometimes I feel like I should be stamping the docs with the method names too.


#6

You’ll need a ladder :smile:


#7

Haha, a tall one indeed :slight_smile:


#8

@sproleee @copleykj would you guys like to tell us about your experience, pros and cons you feel you have with the orm-like approach?


#9

Sure, for me the ORM approach works amazingly well since I perform almost all of my db operations client side and the document is generally published there anyway.


#10

Wow, you’re lucky to have a project like that, and it is indeed a very compelling reason to utilize orm-goodness! Thank you @copleykj for your comment.