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

Auto-join on Mongo.ObjectID fields #698

Open
kaz138 opened this issue Dec 4, 2018 · 1 comment
Open

Auto-join on Mongo.ObjectID fields #698

kaz138 opened this issue Dec 4, 2018 · 1 comment

Comments

@kaz138
Copy link

kaz138 commented Dec 4, 2018

Hi I'm trying to expand / enhance the code base of astronomy to support auto-join features (to automatically fetch the related collection). I'm facing some challenges currently and would like to get some guidance / suggestions on approaching this. If I'm able to make some progress I can then hopefully merge that change back.

Start off with a proof of concept using just what's provided out of box to illustrate the idea:
image

Now some explanation on why I'm trying to implement this feature:

  1. performance: currently for nested objects and arrays, astronomy will store a deep copy of that class with the full schema and data. This could be fairly inefficient for DDP because its reactivity is on per-document basis i.e. any changes in a deeper path will trigger the update and that makes DDP more chatty. Storing those nested objects separately could address this problem.

  2. it reduces the number of copies of the same data, so i don't have to trace down every single place a structure is referenced (and stored as a deep copy). Storing just an object ID will be much better in this case.

Of course trying to do join instead of loading / saving a plain data object has some added cost in coding (to do join, etc.) - that's the very problem I'm trying to automate to some extend with this change.

What I'm trying to achieve is to implement either a module that can hook to the Mongo.ObjectID field load / save / update events if possible, or somewhere in the storage module returning a different collection for nested object fields (currently it always use this.schema.Collection) that may hopefully achieve this more quickly.

Any thoughts / suggestion on approaching this?
Thanks.

@lukejagodzinski
Copy link
Member

Cursors will reactively reload data only when it's being used in the reactive context like Tracker.autorun, so that worth mentioning. Moreover, you can do non-reactive find in MiniMongo - take a look at the reactive option.

The best option is to do it in a way that other ORMs do it which is loading related documents on demand.

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

No branches or pull requests

2 participants