Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use JSONPatch instead of custom verbs in DDP #4483

Closed
mitar opened this issue May 31, 2015 · 7 comments

Comments

@mitar
Copy link
Collaborator

commented May 31, 2015

DDP could be just an extension over JSONPatch. Allowing deep changes and not just top-level changes.

@dcworldwide

This comment has been minimized.

Copy link

commented Jun 1, 2015

Interesting idea. Would this mean that a conflict resolution will now apply to a document sub-tree and not the entire document? If so that sounds very promising, as presently we often to denormalise a data model to support multi user editing use cases.

@stubailo

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2015

Sounds like a cool idea for the next version of DDP. We'll have to do some thinking about the design anyway when we start taking into account other kinds of databases and applications, so we'll definitely take this into account then!

Thanks for the feature request! We welcome discussions about how to make Meteor better. If you haven't yet, check out our wiki page about feature requests on GitHub.

@mitar

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 2, 2015

Is there some list of features I could make for DDP? My feature list is:

  • JSON patch for verbs
  • backpressure (#3740)
  • allowing to add JSON schema to the document, or custom metadata, in general it could just be additional JSON which is associated with the document, but is not provided through MongoDB interface, but some other interface, you could store in it things like which publish is sending the data, or from which collection is coming, or some other annotations; the main important thing why it should be part of DDP is that it is in sync with data, I am currently using two collections and there are issues because sometimes data is available before annotations come over the wire
@ejfrancis

This comment has been minimized.

Copy link

commented Nov 14, 2015

JSONPatch seems like it's a perfect match for the way DDP is being used in Meteor apps currently. I feel like I'm constantly being forced to change my data model to something other than the true "correct" approach for MongoDB to accommodate the top-level fields being sent down the wire, like when an array is the proper data structure to use but I don't want N extra fields being sent down when I add a single value. Being able to model our data however a developer wants and send the minimal amount of data down the wire to apply changes would be a top priority for me for the next version of DDP..

@SanderMertens

This comment has been minimized.

Copy link

commented Dec 5, 2015

@ejfrancis That is exactly the issue I'm running into (#4752). Glad the discussion on this is still ongoing. Would love to see an update on when a new revision of DDP is going to be published.

@mitar With respect to a metadata scheme for documents, you might find www.corto.io an interesting experiment. It's a developer-oriented, strongly typed hierarchical object (document) store which has a DDP connector.

@dcworldwide

This comment has been minimized.

Copy link

commented Dec 7, 2015

Using nested arrays / sub-documents within a single document is the only way that I've managed to ensure atomicity and integrity within a complex multi-user edit scenario. It works great, but as this thread and #4752 suggests, DDP doesn't do this as efficiently as it should. Would really love to see this issue be given more attention, it has a broad benefit.

@hwillson

This comment has been minimized.

Copy link
Member

commented Jun 12, 2017

To help provide a more clear separation between feature requests and bugs, and to help clean up the feature request backlog, Meteor feature requests are now being managed under the https://github.com/meteor/meteor-feature-requests repository.

This feature request will be closed here, but anyone interested in migrating this feature request to the new repository (to make sure it stays active), can click here to start the feature request migration process. This manual migration process is intended to help identify which of the older feature requests are still considered to be of value to the community. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.