MongoDB connection remains open

[aramkarapetian]

Script execution never finished since connection remains open.
Tried to close connection calling destroy (which will remove sync handler from model too) but even that did not help.

var Word = require('../../models/word');
var assert = require('assert');

var word = new Word({asd: 'qwe'});

word.save({
  success: function(project) {
    debugger;
    return console.log("We're saved!");
  },
  error: function(project, err) {
    debugger;
    return console.log('Oh no an error');
  }
});

//Word.prototype.sync('destroy');

Am I doing something wrong here?

[aramkarapetian]

Also got question about backbone collections - cant see usage example. Looks like everything done via model and responses are arrays or I'm wrong?
(off topic, but cant find better places to put)

[kmalakoff]

Connections are pooled across requests. We use the commander CLI and once our scripts are executed call process.exit(0) from the final callback.

If automatic closing after each request is needed, I'd need to discuss with my co-author about exposing a non-pooling approach and we would want to test the set up and tear down impact. If an explicit release mechanism is required, we'd need to add some sort of reference counting to the pooling.

How would you rate each of these three solutions in terms of priority or need for you?

PS: we also use Node's callback pattern (rather than jQuery-style objects) since it is much less verbose:

word.save(function(err, project) {
    debugger;
    console.log(err ? 'Oh no an error' : 'We're saved!');
});

[kmalakoff]

As for fetching through collections, it is less useful with BackboneORM. You can find examples in the test: https://github.com/vidigami/backbone-orm/blob/master/test/generators/collection/sync.coffee

On the server, we typically just do model queries. In the browser, we tend to do is use model queries with Knockback's kb.CollectionObservable that auto-allocates a collection (a simplified example):

class MyViewModel
  constructor: ->
    @things = kb.collectionObservable({view_model: ThingViewModel})
    Thing.find { /* query here */ }, (err, things) => @things.collection().reset(things or [])

[aramkarapetian]

1. I presume ORM should take care of those kind of issues (by ORM I don't mean backbone-orm) so I'd prefer this work automatically and have configuration setting for pooling or closing after each request.
   That's more mongo client performance issue which I'm not quite familiar with.
   Hope this will be helpful for decision making.
2. Concerning collections I can tell that will need them and can't really see if Backbone supports that why ORM can't just use it and provide results in collections or at least let fetch data using collections and may be have it configurable since this is part of backbone.

[kmalakoff]

1. Makes sense. I'll need to look into the performance implications of this. I believe (but need to check) most database drivers pool connections.
2. Collections work. You can add query parameters to a Backbone.Collection's url and when you call fetch, it behaves just like normal Backbone.js (behind the scenes it uses the Model). I think we've retained all of the Collection functionality, but just added the possibility to use Node-style callbacks. For example:

class Things extends Backbone.Collection
  url: '/things'   # or yourDynamicQueryFunction('/things')
  model: Thing
  sync: require('backbone-http').sync(Collection)

class MyViewModel
  constructor: ->
    @things = kb.collectionObservable(new Things(), {view_model: ThingViewModel})
    @things.collection().fetch (err) => 

I was just trying to say that when we have been using BackboneORM, we tend to think in Model queries and use results in the form of arrays of models, individual models, JSON, attributes transformations ($values/$select) rather than collections. That's what drives the above pattern (we typically skip the extra boilerplate of defining a Collection)