Responsive autoValue about meteor-collection2 HOT 2 CLOSED

Probably isn't feasible to observe just anything... maybe just tie autoValue in to relationships in issue #31 so it can recalculate every time a related object changes/inserts/deletes.. that would cover most use cases of autoValue when looking for a precalculated "virtual field."

from meteor-collection2.

I might not be thinking everything through, but it seems like there are a number of other ways this could be handled:

1. sales could be a virtual field. The calculation would be done more often than necessary, but it would work.
2. You could allow updating sales from the server only and then do a server-side observe on an Invoices.find() cursor, which would update customer.sales whenever invoice.total changes. (Haven't tried the specifics, but it seems like it would work. It's similar to what you're suggesting allowObserve should do.) A while ago I had the idea to add a serverOnly: true option to schemas, but there was never a great use case, but maybe something like this is one. You can do it manually in a deny function, though.

In general the idea of using autoValue to enforce a particular value based on another collection is something I haven't thought much about, but I feel like it's perhaps overkill since there is custom observe and other ways to accomplish it. Nevertheless, I can see where one might expect autoValue to be able to do that, so it's something to keep in mind.

You're correct also that it might tie in with relationships development eventually. Maybe some way of defining a related field as a "count" or "sum" field.

I'll have to think about this.id, too. Since I'm not yet convinced this is a good use of autoValue, I'm also not yet convinced that this.id is necessary.

from meteor-collection2.