Mitar

> you provide your own customer trigger functions for each reactive query. These are evaluated for every event in the binlog. OK, so this is what [I mentioned here as...

> without going to the great effort of implementing what is a essentially a JavaScript MySQL engine. It is not a MYSQL engine. It is just a dirty-flag propagation computation....

This has been reported in the past: * https://github.com/peerlibrary/meteor-reactive-publish/issues/21 * https://github.com/peerlibrary/meteor-reactive-publish/issues/44#issuecomment-533425160 I am not completely sure where it comes from, because only tests are using reactive vars.

It is. It is so stable that there is no need to do much. :-) Sadly, I do not have time at the moment to provide examples.

I think something else is happening. See [this test](https://github.com/peerlibrary/meteor-reactive-publish/blob/master/tests.coffee#L109) which seems to work.

If you can provide a small working reproduction (with the least number of packages, just those really required for reproduction), then there is a chance to help here. Otherwise not...

Probably the best approach here would be that fields modify how document is serialized by EJSON. So that fields provide a decoupled way to augment EJSON serialization.

The problem with `ReactiveVar` should be gone. Can you check if the latest version is still having memory issues?

Could you check if #27 is the issue?

Not sure what you mean by re-use. When computation reruns, it has to create a new query because it is generally impossible to know what parameters you changed in the...