You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Now some explanation on why I'm trying to implement this feature:
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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:

Now some explanation on why I'm trying to implement this feature:
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.
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.
The text was updated successfully, but these errors were encountered: