meteor-astronomy icon indicating copy to clipboard operation
meteor-astronomy copied to clipboard

Auto-join on Mongo.ObjectID fields

Open kaz138 opened this issue 6 years ago • 1 comments

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.

kaz138 avatar Dec 04 '18 01:12 kaz138

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.

lukejagodzinski avatar Dec 05 '18 13:12 lukejagodzinski