Thanks for the issue @edwardmsmith! What are you doing in your success callback? Is this something that's easily worked around by filtering the new models out? Also, this appears to be a server-side project. Could you describe briefly how you're using Backbone models?

In async.parallel, each a callback function is passed to each job, and you execute that callback to inform async that job has completed (either successfully or with an error, depending on whether you pass an error or not). The callbacks from each "job" is collected, and when they have all returned, the final callback (the 2nd option to async.parallel in the code snippet) is executed, passing the results of each job as an array.

Async can be used either on the server or on the in the browser - in our case, we're attempting to write our code so that it runs in both environments.

It is easily worked around (yet, not as elegant as it could be) by testing whether the model is new or not:

                jobset = []
                myCollection.each (pd) ->
                    jobset.push (cb) ->
                        # if this has never been saved, then "success" is not called
                        # on destroy, so we just destroy it and trigger the cb.
                        if pd.isNew()
                            pd.destroy()
                            cb null, pd
                        else
                            pd.destroy
                                success: (model,response) ->
                                    cb null, model
                                error: (model, response) ->
                                    cb response, model
                async.parallel jobset, (err, results) ->
                    cb err, results

In this specific case, think of the collection as a garbage can - The user is working with a set of models retrieved from the server, and additional models created on the client - but not yet persisted. The end result is a couple of collections - things to delete and things to create/update. This collection is the set of things to delete - some of them are "new" in that they have not been persisted and some of them were fetched from the server - but in each case, we don't want them any more.

So, as I said, I can see both sides of the argument, and the 'workaround' is not onerous, but its not as elegant as it could be.

Thanks for the use case. I don't see any reason why the success callback shouldn't be called, but I haven't really done extensive work with destroying new models.

@jashkenas Is there any reason not to execute the success callback for new models?

Yep -- it's silly to call destroy on a new model in the first place, and probably indicates a bug in your application logic. But still, I don't see the harm in triggering the success callback, if one is passed.

After looking at the code, it actually makes destroy a bit more straightforward (obviates the need for triggerDestroy), besides being nicely consistent. I'll submit a patch for it later on.

@jashkenas - "it's silly to call destroy on a new model in the first place, and probably indicates a bug in your application logic" - can you explain more? It makes perfect sense to me.

You really find it hard to conceive of a situation where an app may generate a number of un-persisted models, which get added to various collections, and are used in various views, and at some point the app might want to dispose of them in an orderly way?

You make a lot of these opinionated statements about a library that you've worked so hard to be "non-opinionated".

You make a lot of these opinionated statements about a
library that you've worked so hard to be "non-opinionated".

I'm just trying to be helpful with the semantics here. destroy means: delete a model from the server -- just like save means: persist a model to the server. If your application knows that a model does not exist on the server (yet), then trying to delete it from the server is an error.

To remove an un-persisted model, just call remove.

That works if all I want to do is remove a model from a collection, but to me, "remove this model from a collection" and "destroy this model" are semantically VERY different, and, in my opinion, 'destroy' is just as conceptually valid on a non-persisted model as it is on a persisted model.