No Collection.save() #584

Closed
stuartmemo opened this Issue Dec 31, 2012 · 7 comments

Comments

Projects
None yet
7 participants
@stuartmemo

Apologies if there's a reason this isn't included, but I'd like to see MongoDB's save method (insert/update combined) available in Meteor.

Thanks!

@AjayMT

This comment has been minimized.

Show comment Hide comment
@AjayMT

AjayMT Dec 31, 2012

Meteor uses minimongo, not the complete mongoDB. As of now, I don't think minimongo supports all of mongoDB's methods, operators, and modifiers. That might be why you can't use methods like 'save()' on collections.

Ajay Madhusudan
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Monday 31 December 2012 at 8:35 AM, Stuart Memo wrote:

Apologies if there's a reason this isn't included, but I'd like to see MongoDB's save method (insert/update combined) available in Meteor.
Thanks!


Reply to this email directly or view it on GitHub (#584).

AjayMT commented Dec 31, 2012

Meteor uses minimongo, not the complete mongoDB. As of now, I don't think minimongo supports all of mongoDB's methods, operators, and modifiers. That might be why you can't use methods like 'save()' on collections.

Ajay Madhusudan
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Monday 31 December 2012 at 8:35 AM, Stuart Memo wrote:

Apologies if there's a reason this isn't included, but I'd like to see MongoDB's save method (insert/update combined) available in Meteor.
Thanks!


Reply to this email directly or view it on GitHub (#584).

@gschmidt

This comment has been minimized.

Show comment Hide comment
@gschmidt

gschmidt Jan 12, 2013

Member

Hey Stuart, supporting save() is a good idea. Originally we didn't do it because save() requires the upsert to update(), which we currently don't support. (In an upsert, the database sometimes has to autogenerate an _id. That's a problem for apps that want to use strings for _ids instead of ObjectIds for _ids, which is most Meteor apps. Also, in Meteor, the _id for inserts is chosen by the client so that you can have it immediately without waiting for a round trip.)

But, good news. We just spent a while thinking about save() and realized that even though it depends on upsert, it can never result in the server autogenerating an _id, because it only does an upsert when the _id is already known. And, while thinking about that, we realized that upsert itself could be implemented (reasonably efficiently, even) by using a Mongo server-side eval. So we plan to do both of these things, but it could be a few months until we get to it because we're just swamped right now. Though we would take pull requests (from someone who understands how the insert/update path works well enough to fit it in correctly next to the other operations.)

Anyway, thanks a lot for filing this and getting us thinking about these subjects. It would be really cool to finally get upsert implemented.

Member

gschmidt commented Jan 12, 2013

Hey Stuart, supporting save() is a good idea. Originally we didn't do it because save() requires the upsert to update(), which we currently don't support. (In an upsert, the database sometimes has to autogenerate an _id. That's a problem for apps that want to use strings for _ids instead of ObjectIds for _ids, which is most Meteor apps. Also, in Meteor, the _id for inserts is chosen by the client so that you can have it immediately without waiting for a round trip.)

But, good news. We just spent a while thinking about save() and realized that even though it depends on upsert, it can never result in the server autogenerating an _id, because it only does an upsert when the _id is already known. And, while thinking about that, we realized that upsert itself could be implemented (reasonably efficiently, even) by using a Mongo server-side eval. So we plan to do both of these things, but it could be a few months until we get to it because we're just swamped right now. Though we would take pull requests (from someone who understands how the insert/update path works well enough to fit it in correctly next to the other operations.)

Anyway, thanks a lot for filing this and getting us thinking about these subjects. It would be really cool to finally get upsert implemented.

@timhaines

This comment has been minimized.

Show comment Hide comment
@timhaines

timhaines Jan 12, 2013

Contributor

Really really cool. 👍

Contributor

timhaines commented Jan 12, 2013

Really really cool. 👍

@llama

This comment has been minimized.

Show comment Hide comment
@llama

llama Mar 9, 2013

Is support for save() still in the cards?

llama commented Mar 9, 2013

Is support for save() still in the cards?

@AjayMT

This comment has been minimized.

Show comment Hide comment
@AjayMT

AjayMT Mar 9, 2013

Maybe. You can check out the Meteor Roadmap at http://roadmap.meteor.com/.

Ajay Madhusudan
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Saturday 9 March 2013 at 10:38 AM, Doug wrote:

Is support for save() still in the cards?


Reply to this email directly or view it on GitHub (#584 (comment)).

AjayMT commented Mar 9, 2013

Maybe. You can check out the Meteor Roadmap at http://roadmap.meteor.com/.

Ajay Madhusudan
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Saturday 9 March 2013 at 10:38 AM, Doug wrote:

Is support for save() still in the cards?


Reply to this email directly or view it on GitHub (#584 (comment)).

@dandv

This comment has been minimized.

Show comment Hide comment
@dandv

dandv Apr 4, 2014

Contributor

I've also felt the need for .save() quite often.

Contributor

dandv commented Apr 4, 2014

I've also felt the need for .save() quite often.

@glasser

This comment has been minimized.

Show comment Hide comment
@glasser

glasser Apr 18, 2014

Owner

We do not use GitHub to track feature requests (other than for Blaze). The core team's current roadmap is at https://roadmap.meteor.com/. Discussions about features that users desire are great topics for the meteor-talk mailing list, where the community can help come up with solutions that don't require core changes.

Owner

glasser commented Apr 18, 2014

We do not use GitHub to track feature requests (other than for Blaze). The core team's current roadmap is at https://roadmap.meteor.com/. Discussions about features that users desire are great topics for the meteor-talk mailing list, where the community can help come up with solutions that don't require core changes.

@glasser glasser closed this Apr 18, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment