Closed mpitser closed 11 years ago
in mongodb PUT means update existing data, POST means add new data
currently updates to existing diameter entry are al sending POST requests. (should be PUT)
I have the same problem with DELETE too. I was trying to implement the method to remove a tree earlier. Backbone.js claims that model.destroy() will send an HTML DELETE request to the specified model.url. However, it does not seem that the Python script recognizes that my request is DELETE, not POST.
Right now I make do by adding an attribute to the tree object sent called 'delete', which is a boolean that tells the server that I want to delete this thing. It is a very not-neat and risky solution, however, and I hope to find a way to resolve this later.
I think I've found the root of the problem, which is that the model determines whether the request should be PUT or DELETE by detecting whether the model isNew. If the model isNew, then the model is not going to allow us to send a PUT or a DELETE method.
The isNew method is as simple as function() {return this.id == null;} That is, if the id field is empty, then the model is new (because the model would only have an id once it is stored in the database). The problem is, the current version of the application will always tell that the model isNew, thereby preventing us from sending a PUT or a DELETE method, because we do not really have the id field specified for our Tree model: MongoDB uses _id—which is an ObjectId—as the unique index, while the default of Backbone.js is id.
While the difference between the unique indexes in Backbone.js (id) and MongoDB (_id) can supposedly be remedied by setting idAttribute in the model to _id (on the Backbone.js), Backbone.js is not as smart as it claims to be, and nasty things start to happen when we use the _id field (which is an object) as idAttribute. (It does not seem to like it if we use objects as ids.) This problem has an ad-hoc solution: we can parse $oid within the ObjectId to a new field in the model.
Yet, new problems arise. See #21.
we think one needs to be sending a PUT request?